#226 Add support for SP-based authorization of sessions
Closed: Fixed None Opened 6 years ago by merlinthp.

This ticket is off the back of the "RFC: Pluggable IdP-side authorisation" discussion on the ipsilon list (https://lists.fedorahosted.org/archives/list/ipsilon@lists.fedorahosted.org/thread/2B3BXAVTOP2IAKVK3V7GIIG4OTVLPHCL/).

What I'm looking at is this:

A SAML2 IdP is intended to do authentication of a user, and to send an assertion of the authentication of that user, along with some attributes related to the user, to a SP. The SP can then use that information to log the user in to the SP, create a user account in the SP application, whatever. The SAML2 protocol is designed such that the IdP doesn't make any policy decisions about the user. That's up to the SP. For example, if a user shouldn't have access to a specific SP application, that SP has to decide that and reject the user access itself.

The problem comes when the SP has limited functionality in regards to policy enforcement. Applications I'm looking at (e.g. GitLab) don't have SAML2 SP functionality as a core feature, and lack any sort of policy logic. Looking specifically at GitLab, it uses the Omniauth SAML library, which has very limited support for SAML2 attributes (it only looks at four specific attributes), so adding policy enforcement based on SAML2 attributes would require non-trivial changes to GitLab, and the Omniauth library it uses. We could fix GitLab, but getting appropriate policy logic into every SP application, be it open source, open source with vendor packages (that can't be changed while maintaining vendor support), or closed source, is just unfeasible.

The idea is to take a somewhat pragmatic view to SAML2 IdP functionality in Ipsilon, and add support for doing IdP-side authorisation of user sessions. This does break the spirit of the SAML2 specification, but I feel it's a useful enough feature to be worthwhile.

A simplified SAML2 flow currently looks like this:

  1. User goes to the SP and attempts to log in
  2. User is redirected to the IdP with a SAML2 authnrequest
  3. If the user doesn't already have an active IdP session, the user authenticates with the IdP
  4. The IdP queries data sources to collect attributes related to the user
  5. The IdP redirects the user back to the SP with an assertion response containing a success status and attributes
  6. The SP processes the response, creating a user session, etc

This would change to add a new IdP-side step between 4 and 5. The IdP would make an authorisation decision based on the user, their attributes, and the configured SP information. If authorisation succeeded, processing would continue. If it didn't, we'd stop processing with an authorisation failure message.

All the above is written in terms of SAML2, but I don't see any reason why we can't do the same for the other providers.

The authorisation would be done by a plugin system like the authentication and info system, reusing a lot of the framework.

Fields changed

owner: => merlinthp
status: new => accepted

PR 99 has a first go at implementing this.

Implemented under PR 99.

resolution: => fixed
status: accepted => closed

Metadata Update from @merlinthp:
- Issue assigned to merlinthp

5 years ago

Login to comment on this ticket.