[keycloak-user] Allocating Role Assignment Responsibilities with OIDC / Keycloak

[Steve Ramage]

Hello,

I'm building an application that will use OIDC to authenticate (and potentially make some simple authorization decisions) and I have some questions about the best way to do that. Keycloak is our reference implementation, but we would like to do this in a completely generic way.

The context is that our application has three classes of users, teachers, students and parents for example, and they under go completely different life cycles and have different responsibilities in our application. In some deployments of our software the teachers may be part of a school district with SSO functionality, and they have a different set of capabilities in our application (and our application knows that they are teachers). We also have students who may be centrally registered, and we may have parents who are publicly registered or signed up manually. We would like Keycloak or whatever IdP that is chosen, to manage all of this complexity for us and essentially we just need to know the class of user. There is zero possible need for users to switch classes, students don't become teachers, etc...

There are two broad ways I can see our application handling this within the context of OIDC.

1) My first thought from going over the OpenID Connect protocol, was that we could use scope/claims for this. When we redirect the user to the IdP, we ask for a specific additional scopes (i.e., "openid teacher" or "openid student" or "openid parent"). If the user doesn't have these roles in Keycloak, then we don't get the actual claims and we can reject the request. The issue that I have is I can't seem to get this workflow to work with Keycloak, where there is a scope type based on the role, and only users with that role can successfully give us that claim. I can get the claim to appear in the claims returned but not conditionally in this sense. I can also get the information in other claims returned by Keycloak, but this seems Keycloak specific, and it seems like other identity providers would have different structures, and we would have to support different introspection of the various tokens, or make that configurable, which is less than ideal.

2) We could just wire our application up to use three different configurations for IdPs, one for teachers, students and parents. This could be managed in different realms in Keycloak. The drawback of this approach is that in some cases we need to ask the user who they are (teacher / student / parent) before we can authenticate them.

Anyway I'm not even sure if the above two are the right approach at all, and maybe I'm looking at the problem backwards. In particular, the role and scope/claims are specific to our application, our application really isn't asking for authorization to protected resources that the the end users own, we are just piggy backing on it, to determine role in a simple RBAC system, maybe that is simply a mistake, and we should leave the role assignment in the application (although that vastly increases scope, and seems weird since Keycloak has a whole bunch of complex role management functionality that we couldn't leverage or coordinate between services). Alternatively maybe we can impose some constraints on IdPs and say that they have to support say a role claim, that has one of three possible values in the tokens, either teacher / student / parent. Maybe that is a very reasonable imposition to make on a dedicated Identity Management System.

I'd appreciate any advice anyone had on this problem.

Cheers,

Steve Ramage