I have a number of applications in my environment that are using oauth / oidc flows for authentication but need to filter / provide an authorization on each application so only users who are member of a group / entitlement in DS are allowed to access the application. What is the best way at authentication time to authorize the user based on group membership in DS so not all users can authenticate via a client?
1 Like
Hi @nick.hunt
This is an interesting question that I’ve been mulling for a few days. In general, I dislike the notion of the AS doing authorization as that is not really the role it is there to serve. The RP should be making authorization decisions based on claim data provided by the AS in the id token (for example a groups claim that may provide information about whether or not the user is allowed access to the RP).
Let’s assume however that we must make the AS perform the authorization decision. We know that we can’t make this decision at the time of authentication as the user may already have a session and therefore we won’t invoke any authentication trees, so we must delegate this decision somewhere else. I see (off the top of my head) two places we could do this:
- When minting the token
- Prior to the request reaching AM
To perform the authorization check when minting the token this could be accomplished by simply checking groups in the claims generation script. This could get messy depending on the number of groups and RPs you are dealing with, and leaves you with some outstanding questions, most notably what actually happens if the user is not authorized. Do you generate an exception that prevents the token from being generated? That feels sloppy and difficult to manage and a poor experience for both the user and the RP. Do you strip out all claims from the token? That could work, and would be smoother for the user, but then the RP needs to know what to do with an id token that doesn’t contain expected claims. Do you have enough control over the RPs to dictate how they behave in that scenario? You could include a claim of something like “authorized” with a value of true or false, but once again you are still generating an id token and need your RP to know what to do with the claim which is still offloading authorization to the RP.
If you have flexibility to do so, perhaps doing the authorization check prior to reaching AM could be the solution. I’m thinking here about utilizing IG deployed to protect AM, with a route protecting the /authorize endpoint that uses a PolicyEnforcementFilter that calls a policy which performs a group check based on the id of the client. I’ve implemented something similar to this before for a case where certain applications require MFA before we allow SSO.
To reiterate my initial point I really don’t think this is the role of the AS, but I know some other access management solutions provide this functionality and I can see why you’d want this in AM. I’m not stating that these are the only possible solutions for this problem, but these are the ones that stand out to me.
@mwtech thanks for the reply on this one. In terms of your ask, the need here is I have a shared AM infrastructure across 30+ applications that I need to do some initial authorization checking on users. So, if a user is a member of a group / entitlement, then allow the login / redirect to an app. Then, as you said, the RP will do their internal authorization checking for specific roles in the app. But, to reduce the possibility of people getting authorization failures at each app, we are doing some initial checking at the AM level. The only way I am finding to do this would be a custom scripted node in the journey to do an authorization check using the authz policy service, but that seems a bit much for initial login. Was looking for a way to 1) filter users on login to 2) do entitlement / group checks on login per app client on login to make sure is a valid user.
@nick.hunt - the problem with doing this at login time is that once a user has an authenticated session in AM and a valid cookie they will not trigger an authentication tree, so that approach will only really work for the first authentication that they attempt (unless you are immediately invalidating the user’s session, or have a custom UI in place with logic that you control where you can initiate the login with the noSession=true parameter or invalidate existing sessions for any requests for OAuth2 authorization).
You could do what you are looking for (group lookup) via a scripted decision node, but I don’t think that will actually buy you what you need here.