CODEWITHSUNDEEP
spring-security
Akhil Ranjan
Akhil Ranjan

Reputation: 141

Migration from org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE to spring security 5.7.x for SAML use-cases

We're using SAML in our application for functionalities like login, logout and single logout through various IDPs like Okta, Lastpass etc. The library we use right now is org.springframework.security.extensions:spring-security-saml2-core:1.0.10.

We now need to move away from this library, and as suggested by spring, want to move to the new spring security (5.7.x) jars. Related forum :- https://github.com/spring-projects/spring-security/issues/8685

I've a few queries regarding this migration :-

  1. In our service provider metadata file that's used in the IDP configuration on the clients' end, we have references to SAML endpoints like '/saml/SingleLogout' and '/saml/SSO'. In the spring security 5.7.x, the equivalent endpoints I see are '/logout/saml2/slo' (for Single Logout) and '/saml2/sso'. If we migrate to the new jar, is there a way to retain the earlier endpoints like '/saml/singleLogout' (by customization)? Else, there'll be changes required in the configuration of all our clients, which would not be feasible.

  2. Do the new spring security jars have all the SAML functionalities that were offered by the extensions 1.0.10 jar? We won't want to miss any use-cases that we have now.

  3. Is there any comprehensive guide for this migration (from spring-security-saml2-core:1.0.10 to spring security 5.7.x)? Or is such a document/guide in plans? Since the two jars are very different in implementation, a guide will be incredibly helpful.

Upvotes: 8

Views: 1072

Answers (1)

Radoslav Ivanov
Radoslav Ivanov

Reputation: 1072

Trying to answer at least partially (if not in full) to your questions as it is a big bang.

  1. Use that dependency now org.springframework.security:spring-security-saml2-service-provider
  2. You can preserve the urls (change the new defaults) by predefining/configuring the new filters (the architecture is the same but the filter names are different - Saml2WebSsoAuthenticationRequestFilter, Saml2WebSsoAuthenticationFilter, etc.), e.g. add AntMatcher with the new pattern:
<bean id="samlEntryPoint" class="org.springframework.security.saml2.provider.service.web.Saml2WebSsoAuthenticationRequestFilter">

<bean class="org.springframework.security.saml2.provider.service.web.authentication.OpenSaml4AuthenticationRequestResolver">
  <constructor-arg type="org.springframework.security.saml2.provider.service.registration.RelyingPartyRegistrationRepository" ref="relyingPartyRegistrationRepository"/>
  <property name="requestMatcher" ref="samlRequestMatcher"/>
</bean>

<bean id="samlRequestMatcher" class="org.springframework.security.web.util.matcher.AntPathRequestMatcher">
   <constructor-arg name="pattern" value="/saml/login/{registrationId}"/>
</bean>

Note: now you could have more than one idp (registration) defined in your config, so you need a "registration id" (or you can have match all urls to one idp with "/**"). So look at those "requestMatcher" and "processingUrl" properties of the filters.

See the architecture here: https://docs.spring.io/spring-security/reference/servlet/saml2/login/overview.html

  1. There are some migration guides but they are complete re-write: https://docs.spring.io/spring-security/reference/migration/index.html

  2. Last but not least you may have to set up httpSessionSecurityContextRepository to keep your sessions and also take care for cross domain things (like cookies, SameSite=Lax, etc)...

Good luck.

Upvotes: 0

Related Questions