So there’s been a bit of discussion already happening on Jira, see from here on TRUNK-381. As requested by @dkayiwa I’m taking this here as some more design is needed at this point.
The bottom line is that a 3-party authentication provider will tell OpenMRS “this user is authenticated and has those roles”. We consider that the 3-party authentication provider will just refer to exisiting roles. So somehow it needs to know of them in some form, role UUIDs or role names.
When OpenMRS is being told about a successful authentication two situations are possible:
The user already exists in which case it will be fetched and marked as authenticated.
The user doesn’t exist yet
In the latter case OpenMRS will have to create the user and assign the roles indicated by the 3-party authentication provider. In the end we need to be able to do the following:
Fetch a user by username.
Fetch a role by UUID (and/or by name, ideally).
Create a new user.
Fetching can perhaps just be done by expanding on ContextDAO (the same way getUserByUuid(String) is already part of it).
What about creating a new user, this will obviously leave an audit trail, should this be let to the Daemon user?
A quick framing question: why does an AuthenticationScheme need to define roles (i.e., handle authorization as well)? We already have RBAC inside the platform. Could AuthenticationSchemes focus solely on authentication?
An authentication scheme is creating a local (OpenMRS) copy of the authenticated user, if they do not already exist. But this user is not yet mapped to any roles and hence will not do anything meaningful in OpenMRS. At what stage will the user to role mappings be copied from the 3-party authentication system into OpenMRS? Am also still struggling to fully understand the real practical use case where some one creates OpenMRS specific roles in a 3-party authentication system just for the sake of being able to log in OpenMRS and do ABC.
This will help register users in one place. The 3-party authentication system will not define or manage OpenMRS roles at all, just merely keep references (UUIDs, names) to it for convenience only. So that a system admin can say to the 3-party authentication system “I’m creating a new user ‘johndoe’ with OpenMRS roles x, y and z.”
When ‘johndoe’ logs in the first time, the authentication scheme will be able to create the OpenMRS user and assign the roles being fetched by UUID (or name).
That’s a nice to have, but we are not looking at a way to manage roles outside of OpenMRS at this point.
@mksd when you say “That’s a nice to have”, what value is it to just authenticate without user to role mappings for authorisation? Will such a user be in position to meaningfully use OpenMRS?
Well you would save the hassle of a double creation of users, one in the 3-party authentication system and the second in OpenMRS. From a system management point of view that’s already a big plus.
If there were ways to fetch the roles and assign them, or at the very least a default role, that would be a second big plus.
To clarify, it will be up to custom auth. schemes to do this or not, but in order to let this be possible we would have to leave a way to create new users. Hence the suggestion to do it deep down with the Daemon user, but through an API that would be available only to auth. schemes.
