Expected Behavior
We currently are using Spring SAML Extension 1.0.10 in SP mode. We integrate with different IDPs like OAM, OKTA, ADFS etc and it works smoothly.
Now, we need to upgrade as the underlying OpenSAML is quite old.
I see that Spring Security Core is the new place for SAML support and Spring SAML will not be available as a separate library.
It seems not all functionality from Spring SAML has been ported to Spring Security. We are specifically interested in SP Metadata generation and Single Logout. When will this be available in Spring Security SAML?
Is there a document that can be used for this migration path? ie From Spring SAML Extension to Spring Security SAML Feature set.
Current Behavior
Documentation for existing users of Spring SAML Extension is limited/ unable to find.
Context
@rajn, thanks for reaching out about this. I think it makes sense to provide support for metadata generation as well as single logout.
Based on your feedback, I've added https://github.com/spring-projects/spring-security/issues/8693 to track Spring Security's SP Metadata support.
Would you mind creating a ticket that indicates what you feel is needed to address your single logout use case?
As far as laying out a migration path, that's still a todo. I'll leave this ticket open for adding the appropriate documentation.
I created #8731 for the "trigger a Single Logout" part, which is pretty important I think.
The other part would be receiving a Single Logout request from the IdP (i.e. the Single Logout was triggered from another SP), but I think it's less important (at least I for one have never used this)
@jzheaux is there a place for developers that are going through the migration to share common workarounds, supported / unsupported scenarios, etc? To aid in the meantime, until there's time for an official migration path.
@fpagliar, if it's a use case that you feel ought to be supported by Spring Security, then it's probably best to log a ticket about it. Then workarounds can be placed there. If there's an existing ticket, you can use that.
If it's a scenario that you don't feel should be supported by Spring Security, I'm not sure if there would be an official place inside Spring Security, but feel free to ping me on Gitter if you want help sorting through them.
Hello Spring Security Team,
I jump on this topic to add few more requirements.
We plan to use Spring Security to integrate with several IdPs using distincts protocols (OIDC, SAML2, LDAP, etc.).
By now, after some prototyping using Spring Security 5.3 with SAML2, we are facing several limitations due to some not yet supported features:
Single Sign-out
See https://github.com/spring-projects/spring-security/issues/8731
Generate dynamically SP Metadata document
See https://github.com/spring-projects/spring-security/issues/8693
Ability to specify AuthNRequest signing algorytm
We have some customers requiring to use RSA_SHA1
Ability to configure NameID Format
Some IdPs requires specifying a NameID Format
Support SAML response with unsigned assertions
Generate SP configuration from/driven by IDP Metadata document
Ability to configure Authentication Context Class Reference
Would it be possible to have ETA for those features?
Thanks
Thanks for sharing this list, @nlenoire.
I've got a question about one of them:
Support SAML response with unsigned assertions
I believe it's already possible to have a signed SAML response with unsigned assertions. Is this what you are looking for? I don't think we want to add first-class support for both the response and assertions being unsigned.
Otherwise, on the surface, several of the features sound reasonable, but I think I'd need more detail to know for sure. Would you be able to write up individual tickets for the features that you need, explaining each use case in greater detail?
I've got a question about one of them:
Support SAML response with unsigned assertions
This requirement comes from a customer that is using an IDP that does not sign encrypted assertions, would it be a valid requirement for spring-security to support unsigned encrypted assertions ?
@amergey, I don't think we want to support unsigned encrypted assertions. Can the provider sign the response as an alternative?
The customer will not accept any other alternative than its current configuration: Signed response, with encrypted unsigned assertions.
@nlenoire, that is a supported setup. So long as the response is signed, the assertions do not have to be signed.
Most helpful comment
I created #8731 for the "trigger a Single Logout" part, which is pretty important I think.
The other part would be receiving a Single Logout request from the IdP (i.e. the Single Logout was triggered from another SP), but I think it's less important (at least I for one have never used this)