1. Cf-Dev
  2. Topics

[EXTERNAL MESSAGE] Re: [cf-dev] Using SAML 2 Bearer token with our own UAA Server #uaa

Shetty, Viraj S [CTR]
 
Edited

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

 

 

From: cf-dev@... <cf-dev@...> On Behalf Of Filip Hanik
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 ? 

 
Filip Hanik
 

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 ?) .

It's been a while since I dug into that code, but I think the Recipient should match the URL you're posting the message to, which is:

http://<host>/uaa/oauth/token/alias/cloudfoundry-saml-login-dev

Filip
Filip Hanik
 

probably https:// and not http://
Shetty, Viraj S [CTR]
 

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. 

1 - 4 of 4