Migration path for Spring SAML Extension users

[rajn]

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

[jzheaux]

@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 #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.

[jeanblanchard]

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)

[fpagliar]

@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.

[jzheaux]

@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.

[nlenoire]

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:

High Priority

• Single Sign-out
  See Support sending SAML 2.0 LogoutRequest to the IdP (Single Logout) #8731

• Generate dynamically SP Metadata document
  See Support SAML 2.0 SP Metadata Endpoints #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

Low Priority

• 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

[jzheaux]

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?

[amergey]

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 ?