ABAC replacement for public/unauthenticated client access?

Help
2

Hi Gary,

In the most simple scenario you would create a bootstrap role that has two permissions:

  • Permissions to log in. This could be access to an user_by_email index or just the right to call a User Defined Function or UDF that logs your user in.
  • Permissions to register. This could be access to create a new user or again a UDF

Note: I prefer UDFs in such case, since it’s a convenient way to bundle some logic together such as searching a user by e-mail, calling login etc.

For example, your bootstrap role could look like this (non UDF approach):

{
  name: 'keyrole_register_login_verify_token',
  privileges: [
    {
      resource: Collection('accounts'),
      // accounts can be created.
      // accounts can be updated to change the verification
      actions: {
        create: true,
        read: true
      }
    },
    {
      resource: Index('accounts_by_email'),
      actions: { read: true }
    }
  ]
}

For which you then can create a key (with the CreateKey function) to bootstrap your app. You do not need to create a fake user and login with that, if you do not need to have an Identity (see the Identity) function) to be attached to the secret than you don’t need that. If that initial access is however not anonymous you can make a Token as well (Keys are anonymous, Tokens have an identity or database document attached to them) by using

Create(Tokens(), {
        instance: <reference to some database entity> 
}

This gives you a similar token as Login would give you, only without the credentials requirement.
Tokens are documented (and creation will soon be) documented here
Keys documentation can be found here.

Your scenario

The above assumes no read access to your resources accept what is necessary to login. For your first scenario:

  • add read access to the resources you want to make publicly available

Second scenario:

  • You are on the right track I think to have passwordless users there. You can use the passwordless token approach above for that (maybe via an UDF) and once the user is claimed, update the document to add credentials and revert to Login to generate your tokens.

Example

There is an example here (with Github repo) that creates ‘client roles’ as well as ‘logged in’ roles.

4 Likes