Federation Starters 5

Blog Post created by SungHoon_Kim Employee on 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.