Closed mobad closed 4 years ago
Hi @mobad
Which lib do you make use of? The new java security library? This repo combines several libraries... Please check the settings „localScopeAsAuthorities“ you probably did in context of SAPOfflineTokenServices (as documented here: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/java-security/Migration_SpringSecurityProjects.md#configuration-changes). With this, the non-local scopes are filtered, like „openid“. And you can check for your application specific scopes without the xsappname (application id) prefix, like „appid!t123.“.
Best regards, Nena
Hi @nenaraab,
So we were originally using a old version of java-container security but with a weird setup. We were using tomcat with spring security and we're running on XSA. Basically the setup described here https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.04/en-US/cc45f1833e364d348b5057a60d0b8aed.html under "Configure Spring Security"
But I was hoping to switch to "Configure Integrated Container Authentication of the SAP Java Buildpack" as it seemed much simpler. But I'm not able to figure out how to do the equivalent of isAuthenticated.
I went back to the old setup and followed the migration guide but I've run in to an issue.
Caused by: java.lang.IllegalArgumentException: configuration must not be null
at com.sap.cloud.security.xsuaa.Assertions.assertNotNull(Assertions.java:10)
at com.sap.cloud.security.token.validation.validators.JwtValidatorBuilder.getInstance(JwtValidatorBuilder.java:47)
at com.sap.cloud.security.adapter.spring.SAPOfflineTokenServicesCloud.<init>(SAPOfflineTokenServicesCloud.java:117)
at com.sap.cloud.security.adapter.spring.SAPOfflineTokenServicesCloud.<init>(SAPOfflineTokenServicesCloud.java:101)
at com.sap.cloud.security.adapter.spring.SAPOfflineTokenServicesCloud.<init>(SAPOfflineTokenServicesCloud.java:88)
My VCAP_SERVICES is:
{
"xsuaa": [
{
"name": "xsahaa-uaa",
"label": "xsuaa",
"tags": [
"xsuaa"
],
"plan": "default",
.....
}
]
}
You can see that my "plan" is "default".
I believe the exception is caused by the loadXsuaa function which runs:
Optional<OAuth2ServiceConfiguration> applicationService = Optional
.ofNullable(loadForServicePlan(XSUAA, Plan.APPLICATION));
Optional<OAuth2ServiceConfiguration> brokerService = Optional
.ofNullable(loadForServicePlan(XSUAA, Plan.BROKER));
Optional<OAuth2ServiceConfiguration> legacyService = Optional
.ofNullable(loadForServicePlan(XSUAA, Plan.SPACE));
You can see that it doesn't include the "default" service plan mentioned here: https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.04/en-US/0393ce339acf49bf97b17c671ce92b9f.html So it doesn't find the config and returns null.
Could we get "default" added here?
If you have any ideas on how we could use the simpler buildpack config they would be much appreciated.
Thanks, Mark
hi @mobad
Oh, thats interesting. Thanks for your your detailed feedback! So, I'm going to support the default plan in the next version (probably 2.5.2). Please let me know if you need it in a timely manner (otherwise i would collect some more changes).
I regard to your request. You're right, you do not need the additional Spring Security setup, if you are only interested in the basic JWT validation to make sure, that the user is authenticated. How to realize that is documented in various samples, like here: https://github.com/SAP/cloud-security-xsuaa-integration/tree/master/samples/sap-java-buildpack-api-usage
Note that the SAP java buildpack still makes use of the "old" sap-internal java-container library internally. This will not bother you right now, as in your dependencies you are only referring to this api package, which is available on maven central. And this dependency is only required in case you need further information about the user, like the email, user name... Note that this will change incompatible with one of the next SAP Java buildpack versions.
Best regards, Nena
Hi @nenaraab,
Thanks for the fix! Unfortunately we're trying to fix a vulas issue with an old release of java-security-container that's blocking another team depending on our product so, if possible, a quick release would be appreciated.
As far as I can tell sap-java-buildpack-api-usage only handles the "is the user authorized" case not the "is the user authenticated" case.
Meaning I can do:
// configure servlet to check against scope "$XSAPPNAME.Display"
@ServletSecurity(@HttpConstraint(rolesAllowed = { "Display" }))
And check for $XSAPPNAME.Display but we don't want to have any roles checked because our previous instructions don't grant any roles and I cant find a way of just checking whether the token is valid like I can do with spring-security's isAuthenticated.
The possible workaround I mentioned with using the default "openid" or "uaa.user" role doesn't seem to work for some reason. I just get that the role can't be found and I can't find a way to check for non-local roles using sap-java-buildpack-api. I think they get stripped out.
I think allRolesMode might be the way to do it without a role but I can't find a way to set it as there doesn't seem to be a realm. https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/realm/RealmBase.AllRolesMode.html
Thanks, Mark
Hi @mobad
I'm not responsible for the java-security-container lib. Which version do you use and which dependency causes a vulas issue?
It's a super old unmaintained version of java-container-security like the com.sap.xs2 package which is why we're trying to migrate to this new library.
Too bad... I've tried also several variants like @ServletSecurity(@HttpConstraint(ServletSecurity.EmptyRoleSemantic.DENY))
.. and found not a solution when using @ServletSecurity()
... to skip the Roles check.
I take that as requirement for the new SAP Java Buildpack version, that it will contain the "openid" as dummy scope.
for now I would suggest... as direct replacement for the super-old buildpack you can make use of the new java-client lib (using version 2.5.1
that supports Xsuaa service plan "default").
Would that be feasible?
@mobad
I've just released the "default" plan support with version 2.5.1
.
Please try again...
Thanks @nenaraab it works!
I'm trying to migrate from the old java-container-security to this library and I'm having problems replicating isAuthenticated() with the new library.
Basically I don't care about roles and I want to allow any authenticated user access to my service.
Using https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.04/en-US/cc45f1833e364d348b5057a60d0b8aed.html
With `
and
@ServletSecurity(@HttpConstraint(rolesAllowed = { “???” }))
I've tried various other rolesAllowed = "*", "", null etc but nothing seems to work.
I've also tried to use the "openid" role which always seems to exist but that doesn't seem to work. When I look at the JWT token I can see that the scope includes "openid" but I still get: `2/25/20 2:57:50.713 PM [APP/4-0] SYS #2.0#2020 02 25 14:57:50.713#-08:00#DEBUG#org.apache.catalina.realm.RealmBase#
A13EC8F04A914FB1A7AEEA2D18ADBA0B##xsahaa-java#org.apache.juli.logging.DirectJDKLog########http-nio-127.0.0.1-50128-exec-1#PLAIN
2/25/20 2:57:50.713 PM [APP/4-0] SYS #2.0#2020 02 25 14:57:50.713#-08:00#DEBUG#org.apache.catalina.realm.RealmBase#
FDED7D6B88044702B7941AC0CE1561C4##xsahaa-java#org.apache.juli.logging.DirectJDKLog########http-nio-127.0.0.1-50128-exec-1#PLAIN
`
It seems like it's removing all non-local scopes/roles and I'm not sure how to disable it.
Any ideas on how to make either of these methods work?