Skip navigation
All People > SungHoon_Kim > Sung Hoon Kim's Blog > 2016 > June > 17

Federation Starters 6

Posted by SungHoon_Kim Employee 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.


Federation Starters 5

Posted by SungHoon_Kim Employee Jun 17, 2016

This is continuation from Federation Starters 4


I will be demonstrating the SAML 2.0 Artifact Profile(SAMLResponse is delivered via SSL Backchannel).

Previous was SAML 2.0 Post Profile (browser posts SAMLResponse to Service Provider).


Personally, SAML 2.0 Artifact is more secure because the information does not go through the browser so there is less chance it(SAMLRequest and SAMLResponse) can be accessed by other people.

However, because it goes through separate channel, it is harder to troubleshoot if something goes wrong.


In order to setup Artifact Profile, your IDP must be listening on HTTPS.

Our setup already has that so we will skip this.

Important part is, the SP side federation web services must TRUST the IDP side https certificate's issuer.


Otherwise, they are the almost the same.


Following are required for SAML 2.0 Artifact Profile.


In the previous articles, the IDP initiated and SP initiated share common configuration.


I will try to create new objects to demonstrate the whole setup so it will be more clearer.

Now all the partnerships and entities are deleted.


Again we go back to the drawing board as below.




IDP Side(Having user accounts)

AD as user store

Test user account: SSO\user1

NameID to be used: email address (user1@sso.lab)

Policy Server: R12.52SP1CR2

WebAgent: R12.52SP1CR1 (On IIS 7.5)

WebAgent OptionPack: R12.52SP1CR2

WAS: NewAtlanta ServletExec 6.0

64bit JDK for NewAtlanta/WAOP

32bit JDK for Policy Server

WebServer URL: https://www.sso.lab


SP Side(Having application)

CADirectory as userstore

Test user account: user1

NameID to be searched: email address(user1@sso.lab)

Policy Server: R12.52SP1CR2

SPS: R12.52SP1CR2 (Includes WebServer/WA/WAOP/WAS)

32bit JDK for Policy Server and SPS

WebServer URL: https://www.partner.lab


Create IDP side configuration.


1. Deploy affwebservices on NewAtlanta Servletexec (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 but need additional configuration)

8. Rule/Resource (already done)

9. Policy/Role (already done)

10. Session Store (This is now a requirement! It must be configured and enabled!)

11. Entity(Local and Remote)

12. Partnership


You need to document the following agreed by both IDP and SP.


1. EntityID

2. Which keys to sign and verify (This is optional in this case)

3. Federation URLs (Federation SSO, Assertion Consumer Service, SLO Service, SLO confirmation URL)

4. What will be used as NameID value

5. Whether additional part of document will be signed

6. Whether encryption will be configured (which key to decrypt and which cert to encrypt)

7. Whether RelayState(Deeplinking) will be allowed.

8. What will be the "Audience" value.

9. IMPORTANT! Certificate(and its chain) used for HTTPS connection to IDP's Federation Web Services must be shared with SP. This is for "SSL BackChannel" which SP side Federation Web Services will connect to IDP's Federation Web Services to fetch Assertion. SP need to import IDP's CA certificate to establish trust to make ssl connection.

10. Whether SAML Artifact Profile will be used or SAML Post Profile will be used.(In this use case we are using Artifact Profile)

11. Whether SP will use HTTP-Redirect mode to send AuthnRequest to IDP or use HTTP-POST. (In this use case, we will select HTTP-Redirect mode)


Since everything is agreed we can start setting up the IDP side of Federation objects.

Skipping 1~6.


10. Session Store (This is now a requirement!)

Although this was in the step 10, it requires to be enabled first.

Run "smconsole" and check "Data" tab and select "Session Store" from Database dropdown list.


As you can see it is not enabled yet. The Session Store DB instance was setup(it requires sql authentication such as "sa" user) and "C:\Program Files (x86)\CA\siteminder\db\SQL\sm_mssql_ss.sql" was run to have it ready for use.


DSN need to be created so Policy Server can access it.


Run "C:\Windows\SysWOW64\odbcad32.exe" to load 32bit "ODBC Data Source Administrator" console.

Click "Add" and create a new DSN entry.





Select "SiteMinder SQL Server Wire Protocol". "SQL Server" or "SQL Server Native Client 11.0" will also work but it is not supported configuration. You must select SiteMinder driver!


Enter the DSN "SiteMinder Session Data Source", you can enter what you want to call it but you must ensure you enter the same at the smconsole.

Now "SiteMinder Session Data Source" DSN entry is created.


Go back to smconsole and ensure "Session Store enabled" is checked!!!


Enter the same info and click "Test Connection" and verify the connection was successful.

Click Apply and OK to save then restart the Policy Server service.


If you see the above entries in the smps.log then session store is enabled.


7. Realm/Component (already done but need additional configuration)



This is the "Authentication URL" Realm.

Click on "Advanced Settings..." button to show more settings.







Submit and save. This will ensure when the user is authenticated, they will be generating session in the session store. User should have accessed one of the persistent realm at least once before initiating federation.

What happens is, when assertion is generated, the user must have session in the session store and the assertion gets saved in the session store.


Next is to setup the Entity and Partnership.

The steps are not much different from previous POST Profile use case.


11. Entity(Local and Remote)


No signing required so there are no keys selected.



Now create Remote SP Entity.

HTTP-Artifact URL is same as HTTP-POST. They all goto saml2assertionconsumer


Both entities created as below.


12. Partnership

Create "SAML2 IDP => SP" Partnership.


This time I am allowing all users to generate assertion.





Note above the "SSO Binding" is "HTTP-Artifact".

Both IDP and SP initiated federation are allowed.


When SP connects to IDP via "SSL BackChannel", you have option to let anyone access and try fetching the assertion or you can enforce authentication method like "Basic" or "Certificate".

I chose "Basic" as that is usually sufficient, obviously it is over ssl.

In Basic Authentication, you can either enter the userID of your choice or option to use Partnership Name as userID.

I chose to use Partnership Name. So it will be "SSO2PARTNER" and you need to enter a password of your choice.


You must enter the same information at the SP side so they submit the correct credential.




Nothing to sign so nothing here.



I will continue with SP side configuration in next article.