[EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa
Thanks. I digged into this a little deeper. During the SAML verification, confirmed is never TRUE and that’s why it gives the following error
2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can't be confirmed by the bearer method
SPSSODescriptor spssoDescriptor = (SPSSODescriptor) context.getLocalEntityRoleMetadata();
for (AssertionConsumerService service : spssoDescriptor.getAssertionConsumerServices()) {
if (context.getCommunicationProfileId().equals(service.getBinding()) && service.getLocation().equals(data.getRecipient())) {
confirmed = true;
}
}
Here are the consumer assertion services defined in my UAA metadata.
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https:///saml/SSO/alias/cloudfoundry-saml-login-dev"
index="0" isDefault="true" />
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI"
Location="https:///oauth/token/alias/cloudfoundry-saml-login-dev"
index="1" />
The SAML Assertion that comes in – has the following
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">HIDDEN</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo=""
NotOnOrAfter=""
Recipient="https:///saml/SSO/alias/cloudfoundry-saml-login-dev" />
</SubjectConfirmation>
</Subject>
See that the recipient matches with https:///saml/SSO/alias/cloudfoundry-saml-login-dev but I think the Binding does not match (in the code I am not sure what binding is matched to. Is it Method ?) .
Do I have to change my uaa.yml to somehow add a new Assertion Consumer Service ?
Viraj Shetty
Sent: Tuesday, December 10, 2019 6:49 PM
To: CF Developers Mailing List <cf-dev@...>
Subject: [EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa
1. Take a look at the endpoint `/saml/metadata` on your server. For example https://login.run.pivotal.io/saml/metadata
In the metadata, take a look at: urn:oasis:names:tc:SAML:2.0:bindings:URI binding, for the exact location to POST your Assertion
https://login.run.pivotal.io/oauth/token/alias/login.run.pivotal.io" index="1"/>
2. You can have the NameID encrypted, not the assertion itself.
Correct:
Incorrect:
Incorrect:
3. A fully working example you can run in your Debugger can be viewed here (no server required)
On Tue, Dec 10, 2019 at 2:07 PM vshetty via Lists.Cloudfoundry.Org <vshetty=fdic.gov@...> wrote:
Still having issues. I tried several things and they all seem to fail.
1. Per the documenatation, the URL should go to http://vyscu3.localhost:8080/uaa/oauth/token/alias/vyscu3.cloudfoundry-saml-login. For my environment, this should probably be
http:///uaa/oauth/token/alias/cloudfoundry-saml-login-dev
How do I find if this URL is correct ? The receipient in the SAML Asserrtion is https:///saml/SSO/alias/cloudfoundry-saml-login-dev. tried this as well.
2. When i used with encrypted assertion below, i get the following exception
2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT java.lang.ClassCastException: class org.opensaml.saml2.core.impl.EncryptedAssertionImpl cannot be
cast to class org.opensaml.saml2.core.Assertion (org.opensaml.saml2.core.impl.EncryptedAssertionImpl and org.opensaml.saml2.core.Assertion are in unna
med module of loader org.apache.catalina.loader.ParallelWebappClassLoader @3ed242a4)
2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT at org.cloudfoundry.identity.uaa.authentication.SamlAssertionDecoder.doDecode(SamlAssertionDec
oder.java:97) ~[cloudfoundry-identity-server-74.5.0.jar:?]
2019-12-10T16:51:10.13-0500 [APP/PROC/WEB/0] OUT at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:79) ~[ope
nws-1.5.6.jar:?]
3. then i tried unencrypted assertion, which gave me another exception
2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT Caused by: org.opensaml.common.SAMLException: Assertion invalidated by subject confirmation - can'
t be confirmed by the bearer method
2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifySubject(WebSSOProf
ileConsumerImpl.java:400)
2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOPr
ofileConsumerImpl.java:296)
2019-12-10T16:45:24.58-0500 [APP/PROC/WEB/1] OUT at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationRes
ponse(WebSSOProfileConsumerImpl.java:214)
UAA does not seem to like the subject. Looking at the subject confirmation tag, there is attribute 'method' which is 'urn:oasis:names:tc:SAML:2.0:cm:bearer'
Any ideas ? IS there any expanation other than the UAA Api ?
See that the recipient matches with https://<HIDDEN>/saml/SSO/alias/cloudfoundry-saml-login-dev but I think the Binding does not match (in the code I am not sure what binding is matched to. Is it Method ?) .
Thanks.
The SAML assertion generated by ADFS contains "https://<HIDDEN>/saml/SSO/alias/cloudfoundry-saml-login-dev" while the bearer assertion in the metadata file is https://<HIDDEN>/oauth/token/alias/cloudfoundry-saml-login-dev (this is what i am using to post).
This raises another question. In a general case, lets say Application A is an on-prem application which is already SAML authenticated with internal ADFS Server using a Relying Party R. Web Service W (OAuth Resource Server) is located in cloud.gov and is a client for UAA in cloud.gov. The UAA in cloud.gov has a trust with the same internal ADFS, however the Relying Party is different (That would be the most likely scenario). In this case, the SAML assertion will contain the recipient field pointing to application A (and will not point to UAA). How would this even work ? Sounds like the assertion would be rejected by the UAA if we pass to UAA to get oauth token.