Migration to Spring Security 5.x version

[Mazhar7860]

Dear Team,

We have upgraded our spring boot application with 2.3.3.RELEASE,this in turn upgraded Spring Security to 5.x version.

We realized ResourceServerConfigurerAdapter is now deprecated, so we followed the migration guide https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/spring-xsuaa/Migration_JavaContainerSecurityProjects.md

Now we have included the below xs-security jar along with other recommended security jars.

   <dependency>
              <groupId>com.sap.cloud.security.xsuaa</groupId>
              <artifactId>spring-xsuaa</artifactId>
              <version>2.7.6</version>
    </dependency>

Though we have configured the resource server , but still whenever we are trying to access the service endpoint with a valid jwt token,we are getting 401 unauthorized error.

I have also created a sample project , could you please have a look into pom.xml/resource service configuration and see if something is not correct or missing. https://github.wdf.sap.corp/i325519/Spring-Security-Upgrade

P.S.: This change is important for our upcoming production release.

Thanks, Mazhar

[nenaraab]

Hi @Mazhar7860 thanks for your request!

Would you mind to provide as the missing information as listed here in the "Issues" section: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/spring-xsuaa/Migration_JavaContainerSecurityProjects.md#issues or here in the "troubleshoot" section https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/spring-xsuaa/README.md#troubleshoot

Thanks! Nena

[Mazhar7860]

Hello @nenaraab ,

Please find the dependency tree information here -

xsuaa-resource-mvn-dependency-tree.txt

I was getting 401 unauthorised error when i was explicitly creating XsuaaServiceConfiguration with default configuration. Because i have autowired XsuaaServiceConfiguration into ResourceServerConfig.java and spring container keeps complaining about this missing bean so i had to explicitly declare this bean in the configuration . Later app was up and but i was getting 401 even with valid jwt token.

@Bean XsuaaServiceConfiguration xsuaaServiceConfiguration() { return new XsuaaServiceConfigurationDefault(); } Please find the debug app log here -

Error_401.txt

Then i thought lets not declare XsuaaServiceConfiguration explicitly so i then added the following component scan @SpringBootApplication @ComponentScan({"com.sap.cloud.security.xsuaa","**com.sap.cloud.security.xsuaa.**","org.springframework.security.oauth."}) public class ResourceServerApplication {

My application started working as expected if i dont pass valid jwt token it throws 401 otherwise with a valid token it allows to access the app services. Please find the logs here

withcomponentscan.txt

Now the question is, is it mandatory to include cloud security xsuaa in the component scan ? If not what is the ritgh way to configure resource server.

Second since in our application we do bind both broken and application xsuaa plans , so how will we authorise the authority/application scope ?

Some where in the migration guide it was mentioned that TokenAuthenticationConverter should not be used if there is more one xsuaa plan

so if i dont include this change

Converter<Jwt, AbstractAuthenticationToken> getJwtAuthoritiesConverter() { TokenAuthenticationConverter converter = new TokenAuthenticationConverter(xsuaaServiceConfiguration); converter.setLocalScopeAsAuthorities(true); return converter;

in the resource server configuration, will scope/authority still work ?

Thanks, Mazhar

[nenaraab]

Hi @Mazhar7860

Instead of this

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
        </dependency>
        <dependency>
            <groupId>com.sap.cloud.security.xsuaa</groupId>
            <artifactId>spring-xsuaa</artifactId>
            <version>2.7.6</version>
        </dependency>

just add this xsuaa spring boot starter

<dependency>
            <groupId>com.sap.cloud.security.xsuaa</groupId>
            <artifactId>xsuaa-spring-boot-starter</artifactId>
            <version>2.7.6</version>
        </dependency>

as described there: https://github.com/SAP/cloud-security-xsuaa-integration/tree/master/spring-xsuaa#maven-dependencies

Your current ResourceServerConfig looks good. But you can get rid of jwtDecoder bean when you have updated to xsuaa-spring-boot-starter (as this is done with auto-configation then).

Further references:

• sample: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/samples/spring-security-xsuaa-usage/

[Mazhar7860]

Dear @nenaraab ,

Thanks auto configuration really helped, now i could see with valid jwt token i could access an application :)

I need few more clarification, since in our productive application we do bind both broker and application xsuaa plans , so how will we authorise the authority/application scope ?

Here in the migration guide it has been mentioned that TokenAuthenticationConverter not applicable in case of multiple xsuaa bindings

so if i dont include this change

Converter<Jwt, AbstractAuthenticationToken> getJwtAuthoritiesConverter() { TokenAuthenticationConverter converter = new TokenAuthenticationConverter(xsuaaServiceConfiguration); converter.setLocalScopeAsAuthorities(true); return converter;

in the resource server configuration, will scope/authority still work ?

As per the documentation,TokenAuthenticationConverter must be configured to check against the authorities.

Thanks, Mazhar

[nenaraab]

hi @Mazhar7860

in case you can't avoid two xsuaa bindings and you can't only use one (the "unified" broker plan) then you can follow the description in the migration guide: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/spring-xsuaa/Migration_JavaContainerSecurityProjects.md#multiple-xsuaa-bindings

the only disadvantage is that you have to do "global scope" checks that mean you have to provide the xsappid as described in step 4.

Best regards, Nena