4:32 a.m.
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