Rest2LDAP, especially the webapp, should support OAuth2. In particular, Rest2LDAP should act as an OAuth2 "resource server" requiring an OAuth2 token to be provided with incoming requests.
Once Rest2LDAP receives the OAuth2 token it must authorize the request, but how? For fine grained access control we must allow the backend LDAP directory to enforce its own access control policy for which it must be able to determine the identity of the end-user. The traditional way to achieve this is for the client (Rest2LDAP) to pass a "proxy authz" control with the request which communicates the identity of the end-user. Here we have a choice:
- Rest2LDAP is responsible for validating the OAuth2 access token and mapping it to a proxy authorization ID (DN, uid, email address, etc) which is then included in the proxy authz control
- the LDAP directory server is responsible for validating the OAuth2 access token and mapping it to an identity before applying access control. In this case, Rest2LDAP acts as a protocol gateway, by simply forwarding the OAuth2 access token with any outbound LDAP requests as the authorization ID in a proxy authz control.
There are pros and cons to both approaches:
- will work "out of the box" with existing standards compliant LDAP directories that support the proxy authz control, but will not be able to take advantage of the case where the backend LDAP server is the OAuth2 token store
- will require that the backend LDAP server is capable of acting as an OAuth2 resource server. In other words the LDAP server will need to be able to validate tokens and map them to identities. There are potentially large performance gains to made in the case where the LDAP server is acting as the OAuth2 token store.
Therefore I think it would be good if we supported both approaches. Suggested fixes:
- Rest2LDAP leverages OpenIG's OAuth2 resource server filter and delegates token lookup to a remote configurable AS. It then maps the returned token information to a suitable authz id which the server understands. The mapping algorithm should be configurable
- we defined an extension to the proxy authz control allowing us to pass across an OAuth2 access token. There are two existing schemes: "dn:" and "u:". We could re-use the "u:" scheme or define a new "oauth2-bearer:" scheme. We then implement an IdentityMapper in DJ capable of mapping OAuth2 access tokens to a DJ user. We may need two mappers, one which calls out to a remote OAuth2 AS tokeninfo endpoint, and one which is optimized for the case where DJ is the OAuth2 token store behind AM.