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

Comment From: 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 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.

Comment From: 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)

Comment From: 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.

Comment From: 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.

Comment From: 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 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

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

Comment From: 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?

Comment From: 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 ?

Comment From: jzheaux

@amergey, I don't think we want to support unsigned encrypted assertions. Can the provider sign the response as an alternative?

Comment From: nlenoire

The customer will not accept any other alternative than its current configuration: Signed response, with encrypted unsigned assertions.

Comment From: jzheaux

@nlenoire, that is a supported setup. So long as the response is signed, the assertions do not have to be signed.

Comment From: scho

  • Ability to configure NameID Format Some IdPs requires specifying a NameID Format

I'm currently started to use the new SingleLogout feature from 5.6.0 and it looks like, my IDP requires specifying the NameID format.

Is there are a way to hack this feature into the OpenSamlLogoutRequestResolver or somewhere else until it's supported? Or should I roll-out my on LogoutFilter?

Edit: I figured out how to change the NameID Format:

// Set the parameters consumer
OpenSaml4LogoutRequestResolver resolver = new OpenSaml4LogoutRequestResolver(relyingPartyRegistrationResolver());
resolver.setParametersConsumer(saml2LogoutParameterConsumer());
// ...
// and set the resolver in the configure(HttpSecurity http) method:
http.saml2Logout(saml2Logout -> saml2Logout.logoutRequest(request -> request.logoutRequestResolver(openSaml4LogoutRequestResolver)))

Comment From: jzheaux

Thanks, @scho! Glad you found it. Note that this is covered here: https://docs.spring.io/spring-security/reference/servlet/saml2/logout.html#_customizing_saml2logoutrequest_resolution

Comment From: t4colingough

Has there been any update on the migration document or guide to migrate from 1.0.10 to 2.0+?

Comment From: gertjanal

Good morning,

First of all thanks for all the effort that is put into this upgrade. The old saml extension works fine with the following setup:

        <spring.version>5.3.15</spring.version>
        <spring.boot.version>2.5.6</spring.boot.version>
        <spring.samlsecurity.version>1.0.10.RELEASE</spring.samlsecurity.version>
        <spring.security.version>5.6.1</spring.security.version>

But upgrading to the latest Spring Boot seems to break the loading of the saml plugin;

        <spring.boot.version>2.6.3</spring.boot.version>

This is why I spent some time investigating this new version of the saml extension. I think the problem for all of us is that the new extension should be 100% feature complete, as we are otherwise not able to upgrade under the hood (without sysadmins needing to change configuration).

In our case, we need the following components before we can upgrade:

  • [x] Users log in to our REST API via a http post binding
  • [ ] Script users log in via Python to our REST API, using the soap binding
  • [ ] The sp metadata is described in an xml. I was not able to find out how this xml can be read. I found the sample with yml configuration, but it would be nice if the current sp metadata can be reused, as this includes the signing key as well.
  • [ ] We support multiple idps, where the xml files are read from a directory in the Spring SP. This is our own extension on the IDPMetadataManager, but loading multiple idps from a directory works very well for us. The name RelyingPartyRegistration is new for me (as that name was not used in the old extension), but I believe this can be achieved with https://github.com/spring-projects/spring-security/blob/50a3bcf7283cc2e7ea75c9b97f9ff2d99273a8de/saml2/saml2-service-provider/src/main/java/org/springframework/security/saml2/provider/service/registration/RelyingPartyRegistrations.java#L127

That's it for now, thanks again for the effort

Comment From: akhil-lm

Hello, 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.

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.

Comment From: marcusdacoregio

Hi, @akhil-lm. Answering your questions:

  1. There are multiple ways to achieve that. One would be changing the loginUrl and logoutUrl in the SAML2 DSL to the old URLs. Another way would be to create a filter that listen to requests to /saml/SingleLogout, for example, and forward them to /logout/saml2/slo, this way you don't need to change the default configuration. I was working on an example for the latter but I had to pause it for now since there were some higher priorities tasks for the upcoming releases.
  2. There is a summary of the changes here.
  3. There is the Migration Guide that is still a WIP. As I mentioned, we had to pause the work on that for now but I plan to resume the work on it soon.

Comment From: akhil-lm

Thanks @marcusdacoregio I was looking into the migration guide for how the login and the logout functionalities are implemented with the spring security :- https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/saml2/login

I ran the sample, and accessed the application at localhost:8080 which then redirected me to the Okta IDP. The following endpoints in the sample application were invoked on signing in through Okta, and then signing out :-

  1. http://localhost:8080/saml2/authenticate/one
  2. http://localhost:8080/logout

I was expecting to find these endpoints in the source code in the sample application, but didn't find them. Could you please guide me towards how are these endpoints configured, that get called when logging in and out through Okta?

Comment From: marcusdacoregio

Hi @akhil-lm,

The best place to start is from the reference docs, there is a SAML Login Overview that may help you.

If you take a look at the Saml2LoginConfigurer#configure and Saml2LogoutConfigurer#configure you will also find out how the filters are built.

Comment From: marcusdacoregio

Hi @akhil-lm, I think that this sample can help you given your needs. https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/saml2/custom-urls

Let me know if it works for you.

Comment From: akhil-lm

Hi @marcusdacoregio, thanks for the above sample.

I've come across another challenge. In our existing saml implementation using the saml-extensions jar, we used to set up the Profile Options. We used to set the relay state in the SAMLEntryPoint, before the authentication request used to go to the IdP.

The SAMLEntryPoint had the 'getProfileOptions' method, that we'd implemented / overridden in our application to achieve the Profile Options set up. I didn't find this class or its equivalent so far in the new framework for SAML.

Request your input on how the Profile Customization can be achieved with the new saml support in Spring Security. What's the new substitute for SAMLEntryPoint? Thanks so much.

Comment From: marcusdacoregio

I think what you are looking for is a way to customize the AuthnRequest instance which is what the WebSSOProfileOptions does. To do that you can refer to this section of the docs, you have the whole AuthnRequest instance available to customize.

Comment From: akhil-lm

Hi @marcusdacoregio, thanks for the above input.

For my login implementation, I've written my custom MyAuthSuccessHandler class that implements the AuthenticationSuccessHandler interface in Spring. I've overriding the onAuthenticationSuccess() and writing the custom logic here that I want to have in my app once the Asserting Party successfully authenticates a user.

So, ultimately, after successful authentication, I want to land into my onAuthenticationSuccess() method.

Right now, the Asserting Party (Okta) calls the '/saml/SSO/' endpoint in my application. Previously, this used to be mapped to the class 'org.springframework.security.saml.SAMLProcessingFilter' (of artifact extensions 1.0.10) in my spring xml configurations.

Even in the new implementation, Okta will call the '/saml/SSO' endpoint after successful authentication. I'm guessing this is the one I need to map to my custom handler whose onAuthenticationSuccess() method I want to invoke.

My configurations so far :- 

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
                .authorizeHttpRequests((authorize) -> authorize
                        .anyRequest().authenticated()
                )


                .saml2Login()
                    .successHandler(new MyAuthenticationSuccessHandler())
                    .relyingPartyRegistrationRepository(relyingPartyRegistrations());

        return http.build();
    }

I am setting my custom handler in the successHandler() method, in the hope that it gets called after the successful authentication.

And my relying party registration looks like :- 

    @Bean
    public RelyingPartyRegistrationRepository relyingPartyRegistrations() {

        RelyingPartyRegistration relyingPartyRegistration = RelyingPartyRegistration.withRegistrationId("mycompany")
                .assertionConsumerServiceLocation("/login/saml2/sso/mycompany")
                .assertingPartyDetails(party -> party
                        .entityId("https://trial-6100123.okta.com")
                        .singleSignOnServiceLocation("https://trial-6100123.okta.com/app/trial-6100123_localmycompany_1/exk3dmunf4rkOEynb697/sso/saml")
                )
                .build();

        return new InMemoryRelyingPartyRegistrationRepository(relyingPartyRegistration);
    }

But I am stuck at the challenge that when '/saml/SSO' is called after the successful authentication, how do I get my onAuthenticationSuccess() method of the custom handler MyAuthenticationSuccessHandler invoked? Request your input on the same, and also please let me know if you see I've got some configuration wrong so far.

Comment From: marcusdacoregio

Is your Saml2WebSsoAuthenticationFilter being invoked by the IdP? Did you map the /saml/SSO to the /login/saml2/sso/{registrationId} or changed the loginProcessingUrl? It's hard to tell what is happening without a reproducible sample.

Comment From: akhil-lm

Hi @marcusdacoregio 1. "Is your Saml2WebSsoAuthenticationFilter being invoked by the IdP" - My IdP calls '/saml/SSO' that was previously (in the saml extensions based implementation) mapped to Saml2WebSsoAuthenticationFilter in the xml config :-<security:filter-chain pattern="/saml/SSO/**" filters="samlWebSSOProcessingFilter"/>

The /saml/SSO endpoint would still be called since the Okta is already configured for my relying party, but now it needs to be routed to my success handler I think.

  1. "Did you map the /saml/SSO to the /login/saml2/sso/{registrationId} or changed the loginProcessingUrl" :- This part is where I am struggling at. I am thinking this is where I've to make use of the SamlExtensionUrlForwardingFilter? I was thinking maybe I can use one of the .addFilterAfter() or .addFilterBefore() on my HttpSecurity instance and pass in my SamlExtensionUrlForwardingFilter? Request your input on this mapping part.

Comment From: akhil-lm

Hi @marcusdacoregio, I tried to run my application, and the error I'm getting stuck at is that ContextLoaderListener.getCurrentWebApplicationContext(); returns me null.

Previously I had the springContext.xml file (now deleted) which was picked by the Listener. How do I configure the same with the SecurityConfiguration.java file? My web.xml has an entry for the Listener :-

<listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener

Comment From: marcusdacoregio

This part is where I am struggling at. I am thinking this is where I've to make use of the SamlExtensionUrlForwardingFilter? I was thinking maybe I can use one of the .addFilterAfter() or .addFilterBefore() on my HttpSecurity instance and pass in my SamlExtensionUrlForwardingFilter

Yes, you do not need to add the custom filter to the SecurityFilterChain, instead, it can stay on the regular filter chain but should be invoked before FilterChainProxy. Register it as a @Component and use a @Order, like you can see in the code:

@Component
@Order(-101) // To run before FilterChainProxy
public class SamlExtensionUrlForwardingFilter extends OncePerRequestFilter {
  // ...
}

Comment From: akhil-lm

Hi @marcusdacoregio, thanks for your reply.

Another query I have is that by looking at the migration guide, I have come to a conclusion that I can implement the SSO using the new libraries with Java+Spring itself, and do not compulsorily need Spring boot. Could you please let me know if that's a correct understanding? Actually, our application do not have Spring boot yet, and we don't have plans to use it.

Comment From: akhil-lm

Hi @marcusdacoregio, I got some success with the new implementation, and when I now try to access my application without authorization, I'm redirected to the configured IdP (Okta) and asked for the IdP credentials.

When I enter my credentials, Okta calls the '/saml/SSO/' endpoint in my application. The problem I am facing right now is that for some reason, the status code for the POST call to '/saml/SSO/' is 403.

This request should ideally be re-directed to the '/login/saml2/sso/{registrationId}' as per the SamlExtensionUrlForwardingFilter, but I am stuck at the 403 error for '/saml/SSO/'.

The SamlExtensionUrlForwardingFilter is working for the '/saml/login' ----> /saml2/authenticate/{registrationId}' routing, so the filter seems to be correctly configured.

Request your inputs on what may be causing the 403 error for '/saml/SSO/', and why the request is not routing to the '/login/saml2/sso/{registrationId}' endpoint.

Comment From: rajn

looks like the answer is in your question :) why is Okta sending to /saml/sso it should send to saml2/sso right? please check the destination url in okta

Comment From: akhil-lm

Hi @rajn, destination url is something my team can't change in Okta, since many clients of our application already have it set to '/saml/SSO' in their existing Okta configurations.

This is why I am using the SamlExtensionUrlForwardingFilter introduced in the spring sample to redirect/forward the '/saml/SSO' request to the correct url as per the new spring security saml2 support. Link to the sample :- https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java/saml2/custom-urls

Comment From: marcusdacoregio

Another query I have is that by looking at the migration guide, I have come to a conclusion that I can implement the SSO using the new libraries with Java+Spring itself, and do not compulsorily need Spring boot.

That's right, in order to use Spring Security features it is not mandatory that you use Spring Boot, although it facilitates a lot of tasks.

When I enter my credentials, Okta calls the '/saml/SSO/' endpoint in my application. The problem I am facing right now is that for some reason, the status code for the POST call to '/saml/SSO/' is 403.

Given that the request is a POST, my first thought is that you are getting a CSRF error. Add logging.level.org.springframework.security=TRACE to your application.properties and check the console. The SamlExtensionUrlForwardingFilter should run before the SecurityFilterChain to forward the request before any authorization happens.

Comment From: akhil-lm

Thanks @marcusdacoregio, I appreciate your help so much.

Comment From: akhil-lm

Hi @marcusdacoregio, With some debugging of the spring filters, I could see the following problem :- Invalid CSRF token found for https://mycompany.abc.com/company/saml/SSO/

Basically in the CsrfFilter of Spring security, there's this code that's returning me the actualToken value as null :- 

String actualToken = request.getHeader(csrfToken.getHeaderName());
if (actualToken == null) {
    actualToken = request.getParameter(csrfToken.getParameterName());
}

So it seems as if the request doesn't have the X-CSRF-TOKEN set as one of the headers. Could you please provide some inputs on how to tackle this problem?

Comment From: akhil-lm

Hi @marcusdacoregio, To resolve the above issue, I disabled csrf :- http.csrf().disable()

That did resolve the 403 error, but now what's happening is that I am getting recursive calls to '/saml2/authenticate/{registrationId}', '/saml/SSO' and the IdP (Okta) url

Basically I am getting recursive redirections to these three endpoints in a loop, and my request is finally ending up in 429 Too Many Requests for the IdP url. Request your inputs on the same.

Comment From: akhil-lm

Hi @marcusdacoregio, I can see that my request is ending up in 'AccessDeniedException' based on a check in the AuthorizationFilter (of Spring) :- AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);

In the check method, there's the following code :- 

private boolean isGranted(Authentication authentication) {
    return authentication != null && isNotAnonymous(authentication) && authentication.isAuthenticated();
}

Here, the condition 'isNotAnonymous(authentication)' is returning false for me. Could this be the reason behind the infinite loop redirects that I am seeing?

Comment From: akhil-lm

SecurityContextHolder.getContext().getAuthentication() This returns null, resulting in the creation of the AnonymousAuthenticationToken object. I am wondering if it's related to the infinite redirects.

Comment From: marcusdacoregio

Hi @akhil-lm ,

the ideal scenario would be to not disable CSRF protection. Did you register the FilterChainProxy for FORWARD requests?

If you are not using Spring Boot you might need to use:

public class SecurityWebApplicationInitializer extends AbstractSecurityWebApplicationInitializer {

    @Override
    protected EnumSet<DispatcherType> getSecurityDispatcherTypes() {
        return EnumSet.of(DispatcherType.REQUEST, DispatcherType.ERROR, DispatcherType.FORWARD,
                DispatcherType.FORWARD, DispatcherType.INCLUDE);
    }

}

Comment From: akhil-lm

Thanks @marcusdacoregio, this worked. I've removed the code to disable csrf.

Comment From: akhil-lm

Hi @marcusdacoregio, I'm currently facing the following errors in my OpenSamlAuthenticationProvider.java :-

[[invalid_signature] Invalid signature for object [id81831180107548381835751282]

[invalid_destination] Invalid destination [https://xyz.companyname.com/company/login/saml2/sso/lm] for SAML response [id81831180107548381835751282]

[invalid_issuer] Invalid issuer [http://www.okta.com/exk3dmunf4rkOEynb123] for SAML response [id81831180107548381835751282]

[invalid_signature] Invalid assertion [id8183118010910692226156343] for SAML response [id81831180107548381835751282]: Signature of Assertion 'id8183118010910692226156343' from Issuer 'http://www.okta.com/exk3dmunf4rkOEynb123' was not valid

[invalid_assertion] Invalid assertion [id8183118010910692226156343] for SAML response [id81831180107548381835751282]: Condition '{urn:oasis:names:tc:SAML:2.0:assertion}AudienceRestriction' of type 'null' in assertion 'id8183118010910692226156343' was not valid.: None of the audiences within Assertion 'id8183118010910692226156343' matched the list of valid audiances]

Is there any single piece of configuration I might be missing out on that might be resulting in all the above errors? Or each of them may be due to individual reasons? Request your inputs on the same.

Comment From: marcusdacoregio

Hi @akhil-lm,

I'm afraid I cannot help now, it seems that it is a configuration issue on your side. I recommend debugging the OpenSaml4AuthenticationProvider in order to figure out the current x expected values.

Comment From: akhil-lm

Hi @marcusdacoregio, No problem. Yes, I will do that, and will seek your help if I have specific queries. Thanks.

Comment From: akhil-lm

Hi @marcusdacoregio, I found success in getting the login to work. But I had to set my Single sign on URL in Okta to '/login/sam2/sso/{registrationId}'.

When I set it to '/saml/SSO', I get the '403 Forbidden' error. On debugging, I found that in the following code, the requiresAuthenticationRequestMatcher is referring to '/login/sam2/sso/{registrationId}' and the HttpServletRequest object refers to '/saml/SSO'. Hence, the requiresAuthentication() always returns false, and the attemptAuthentication() method doesn't get called.

protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) {
if (this.requiresAuthenticationRequestMatcher.matches(request)) {
    return true;
}
if (this.logger.isTraceEnabled()) {
    this.logger
            .trace(LogMessage.format("Did not match request to %s", this.requiresAuthenticationRequestMatcher));
}
return false;
}

Could you please provide your input on this? I feel that I may not have the proper configuration for SamlExtensionUrlForwardingFilter, that's probably resulting in HttpServletRequest request object still referring to '/saml/SSO'.

Comment From: akhil-lm

I confirmed that SamlExtensionUrlForwardingFilter with the following configuration is seemingly being ignored by Spring :-

@Component
@Order(-101) // To run before FilterChainProxy
public class SamlExtensionUrlForwardingFilter extends OncePerRequestFilter {

My Filter chain proxy configuration is as follows :- 

@Configuration
@EnableWebSecurity
public class SecurityConfiguration {

    @Value("classpath:credentials/rp-private.key")
    RSAPrivateKey privateKey;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        RelyingPartyRegistrationResolver relyingPartyRegistrationResolver = new DefaultRelyingPartyRegistrationResolver(
                relyingPartyRegistrations());
        http
                .authorizeHttpRequests((authorize) -> authorize
                        .anyRequest().authenticated()
                )
                .saml2Login()
                    .successHandler(new MyAuthenticationSuccessHandler());
        return http.build();
    }

Do I need to register the SamlExtensionUrlForwardingFilter somewhere else as well?

Comment From: marcusdacoregio

Hi @akhil-lm, did you follow all the steps from the sample's README?

You have to change your RelyingPartyRegistration to the old URLs, is this already done?

singlelogout:
              binding: POST
              url: "{baseUrl}/saml/logout" (2)
              responseUrl: "{baseUrl}/saml/SingleLogout" (3)
            acs:
              location: "{baseUrl}/saml/SSO" (4)

Comment From: akhil-lm

Hi @marcusdacoregio, I had some misconfigurations, but I corrected them and now it's working for me.

But I had to register my SamlExtensionUrlForwardingFilter like this :- 

  @Bean
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
      RelyingPartyRegistrationResolver relyingPartyRegistrationResolver = new DefaultRelyingPartyRegistrationResolver(
              relyingPartyRegistrations());
      http
              .addFilterBefore(new SamlExtensionUrlForwardingFilter(), DisableEncodeUrlFilter.class)

The filter was not being picked before the filterChain by just defining it with order -101.

Comment From: marcusdacoregio

Hi @akhil-lm,

That's my bad, I forgot that you were not using Spring Boot and that it's Spring Boot that picks Filter beans automatically. In your case, you really have to register the Filter in the SecurityFilterChain or in your regular filter chain manually.

Comment From: akhil-lm

No problem @marcusdacoregio, so the way I am registering it is correct?

Comment From: marcusdacoregio

Yes, @akhil-lm.

I feel that further inquiries about the migration path from Spring SAML Extension should be discussed in individual issues (and maybe linked here), this issue is becoming confusing with all those comments.

Please, if you have more questions let's discuss them in a separate ticket or Stackoverflow question and improve our migration path.

Comment From: akhil-lm

Sure @marcusdacoregio, noted. Thank you.

Comment From: jzheaux

Closed with https://github.com/spring-projects/spring-security/wiki/SAML-2.0-Migration-Guide

Comment From: siddharth-78

I'm currently using spring-security-saml2-core [1.0.10.RELEASE], and I'm looking to upgrade it to spring-security-saml2-core [2.0.0.M31] instead of the spring-security-library, since a lot of code change will be required while switching libraries.

During the process of switch from 1.0.10.RELEASE -> 2.0.0.M31, a lot of packages are missing, requesting you to point to the alternative packages in place [PS. I don't see any comprehensive migration document, which points these things out for e.g. this documentation of restsharp is clearly states the alternatives restsharp.dev/v107 ]

Missing imports:

  • org.opensaml.saml2.*;
  • org.opensaml.xml.*;
  • import org.springframework.security.saml.key.JKSKeyManager; [JKSKeyManager is missing]
  • import org.springframework.security.saml.metadata.*;

Comment From: siddharth-78

Hey guys any leads?

I'm working on upgrading spring-security-saml2-core from version 1.0.10.RELEASE to 2.0.0.M31 in my project. I don't want to switch to the newer spring-security-library. After the upgrade, I face the following missing import errors on compilation:

  • org.opensaml.saml2.metadata (from org.opensaml:opensaml:2.6.6 jar)

  • org.opensaml.xml (from org.opensaml:xmltooling:1.4.4 jar)

  • org.opensaml.xml.security (from org.opensaml:xmltooling:1.4.4 jar)

  • org.opensaml.xml.signature (from org.opensaml:xmltooling:1.4.4 jar)

  • org.springframework.security.saml.key (from org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE jar)

  • org.springframework.security.saml.metadata (from org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE jar)

  • org.opensaml.xml.security.credential (from org.opensaml:xmltooling:1.4.4 jar)

  • org.springframework.security.providers (from org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE jar)

  • org.opensaml.saml2.core (from org.opensaml:opensaml:2.6.6 jar)

  • org.springframework.security.saml.userdetails (from org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE jar)

These missing imports are crucial for my application, and I'm unable to compile the code without resolving them.

I was expecting the migration to be straightforward, but unfortunately, that was not the case. I've looked for migration documentation to help with the transition, but the only document available is the SAML 2.0 Migration Guide. However, it's poorly written and doesn't suggest alternate packages for the ones that have changed.

I expected to find a clear and concise migration path, including the necessary package replacements. Now, I'm stuck with these compilation errors and unsure how to proceed.

Can anyone point me to the alternatives or solutions for these missing imports? Any help or guidance on this migration would be greatly appreciated.

@marcusdacoregio @jzheaux

Comment From: martinwunderlich-celonis

@siddharth-78 Have you had any luck with the migration from Spring SAML extension to Spring Security? Any resources you would recommend in addition to the migration guide mentioned?

Comment From: siddharth-78

@martinwunderlich-celonis None yet, here's something that might help you https://github.com/spring-projects/spring-security/issues/13663

Comment From: OrangeDog

For the record, here is what the OpenSAML has to say about the sort of design that Spring Security has moved to:

It is very dangerous to attempt to use parts of the library in isolation without making use of all of its relevant components. In particular, implementing your own XML processing code, using XML parsing classes other than the ParserPool components provided by the library, using your own security processing code, omitting proper support for SAML metadata, etc. are all risky choices that may lead to security flaws and incomplete, unsafe, and ill-advised SAML solutions. The Shibboleth Project discourages such approaches in the strongest possible terms. Use all of it that applies to the task at hand, or use none of it.