This ticket is off the back of the "RFC: Pluggable IdP-side authorisation" discussion on the ipsilon list (https://email@example.com/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:
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.
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
to comment on this ticket.