[mitreid-connect] Roles in OpenID (and when using LDAP)

[Matt Hughes]

Ahh that does clear things up a bit, however I was thinking of building something a bit differently and was hoping for your thoughts on it.

I want the AuthServer, backed by LDAP, to understand the mapping of LDAP filters to ROLEs for each client. On the “Edit Client” screen, there would be a new tab: Roles. Administrators for an app would list all the roles and a series of LDAP filters that grant those roles:

ROLE_ADMIN = (uid=bob_the_admin)
ROLE_USER = (guid=pa_users)(uid=bob_the_admin)
ROLE_EMAILER = (uid=bob_the_admin)
The AuthServer would perform that mapping and return the set of roles the user is authorized for. Then, the client app can just look at the token to see what roles are valid.

This role info would presumably be encoded into the JWT id token. When the client gets the id token from the authorization, it stores it in the user session. Every time a request is made from the end user, you look up the id token and extract the set of roles.

The benefit with this approach, is you centralize the mapping of users to roles. So for folks deploying the application, rather than editing some Spring config file, they can use a UI to administer. I’m not asking for this change to be incorporated into your project, but does this seem like a good idea with regards to OpenID Connect architecture?





On July 23, 2015 at 3:20:27 AM, Justin Richer (jricher at mit.edu) wrote:

The roles between both of those servers are not connected in any way. An account on the IdP could have ROLE_ADMIN there but not have ROLE_ADMIN on the client (simple-web-app is the demo client application). Think of it this way: you could use this client with a non-spring-based IdP that has no notion of what ROLE_ADMIN or ROLE_USER are. The roles that those accounts might have in the server, if they even exist, have no bearing on the client.

It’s up to the AuthenticationProvider in the client code to determine which users get which roles locally. This is configured in the current branch using the OIDCAuthoritiesMapper plugin component, which we provide a simple implementation that lets you name your users who get ROLE_ADMIN by their iss/sub pairs:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/NamedAdminAuthoritiesMapper.java

If you look in this code, you can see that this service gets handed the incoming ID Token and the user info object. A custom implementation can map that information onto whatever local ROLE_ values that it wants, regardless of the server’s setup. Thus, it’s up to you whether you’d like to map your client’s ROLE_ADMIN users by their identities (iss/sub pairs) or by other attributes that you fetch from the server.

 — Justin
On Jul 22, 2015, at 7:55 PM, Matt Hughes <hughes.matt at gmail.com> wrote:

I’m running both the OpenID-Connect-Java-Spring-Server/openid-connect-server-webapp and the OpenID-Connect-Java-Spring-Server/sample-webapp projects.

Sample Webapp defines resources that are protected by either ROLE_USER or ROLE_ADMIN. In the connect server (IDP), user roles are stored in the database. I’m having a hard time figuring out how, once the sample webapp has the access_token, it knows what roles the users has. Is it able to extract that information out of the access_token? Or does it make a web request to the IDP asking for role info?

My next step is to try to use an LDAP server as the IDP. However, looking at the sample LDAP project, I don’t understand how roles fit into the picture there. Once a user is authenticated against an LDAP provider, how would the IDP or RP map roles onto the user?






_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu
http://mailman.mit.edu/mailman/listinfo/mitreid-connect

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150723/811c1341/attachment-0001.htm