Federation Starters 6

Blog Post created by SungHoon_Kim Employee on Jun 17, 2016

This is continuation from Federation Starters 5


Previously IDP side was configured for SAML Artifact Profile.


Create SP side configuration.


1. Deploy affwebservices on SPS Tomcat (already done)

2. Modify (already done)

3. Modify (already done)

4. User Store (already done)

5. Authentication Scheme (already done)

6. Domain/Application (already done)

7. Realm/Component (already done)

8. Rule/Resource (already done)

9. Policy/Role (already done)

10. Session Store is Not Required (For Artifact, IDP requires session store to save assertion but SP do not need it. But still, if you want to implement then you will need session store)

11. Import IDP's Federation Web Services securing ssl certificate's chain for SSL BackChannel.

12. Entity(Local and Remote)

13. Partnership


Since everything is agreed, let's start setting up SP side configuration.


1~10 is already done so it is skipped.


11. Import IDP's Federation Web Services securing ssl certificate's chain for SSL BackChannel.


We actually performed this in previous use case so there it is.

When you try accessing "https://www.sso.lab/affwebservices/public/saml2sso" and check the ssl certificate, you can check what you will need to import.




Click on the padlock icon and you can view the server certificate.

At the "Certification Path" tab, you can find out if there are intermediate CA and find the RootCA.

Import the chain of certificates.


12. Entity(Local and Remote)

Create Local SP Entity.



Create Remote IDP Entity.




13. Partnership


Create SAML2 SP to IDP Partnership.


For some reason, "Enforce Single-Use Assertion" and "Use Persistent Session" options are enabled by default.

These features require Session Store, so in case if you do not have session store enabled at the SP, you should turn these OFF.

I will just leave it. If you do enable "Use Persistent Session" then I would encourage you to also enable validation period just so you can ensure the session is updated based on the interval you specify.


Above is the user credential SP will be supplying when it connects to "https://www.sso.lab/affwebservices/public/saml2ars".



Nothing to do here.



Now I test the Artifact use case and unfortunately it failed.

But that gives us an opportunity to troubleshoot.


You would already be familiar what to do in this case.

Copy the TransactionID 6826e6f8-28e70e03-40336b3d-17363412-69d54d39-49 and look it up on affwebserv.log and FWSTrace.log for details.


FWSTrace.log shows the following message.


The exception reports "Illegal key size".

Usually this means JCE patch is required.

And as this SP side Federation Web Services is deployed on SPS which is using 32bit jdk, that jdk/jre must be JCE patched.


Shutdown SPS Service(SiteMinder Proxy Engine) before applying the jar files.



Startup "SiteMinder Proxy Engine" service and try again.


Try federating again.

So, this time it worked.


Now take a close look at the fiddler trace.

In the SAML Post Profile, the Assertion went through the browser so you were able to capture the SAMLResponse POSTDATA.


In this SAML Artifact Profile, Assertion does not go through the browser.

What you saw was "SAMLart" which is the SAML Artifact. And it was also a "GET" request to "https://www.partner.lab/affwebservices/public/saml2assertionconsumer".


When the IDP side generates assertion, it stores the assertion in the session store and provides and Artifact that would have reference to the Assertion.

That artifact is passed on to SP via querystring.


SP receives this Artifact and establishes HTTPS connection to "https://www.sso.lab/affwebservices/public/saml2ars".

And it makes a SOAP Post with the Authorization header which delivers the UID(SSO2PARTNER) and PWD.


If it passes the Basic Authentication(there is no physical user created for this, it is a virtual user that is part of the partnership configuration) then in the RESPONSE to the POST request, the SAML Assertion is sent to SP.


SP captures the SAML Assertion in the response and consume it to authenticate user.


The part where the SP is submitting Authorization header is not captured in the log.

But FWSTrace.log will show what SOAP message was posted.


SP's POST request via SSL BackChannel

[06/17/2016][10:41:34][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][][getAllCAcerts][Subject DN of last certificate received: CN=TESTLABCA,dc=sso,dc=lab]

[06/17/2016][10:41:34][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][][getAllCAcerts][Number of CA certificates copied to output:1]

[06/17/2016][10:41:34][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][][getAllCAcerts][Obtained CA certificates from policy server. Total Certs received: 1]

[06/17/2016][10:41:34][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][][dispatchMessage][Sending the following message to the remote entity:






[Message: <?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=""><SOAP-ENV:Body>

<ArtifactResolve ID="_bc1053366a5957c509cdea0fa01106c33401" IssueInstant="2016-06-17T10:41:32Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">

    <ns1:Issuer xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion">http://www.partner.lab</ns1:Issuer>







SP then received the Response as below

[06/17/2016][10:41:38][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][][dispatchMessage][Received the following response from the remote entity: [Status Line: HTTP/1.1 200 OK




[Headers:{Date=Fri, 17 Jun 2016 10:41:38 GMT, X-Powered-By=ASP.NET, Server=Microsoft-IIS/7.5, Connection=close, Content-Type=text/xml, Content-Length=2475}]






[Message: <?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=""><SOAP-ENV:Body>

<ArtifactResponse ID="_1bcda2111cb2aab1b29edc449f2e5b3dff2e" InResponseTo="_bc1053366a5957c509cdea0fa01106c33401" IssueInstant="2016-06-17T10:41:38Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">

    <ns1:Issuer xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion">http://www.sso.lab</ns1:Issuer>


        <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>


<Response Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_c19dfabe5c2764afa8eb26a6142db3f9d222" IssueInstant="2016-06-17T10:41:32Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">

    <ns1:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion">http://www.sso.lab</ns1:Issuer>


        <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>


    <ns2:Assertion ID="_cb460f92ffbdd2d3641adbc24832f6fe7bd7" IssueInstant="2016-06-17T10:41:32Z" Version="2.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion">

        <ns2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.sso.lab</ns2:Issuer>


            <ns2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user1@sso.lab</ns2:NameID>

            <ns2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                <ns2:SubjectConfirmationData NotOnOrAfter="2016-06-17T10:43:02Z" Recipient="https://www.partner.lab/affwebservices/public/saml2assertionconsumer"/>



        <ns2:Conditions NotBefore="2016-06-17T10:41:02Z" NotOnOrAfter="2016-06-17T10:43:02Z">





        <ns2:AuthnStatement AuthnInstant="2016-06-17T10:41:32Z" SessionIndex="txYr5/mXnanQ+9xkc53oleloI2I=3ChwWQ==" SessionNotOnOrAfter="2016-06-17T10:43:02Z">












Hopefully this gives you some idea on how the federation works and what are the differences between SAML Post Profile and SAML Artifact Profile.


Next article will cover SLO.