SungHoon_Kim

Federation Starters 7

Blog Post created by SungHoon_Kim Employee on Jun 21, 2016

This is continuation from Federation Starters 6

 

SAML2 Post and Artifact profiles are both covered now.

Next is to demonstrate the SLO.

 

In case of SLO, I will firstly demonstrate One IDP vs One SP SLO use case.

After that I will add one more SP and demonstrate how it works differently.

 

It will get a bit complicated but fiddler trace will help you to understand the flow.

 

As we have already tried both POST and Artifact Profile, I will use POST profile for demonstrating the SLO.

You should already be familiar with what is setup. Please refer to previous articles for what is required for Post Profile.

 

What you need to ensure is that the Authentication URL remains persistent realm.

 

Following is the IDP Side Entities

Local SAML2 IDP Entity

Remote SAML2 SP Entity

Note that we use same URL(https://www.partner.lab/affwebservices/public/saml2slo) for both Location URL and Response Location URL.

Other federation products may use different URLs so you may need to enter the respective values when federating with other federation products.

 

Following is the SP Side Entities

Local SAML2 SP Entity

Remote SAML2 IDP Entity

Note that we use same URL(https://www.sso.lab/affwebservices/public/saml2slo) for both Location URL and Response Location URL.

Other federation products may use different URLs so you may need to enter the respective values when federating with other federation products.

 

Then load the entities updates from the Partnership configuration as below.

Following is IDP side Partnership. Click "Get Updates" to load the changes from Entities.

 

Following is SP side Partnership. Click "Get Updates" to load the changes from Entities.

 

Following is SSO2PARTNER Partnership (IDP Side)

SSO2PARTNER.png

 

Following is the PARTNER2SSO Partnership configuration(SP Side)

PARTNER2SSO.png

 

Following is a screenshot from fiddler demonstrating the federation and then SLO.

From Line #1 to #14, you are already familiar because that was the SAML 2.0 POST Profile use case.

And it is IDP initiated federation.

From #15 to #26 is SLO.

It is SP initiated SLO.

 

https://www.partner.lab/affwebservices/public/saml2slo

Accessing above session would initiate SLO.

You can see the SP side has already logged out the user, seeing the SMSESSION=LOGGEDOFF

But you would also see the SESSIONSIGNOUT cookie is generated which actually has the SMSESSION cookie value.

You see SMSLOGUID=29048166-7d2c9d73-5c1d08e8-0942e8ef-1e76d18b-38

This GUID is the SAML TransactionID that SP has generated for handling this SLO request.

Following is SP side FWSTrace.log showing the SAML TransactionID.

SP FWSTrace.log showing SAML TransactionID

[06/21/2016][06:49:38][5628][6180][][SLOService.java][doInitLog][------------------------------------------------]

[06/21/2016][06:49:38][5628][6180][][SLOService.java][doInitLog][SAML2 Single Logout Service Initialization.]

[06/21/2016][06:49:38][5628][6180][][SLOService.java][doInitLog][------------------------------------------------]

 

[06/21/2016][06:49:38][5628][6180][][FWSBase.java][getSLOGUIDCookie][Leaving [guid: 29048166-7d2c9d73-5c1d08e8-0942e8ef-1e76d18b-38]]

 

[06/21/2016][06:49:38][5628][6180][29048166-7d2c9d73-5c1d08e8-0942e8ef-1e76d18b-38][SLOService.java][handleLogout][RequestID 10853470-94ea2468-c6e4c2e2-88bcc0c6-bfe76136-0bd7 maps to TransactionID: 29048166-7d2c9d73-5c1d08e8-0942e8ef-1e76d18b-38.]

 

Since we have configured HTTP-Redirect mode for SLO, it redirects the browser to https://www.sso.lab/affwebservices/public/saml2slo with a SAMLRequest in the querystring.

You can decode it using Fiddler (From DeflatedSAML).

SLO SAMLRequest
<LogoutRequest NotOnOrAfter="2016-06-21T06:51:09Z" Destination="https://www.sso.lab/affwebservices/public/saml2slo" ID="_b0e320bdd06318f8dbe3c542df2a290fc514" IssueInstant="2016-06-21T06:49:39Z" 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><ns2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion">user1@sso.lab</ns2:NameID><SessionIndex>0ajVH8SOuADiqgPBUPSsyldH/FM=mI2X+g==</SessionIndex></LogoutRequest>

 

There are some important information here.

You should be familiar with the Destination, ID, Issuer and NameID.

What you need to look at now is the SessionIndex.

 

This 0ajVH8SOuADiqgPBUPSsyldH/FM=mI2X+g== SessionIndex value was actually included in the initial Assertion that was sent to SP for federation.

 

Following is the SAMLResponse(Assertion) that was POST'ed to SP at Fiddler Line #13.

SAMLResponse POST'ed to SP for federation containing SessionIndex info.

<Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_3235eec56be6d139bb4d55dce09fa94c60ba" IssueInstant="2016-06-21T06:49:08Z" Version="2.0">

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

    <Status>

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

    </Status>

    <ns2:Assertion xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_62d1eb118d52bd1cb5ae2cda36c66b70cc47" IssueInstant="2016-06-21T06:49:08Z" Version="2.0">

        <ns2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.sso.lab</ns2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#_62d1eb118d52bd1cb5ae2cda36c66b70cc47">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>QqsM7+Ys8xFCSAsBXRcJ2e1XOfw=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

g0ELkkeytLR65AkgG5yJ+/fk0CJuCmrVabb0i+A5QW+QKz5B9RCBjhzhefq28bxAzB9LkT2eBugv

CRd5UafsWQPIUuX2aw+h2nOYl5vShjJLhSi0urj1Kz9gc9qmy3WUM3csG8oQNcaYxdpO8M933K8M

rSjcLjJJmPV2tPC9PH3Joz17T4N4c6Vehol3Wjf9J3+/90kMvnj7I2PVqwc1dJrj5VJ/qPHu/tbp

53z5uInEQd4YQSXXZFe7DJPjJ1hh88tCDqhtWD/6ZSK/7dBO/AT6vUkA5jm4pXHjgEDUolrlsaAE

ZfTyP9oolX2eRiuaDM7jWgT8uQlJOsV/c/CDxA==

</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>

MIIE+jCCA+KgAwIBAgIKMCdtjgAAAAAACDANBgkqhkiG9w0BAQsFADA+MRMwEQYKCZImiZPyLGQB

GRYDbGFiMRMwEQYKCZImiZPyLGQBGRYDc3NvMRIwEAYDVQQDEwlURVNUTEFCQ0EwHhcNMTYwNjE0

MDkxOTA1WhcNMTgwNjE0MDkxOTA1WjAqMQwwCgYDVQQKEwNJRFAxDDAKBgNVBAsTA0lEUDEMMAoG

A1UEAxMDSURQMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArW7xhxeky328I7tDPI74

nTzU7mFqGx/Qg7LUm5Mde7jFSAIQvkCiXYshkNlSoehjmNtMc6+mAxk5UX8FWsJRc8m2MmsdTGsV

a6nZIge0Yko38fVrAZeCAfgWj1/CFaEAxrQVUSsZ4WpYiQbtQRvfBoGzQWzti+6gl1VnMuSEzBTM

FzSNrNb4BqwaEzapL6OHnK8vnmC+AKrpOXhM64iSa9jm++4dk54/BPxfE4wfFDJDa1S9aSDlQbk+

e/PTLh7gczQnNJDBFd/IjAHwxYT12gPkFh4q8E4c2OsdzTQIbvDQOaSFZH7b5sto466XtBqniSlJ

icz63yg2Fg8yPJaV+QIDAQABo4ICDDCCAggwDgYDVR0PAQH/BAQDAgWgMB0GA1UdDgQWBBRm74Cx

uTxaDKx82siNUpnkB0nmeDAfBgNVHSMEGDAWgBSFZxTPH0bC82lcJI7RaOZdZOzPbDCBwwYDVR0f

BIG7MIG4MIG1oIGyoIGvhoGsbGRhcDovLy9DTj1URVNUTEFCQ0EsQ049VEVTVE1DMSxDTj1DRFAs

Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE

Qz1zc28sREM9bGFiP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j

UkxEaXN0cmlidXRpb25Qb2ludDCBtwYIKwYBBQUHAQEEgaowgacwgaQGCCsGAQUFBzAChoGXbGRh

cDovLy9DTj1URVNUTEFCQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl

cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c3NvLERDPWxhYj9jQUNlcnRpZmljYXRlP2Jhc2U/

b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi

AFMAZQByAHYAZQByMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQAYCTC+

nfMTYom2H6ckQBzs89Lmt/tgfI5Y26iCFOyUAR60TfL4Nve5fzlfppn0Th1YfkFheq6wts9EJAJo

WQwpUPD8k4kyG1x/AS40Mr2P+rDQITD93Tucd6sQ1vaR3a7GiL7YlX4p7XecJu84uXMuylMDgX1n

vllzMOXN2pn9DZvfn/KNK2rk0p7TT8P/PmpCCFZWQz/IaMWcdXalceBDawIEGJD0OFRTO9w3bqGv

ed9NGYrJ+XGXpWYecRyQerAB5AUo/5R5x3Dba5W2Uu6o1d9UvSC9EzXePKOm4UbwTWxfvapoCcBt

piIYtSCrko+d01+LgZgQ+gGVjEJMWRUR

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

        <ns2:Subject>

            <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-21T06:50:37Z" Recipient="https://www.partner.lab/affwebservices/public/saml2assertionconsumer"/>

            </ns2:SubjectConfirmation>

        </ns2:Subject>

        <ns2:Conditions NotBefore="2016-06-21T06:48:37Z" NotOnOrAfter="2016-06-21T06:50:37Z">

            <ns2:AudienceRestriction>

                <ns2:Audience>http://www.partner.lab</ns2:Audience>

            </ns2:AudienceRestriction>

        </ns2:Conditions>

        <ns2:AuthnStatement AuthnInstant="2016-06-21T06:49:06Z" SessionIndex="0ajVH8SOuADiqgPBUPSsyldH/FM=mI2X+g==" SessionNotOnOrAfter="2016-06-21T06:50:37Z">

            <ns2:AuthnContext>

                <ns2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ns2:AuthnContextClassRef>

            </ns2:AuthnContext>

        </ns2:AuthnStatement>

    </ns2:Assertion>

</Response>

 

Where did this SessionIndex value come from?

This is the SessionID of the user when it was Authenticated at the IDP.

 

Following is smtracedefault.log showing the entry when the user was authenticated.

IDP Side smtracedefault.log for user authentication

[06/21/2016][16:49:06][3976][s67/r6][Sm_Auth_Message.cpp:5132][CSm_Auth_Message::FormatAttribute][user1][CN=user1,OU=People,DC=sso,DC=lab][SSO LAB Domain Users][][][][][Authentication URL][][][][][www.sso.lab][Send response attribute 205, data size is 28][1572][16:49:06.848][][][agent.iis][][][][][][][][][][][Login Form for www.sso.lab][][][][][06-a1701534-349b-41e0-bf08-8599a4aa1d2d][][][][][][][][][][][Login][0ajVH8SOuADiqgPBUPSsyldH/FM=][30 61 6a 56 48 38 53 4f 75 41 44 69 71 67 50 42 55 50 53 73 79 6c 64 48 2f 46 4d 3d ][][][][][][][][][][][][]

 

Since the IDP side has sent the sessionID information to SP, SP is able to send back that session information to IDP to logout.

 

Once this SLO request(SAMLRequest) is received at the IDP, IDP will logout the session and send SAMLResponse to SP notifying the user session has successfully logged out.

 

You can see in fiddler line #23 the SMSESSION is set to LOGGEDOFF and SESSIONSIGNOUT also set to LOGGEDOFF

SESSIONSIGNOUT cookie did not exist before, it is set during SLO and it is set to LOGGEDOFF when this entity has completed slo.

 

As there are only 2 entities involved, IDP knows there is no more partner it has to notify that the user session has to loggout, thus SESSIONSIGNOUT=LOGGEDOFF is set.

 

Now if you look at fiddler line #24, IDP has sent SAMLResponse to SP.

Following is the decoded SAMLResponse.

SAMLResponse from IDP to SP for SLO
<LogoutResponse Destination="https://www.partner.lab/affwebservices/public/saml2slo" ID="_eec488a088e0d7ae9ab2d7a260f4bc4ba8bb" InResponseTo="_b0e320bdd06318f8dbe3c542df2a290fc514" IssueInstant="2016-06-21T06:49:39Z" 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><Status><StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></Status></LogoutResponse>

 

IDP sent SAMLResponse to SP saying Logout was a "Success".

SP side still had SESSIONSIGNOUT=<SESSION COOKIE VALUE> although it had SMSESSION=LOGGEDOFF.

 

So, you can see this time SP is also setting SESSIONSIGNOUT=LOGGEDOFF

 

This is end of SLO, the only thing remaining is the redirect to SLO Confirmation page specified at the SP side.

What you need to note is that, when SP1 has initiated the SLO, the final confirmation from IDP that all sessions have been logged out must be notified back to SP1.

This also ensures the SP1 can redirect the user to its SLO Confirmation Page.

 

If SP2 initiated the SLO, IDP must respond back to SP2 that all sessions have been logged out and SP2 will redirect the browser to its configured SLO Confirmation Page.

 

I am attaching sso_and_slo.zip which contains the fiddler trace and logs matching this demo transactions.

 

In the next article, I will add another Service Provider and demonstrate the difference having just 1 SP and having multiple SP.

 

And I will also demonstrate how the user attributes can be sent over via Assertion.

Attachments

Outcomes