If your application maintains it’s own list of Users and Roles, perhaps because they have extra info and relationships stored and used in the app, I think it makes sense that you have to keep those sync’d with the user definitions the AppUser and Role tables.
So is it a normal/best practice to have your UI pages sync the update across both your apps tables and the platforms tables? (perhaps with transactions)
and perhaps we can expand this slightly…most companies will have some authentication system (i.e. auth0, okta, ping identity) and will coordinate user login definition in those tools with the internal tables in Apex.
Perhaps you could comment on a common scenario here, though there are many, for example:
User comes to site, chooses to register, App then gets needed info from user, and puts user entry into security system (i.e. auth0) through some mechanism (Auth0 management api, custom database, SCIM, federated authentication, bulk import).
But then, what’s the common next step…
The user wouldn’t be in AppUser (since they have never logged in), so we can’t really relate them to the Roles teams (Teams) yet, right?
And then if the app has it’s own users and roles tables for the reasons previously mentioned, what’s the common way to coordinate these things?
I realize this is a big area with lots of options, just looking for a common prescription.
The usual pattern is to use one of the authentication libraries like Auth0 or Cognito. These ensure that the user gets a JWT access token and pass it to the server with each request in the Authorization header.
There is server side logic in those libraries that verify the JWT signature and then create the AppUser if it does not exist. This lets the combination of app and authentication system configuration control if / how a user can sign up.
Authorization is separate from Authentication. Most applications use the authorization capabilities that come from the base libraries. This includes the Role and AppUserToRole business objects. These are used to control access to specific business objects and their behaviors. They are also used client-side to give a good user experience (like not trying to access a page with APIs that the user does not have access to).
The role membership can be managed in the application or externally (or a combination of both). An example of external management could be authorization claims added to the JWT by the authentication system. The server-side logic can use these to adjust role membership dynamically.
Roles can be static (defined by a Team in Apex Designer) or created dynamically (a client-specific role with team members managed on a client page).
Authorization can also be managed by application logic vs role membership. Event handlers (before create, update, delete and access) can be used to add restrictions based on application metadata. An example would be allowing access to a supplier’s locations if the user is the procurement lead for that supplier.
Hopefully that helps give a good sense of the range of options.
