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

Federation Starters 9

Posted by SungHoon_Kim Employee Jun 24, 2016

This is continuation from Federation Starters 8


In the previous articles, IDP1, SP1 and SP2 were configured and tested to work.

This time it is a demonstration of SLO when there are multiple entities involved.


Use case:


User1 federates to SP1 first.

Then later user1 federates to SP2 as well.

Later user1 initiates SLO from SP2.


Unfortunately, it did not work and got HTTP 500 at SP2.

You know what to do


Lookup TransactionID 24ba1b28-9e4abd80-918d59bd-daf0153f-1b66e2aa-99d at SP2's FWSTrace.log


It says "SAML Assertion based user authentication failed.".

This is generic message so you need to look at SP2's smtracedefault.log to understand why.


smtracedefault.log at SP2
[06/24/2016][10:27:31][5684][24ba1b28-9e4abd80-918d59bd-daf0153f-1b66e2aa-99d][][checkAssertion][][][][][Assertion rejected (_fe167b7e6c525709b5ab0d54e404a652b8df) - AuthnInstant (Fri Jun 24 10:30:51 AEST 2016) occurs in future after current time {Fri Jun 24 10:27:31 AEST 2016)]


Obviously it is time synchronization issue.

IDP time:

SP2 time:

As you can see there is time difference.

There is "Skew" time setting that you can increase (which is default 60 seconds) to accommodate time issues but it is best that every entity involved would use time server to sync the time.


This is very common issue.

2 very common issue that breaks federation that was working fine are:

1. Expired certificate

2. Time sync issue


After syncing the time, the federation to SP2 also worked.


I will now initiate SLO from SP2(www.service.lab).


When user1 federated to SP1, the user1's sessionID was 4AKEBnc33S837y1j9Xr9qHvIEIU= so this information is sent to SP1 in the assertion as below.

When user1 federates to SP2, the same SessionID is sent as well.

This time I will show it from fiddler trace.


So, SP1 and SP2 has received the same SessionID information.

IDP side would also have a reference in the session store about these so IDP knows if it needs to SLO it knows which federation partners must be notified.


Then I initiated SLO from SP2.

What you see from fiddler trace is :

1. SMSESSION cookie value gets copied and set in SESSIONSIGNOUT cookie.

2. SMSESSION cookie get set to LOGGEDOFF

3. SMSLOGUID cookie is set

4. SP2 generates SAMLRequest and sends it to IDP (via HTTP-Redirect)

The SLORequest is sending the SessionID information as you can see below.


IDP has received this request and it does the same.

But you must note that IDP has not sent SAMLResponse back to SP2 just yet.

It is sending SAMLRequest to SP1.


The SAMLRequest is another LogoutRequest.

IDP is telling SP1 to logout that user.

When IDP is sending LogoutRequest, the SP side don't have to store the SMSESSION cookie value in SESSIONSIGNOUT cookie because it is FINAL.


So, at this point after SP2 initiated SLO:


* SLO not fully finalized. Local SMSESSION cookie value was stored in SESSIONSIGNOUT cookie.

* SAMLRequest sent to IDP and has not yet received SAMLResponse back yet



* SLO not fully finalized. Local SMSESSION cookie value was stored in SESSIONSIGNOUT cookie.

* Did not send SAMLResponse back to SP2 yet, waiting to finalize with other involved SP(SP1).

* Sent SAMLRequest to SP1 to logout the user1 session.



* IDP sent SAMLRequest instructing SP1 to logout the user and the user.


What should happen next is for SP1 to Logout the user1's session and report back to IDP.

IDP then complete the logout and send SAMLResponse back to SP2 informing the logout was complete.

SP2 then completes the logout and redirect the user to SP2's SLOConfirmation url.


SP1 is indeed setting the SMSESSION and SESSIONSIGNOUT cookies to LOGGEDOFF.

(Not sure why it still sets a new SMSESSION cookie though, it is also setting SMSLOGUID to a GUID and also deleting it)

And after finalizing the logout it generates SAMLResponse and sends it to IDP to inform it had SLO completed.



IDP completes SLO by setting SESSIONSIGNOUT and SMSESSION to LOGGEDOFF (it had previously set SMSESSION to LOGGEDOFF but had session cookie value copied to SESSIONSIGNOUT).

It is also deleting SMSLOGUID cookie.


It generates SAMLResponse and sends it to SP2.



SP2 receives SAMLResponse from IDP and completing the SLO by setting SESSIONSIGNOUT and SMSESSION to LOGGEDOFF (previously SMSESSION was set to LOGGEDOFF and session cookie value was copied to SESSIONSIGNOUT).

SMSLOGUID is also removed.


This is the END of SLO and finally SP2 redirects browser to the SLO Confirmation Page.


For your information, it depends on which entity you initiate the SLO.

If you initiated from SP1, you would be redirected to SP1's SLOConfirmationURL in the end.


Hope these articles were helpful to kickstart your federation interest and understand a little better.


I also had an issue today about Impersonation and Federation.

This is not supported.

What happens is, when the impersonatee visits /affwebservices/public/saml2sso, the user's session would be logged out because the Policy Server will fail validation.


/affwebservices/public realm do not have impersonation rules so it is not certain if creating those rules there would get it to work but it is something that QA has not tested to certify.


In the future article, I will demonstrate how to pass user attributes from IDP to SP.

(Passing text values and binary values)

And SP to set headers based on the attributes received from assertion.