SecurityContext.getAccessToken() returning Null

[KaminiSingh]

Hi , We are trying to upgrade to the new security Library and followed the steps from the below Migration guide

https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/java-security/Migration_SAPJavaBuildpackProjects.md

I have attached Pom.xml and web.xml of my project ..

We are trying to access the application using Client credentials flow . Please note that there are no scopes in the client credential JWT .

we have added the below dependency in the web.xml

<security-constraint>
    <web-resource-collection>
        <web-resource-name>All SAP Cloud Platform users</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
   <!--  <auth-constraint>
        <role-name>ODPManage</role-name>  
        <role-name>APIManage</role-name>  
        <role-name>APIFullAccess</role-name>  
        <role-name>ODPAPIAccess</role-name>           
    </auth-constraint> -->  
</security-constraint> 

if we add the auth-constraint with the scopes , the client credential call does not reach the application layer . On removing the auth-constraint the call reaches our application but we can see that SecurityContext.getAccessToken() returns null .

I can see in the guide that it is a known issue . Is it fixed in the latest releases or can you suggest what needs to be done to get the token value .

pom.txt web.txt

[liga-oz]

hi @KaminiSingh,

what do you exactly mean by "call does not reach application layer"? It is not authenticated or you do not see any incoming requests at all? Have you previously used the SAP Java Container Security API or Web Servlet Security using the buildpack?

If the incoming request Jwt doesn't have any roles, but you have defined them in the application security configuration, then I would expect that the request doesn't get through. Can you please increase the logging level and try to see what exactly happens with the incoming requests, why and where it fails. In case your application provides no scopes, consider the documentation here.

In the guide Known issues are meant as frequently faced migration problems that developers stumble upon and not in a sense of found bug in the library.

Thanks and regards, Liga Ozolina

[KaminiSingh]

Hi @liga-oz

Attached are the logs when I specify the roles in application security configuration . I see the request gets Authenticated , but the request does not comes to the application .

Even if I remove the constraint I see that AccessToken is returned as null . while trying to invoke the method com.sap.cloud.security.token.AccessToken.getTokenValue() of a null object loaded from field com.sap.gateway.core.service.authorization.TokenValidation.reqToken of an object loaded from local variable 'this'" }

We are trying to use SAP Java Container Security API using the buildpack first time . log.txt

[nenaraab]

Hi @KaminiSingh

so, I've checked your logs... I guess you followed the guide @liga-oz has provided to you, as you asked for support for Servlet Security when you do not have any scopes?

Have you set environment variable DISABLE_LOCAL_SCOPE_AS_AUTHORITIES = true in the mean while? Has the Nullpointer Exception disappeared for the endpoint that supports a client credential token without scopes?

So, in order to support you, we need to understand your current configuration, the endpoints your are calling and the full log.

Please note, if you've disabled local scope checks you would have to provide (within the same cloud foundry application) the application id for the scope checks, e.g.:

@ServletSecurity(@HttpConstraint(rolesAllowed = { "xfsrt-application-sandbox!t9563.APIManage" })) 

or

<role-name>xfsrt-application-sandbox!t9563.APIManage</role-name>  

BUT, as the application id is different in all your Cloud Foundry landscapes you would have to take it from the system environment variable dynamically. Not sure whether and how this works? In case you have to support both use cases as part of the same app (the client-credentials token without scopes and the user token with scopes) i would not disable the local scope checks.

Best regards, Nena

[nenaraab]

Hi @KaminiSingh

Right now the SAP Java Buildpack supports only scope checks against one single xs-appId for local scope checks. That means in case of multiple xsuaa bindings, xsuaa(application) is preferred over xsuaa(broker). That means the "xsappname" from xsuaa(application) is used for local scope checks.

Limitations:

• There is no option to select another xsuaa instance as primary one as part of the SAP Java Buildpack
• Another idea would be whether wildcards can be used as part of the role check? This might be an idea for SAP Java Buildpack enhancement.
• Not sure whether you could read the respective "xsappname" from the complex VCAP_SERVICES environment variable (see "Stackoverflow: Referencing Environment Variables in web.xml"), so that you can implement it properly with global scope checks.

Closing this, as we follow up as part of this ticket (SAP internal).

UPDATE: the solution was to get rid of the second xsuaa service instance.