Provision User Application Access

Help
,
1

We need to create a large number (10000+) of users accounts that will be accessing our Web, SPA, and Native applications. (We do not need to provide any with API access).

How do we do the following:

  1. Create user(s) with roles - know how to do this
  2. Grant direct access to 3 web application, 1 SPA, and 1 native application - DO NOT KNOW
  3. Send email requesting the existing User add password to account - know how to do this
  4. Send email listing links to all the application mentioned above - can work this out

The steps above are in the order we wish to follow.

The user does not get to decide if they might like to ask for access. We will know if they should or shouldn’t have access. If they don’t have access they will have no knowledge that the application exists. Access to applications will vary based on the Users role and access may be granted and removed from a user at will. We would like to be able to easily identify which applications a user can and can not access in the Auth0 Dashboard.

1 Like
2

Well, you’re halfway there. If you can already create users with rules, then granting direct access to some apps is easy:

In my case, I have one logical API in auth0 which refers to my entire microservices architecture. In it are defined some permissions. For example:

872×436 31.4 KB

Now, in each of your applications make sure you set the audience to that API so that you get an access token which is able to access that.

I’ll assume you’ve already gotten this far, so to continue to the answer:

  1. Simply create a Role which has the desired API permission
  2. Add a user with that role.

All done!

If you want to add all 10,000 users + roles in a batch you can do that too, using the Management API.

2 Likes
3

Another option if you don’t need any kind of API access would be to assign roles to user (from the dashboard, or using the API). You could have a direct 1-to-1 mapping between roles and applications, or something else that makes sense to your authorization model.

Then, in a rule, you can check context.authorization.roles to see which roles the user has assigned, and allow or deny authorization based on that and the context.clientID. In a very naive code sample:

function(user, context, callback) {
    // this is a hard-code relationship between the 
    // apps and any of the roles required to access it
    const allowedRoles = {
      "client_id_1": ["role1", "role2"],
      "client_id_2": ["role1", "role3"],
      "client_id_3": ["role4"]
    };

    const allowedRolesForClient = allowedRoles[context.clientID];
    if (!allowedRolesForClient) {
      // it's an app not listed yet, you decide what to do
      return callback(new UnauthorizedError(
        "Don't know what roles to look for in this app"));
    }

    var userRoles = (context.authorization || {}).roles || [];

    // now check if the user has any of the allowed roles
    //
    // if you want to change the authorization policy so that 
    // *all* roles for the app are required
    // then replace "some" for "every"
    var hasAccess = allowedRolesForClient.some( 
      allowedRole => userRoles.contains(allowedRole));

    if (!hasAccess) {
      return callback(new UnauthorizedError(
        "The user doesn't have any of the roles required for the app."));
    }
    
    // If allowed, continue as usual
    callback(null, user, context);
}
1 Like
4

Thanks for the help! Much appreciated. I’m going to give both ideas a go, they look like they will cater for slightly different scenarios quite well.
Much of what I’m doing now is technical evaluation of Auth0 so I can report on it’s suitability. Knowing we can get good help when needed is a big plus.

2 Likes
5

Thanks a lot @entity1! Let us know if you have any other questions!