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

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][Saml2Validator.java][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:

SP2:

* 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

 

IDP:

* 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.

 

SP1:

* 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.

SungHoon_Kim

Federation Starters 8

Posted by SungHoon_Kim Employee Jun 23, 2016

This is continuation from Federation Starters 7

 

Previously we looked at how SLO works when there are 1 IDP and 1 SP.

In this article, I am adding one more Federation Entity(http://www.service.lab) to demonstrate how SLO works when there are multiple SPs involved.

 

Before we proceed, I would like to comment on one of the limitation in SiteMinder.

You cannot configure multiple partnership for Remote Entity that has same EntityID.

For example, in the following use case, you can activate PARTNER2SSO or SERVICE2SSO one at a time but not both at the same time.

 

You will get an error below.

This will be enhanced in the future version.

 

As such, I need to setup SP2 on a separate machine(which is more realistic).

 

Following is what is installed for this SP2(http://www.service.lab)

Following configuration is required for SP2. I am installing 32bit apache and tomcat for demonstration purpose. You can install 64bit. Note that WA and WAOP also must match the bitness.

 

1. Install ASF Apache 2.4 32bit (refer to How to check the default stack size of httpd.exe)

2. Deploy affwebservices on Apache Tomcat7 32bit (Install the ZIP version)

3. Copy affwebservices folder to a separate folder and deploy (I am placing it under tomcat)

4. Modify affwebservices.properties

5. Modify LoggerConfig.properties

6. User Store

7. Authentication Scheme

8. Domain/Application

9. Realm/Component

10. Rule/Resource

11. Policy/Role

12. Session Store (SLO feature requires it)

13. Import existing ServiceLab's key pair for signing and import IDP's signature verification cert and its chain.

14. Entity(Local and Remote)

15. Partnership

 

Additional Configuration required at the IDP

 

1. Import any certificates or its certificate chain SP2 has provided

2. Entity for SP2 Remote SP

3. Partnership for SP2

 

Components installed at SP2 for this partnership.

(Installed on All-In-One image so using back the existing PS/WA/WAOP)

 

1. PS R12.52SP1CR1

2. WA R12.52SP1CR1 32bit

3. Tomcat7

4. JDK 1.7.0_80 32bit

5. Apache 2.4.20 32bit (Used editbin to increase the stacksize to 512KB as documented)

 

Let's configure SP side configuration.

 

1. Install ASF Apache 2.4 (refer to How to check the default stack size of httpd.exe)

 

I downloaded ASF Apache 2.4 and increased the stack size.

Ran agent configuration wizard and configured Apache.

Verified it is able to startup after agent is configured.

I did not configure mod_proxy_ajp nor mod_jk so this Apache does not proxy requests to tomcat.

What this means is that the HTTP_HOST value will be different when accessing affwebservices.

 

2. Deploy affwebservices on Apache Tomcat7 (Install the ZIP version)

 

Tomcat7 is extracted to C:\apache-tomcat-7.0.70

Environment Variables set

CATALINA_BASE=C:\apache-tomcat-7.0.70

CATALINA_HOME=C:\apache-tomcat-7.0.70

CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_HOME%\bin\tomcat-juli.jar

JAVA_HOME=C:\CA\jdk1.7.0_80

JRE_HOME=CA\jre1.7.0_80

JVM=CA\jre1.7.0_80\bin\server\jvm.dll

Run tomcat7w.exe to check the configuration.

 

 

I can now access tomcat via http://www.service.lab:38080

 

 

3. Copy affwebservices folder to a separate folder and deploy (I am placing it under tomcat)

 

For deploying affwebservices on an application server, you can create a war file of the affwebservices folder or you can copy the affwebservices folder.

You can also use the "C:\CA\webagent\affwebservices" folder as well.

 

So, you I copied this "affwebservices" folder to "C:\apache-tomcat-7.0.70\affwebservices" so it can be configured separately.

 

Click on "Manager App" button at Tomcat Admin Console.

At the "Deply" section, enter the required information and deploy.

 

4. Modify affwebservices.properties

Once deployed, the affwebservices folder is now copied to "C:\apache-tomcat-7.0.70\webapps\affwebservices" so you must change the config files under this folder.

 

Point it to a valid WebAgent.conf file.

I am pointing it to WebAgent.conf that was generated for Apache Web Server.

 

5. Modify LoggerConfig.properties

 

Enable affwebservices.log and FWSTrace.log filepath is updated correctly.

I am logging them in C:\Apache24\logs\ folder.

 

Restart affwebservices.

(Another way is to modify properties files under "C:\apache-tomcat-7.0.70\affwebservices" folder and redeploy)

 

Try testing the webservice to see if it initializes correctly.

visit http://www.service.lab:38080/affwebservices/public/saml2sso

If you are getting HTTP 400 and not HTTP 500 then it is a good sign that it is working.

 

6. User Store

 

This userstore has a test user "cn=Sung Hoon"as below.

This user's ID is "sung hoon"

It does have "displayName" attribute having "user1@sso.lab" value.

 

7. Authentication Scheme

 

 

8. Domain/Application

9. Realm/Component

10. Rule/Resource

11. Policy/Role

 

From 8 to 11, please protect /application/ and assign the above authentication scheme and authorize all users for convenience.

 

12. Session Store (SLO feature requires it)

This is already enabled.

 

13. Import existing ServiceLab's key pair for signing and import IDP's signature verification cert and its chain.

Firstly, import the CA certificate.

Then import the IDP's signing certificate(www_sso_lab) so SP can verify the signature.

You can see "servicelabkey" is the keypair for this SP2.

 

 

14. Entity(Local and Remote)

 

Create SAML2 Remote IDP as below.

 

For Local SP, it need to be created new.

 

Please note the difference here because the "Base URL" is now "http://www.service.lab:38080

And this is not https because I did not install a certificate on the tomcat. Certificate is installed only on the apache web server.

 

15. Partnership

 

Create "SAML2 SP to IDP" partnership.

 

I will cover XPath in future articles with some good use cases.

XPath Expression Syntax    This is a good reference giving you an idea what you can do with XPATH

Simple online XPath tester    When using this tool, make sure you remove all namespaces.

 

 

Following is a full configuration view of SERVICE2SSO Partnership.

 

service2sso.png

 

Let's move on to IDP side configuration.

 

1. Import any certificates or its certificate chain SP2 has provided

 

The CA Certificate is already imported since they are all using TESTLABCA so it is skipped.

Now, import the Certificate provided by SP2 for signature verification or encryption.

 

2. Entity for SP2, Remote SP

 

 

3. Partnership for SP2

 

Create "SAML2 IDP to SP" partnership.

 

 

Following is the full configuration view for SSO2SERVICE partnership.

sso2service.png

 

Now, activate all the partnerships.

 

Test SSO2SERVICE partnership works and SLO works as well.

 

Unfortunately, SSO2SERVICE did not work. But this gives us an opportunity to troubleshoot.

First thing is to look at fiddler.

 

Copy the TransactionID that reports the error and look at the FWSTrace.log at the SP2(www.service.lab)

 

 

It says "SAML Assertion based user authentication failed." and this can be due to so many reasons.

Firstly I would check if the IDP and SP2 has time in sync.

While the time is being checked, goto SP2's smtracedefault.log(using samlsp_trace.template) and look up the same TransactionID.

 

smtracedefault.log(samlsp_trace.template)

[06/23/2016][16:26:37][2320][136832b1-1affeffe-966093fd-889c79b3-fe431343-916][Saml2Validator.java][verifyXML][][][][][Cert to verify sig: samlConfigData.metaSerialNumber: "19abad70000000000004"   samlConfigData.metaIssuerName: "CN=TESTLABCA, DC=sso, DC=lab"]

[06/23/2016][16:26:37][2320][136832b1-1affeffe-966093fd-889c79b3-fe431343-916][Saml2Validator.java][checkAssertion][][][][][SAML20: Assertion rejected (_5e60f9c8455741968390611c18f09acc3b62): DSigException caught while verifying assertion: Error in DSigVerifier: cert not found or sig not verified - Caught an Exception either finding certificate in DB or verifying using IXMLSignature implementor - Certificate from Database does not match the Certificate in message.]

 

Policy Server says "Certificate from Database does not match the Certificate in message".

Since the certificate in the message is suspected, I extracted the certificate part of the message and saved it as test.cer on my desktop and double clicked on it to see what could be the problem.

 

Well, surprise surprise!

Where did I get this certificate from.... (so let's pretend the IDP side gave me the wrong certificate )

You can see the Issuer is the same but the Serial number value is different.

The one that came with the message end with 08.

The one I imported at SP2 for signature verification ends with 04.

 

I need to import this certificate that came with the message and use it to verify the signature.

I imported this certificate in SP2 using "ssolab" alias.

Deactivated the SERVICE2SSO partnership and assigned this certificate for signature verification.

 

Save the partnership and activate.

 

 

So, this time I retried and you can see from fiddler line #18~21 that the federation was successful.

 

You would have also noted here that when the user already had IDP session, initiating federation at the saml2sso application did not redirect the browser to the AuthenticationURL.

 

It is an expected behavior so no surprise.

 

Now, lets try SLO and see if it is successful.

Unfortunately, it did not succeed. And it did not give me the TransactionID that caused error.

In this case, you need to copy the SAMLRequest querystring and do a search at the IDP side(www.sso.lab) FWSTrace.log and you can find the TransactionID.

 

Now, you found the request that resulted in error.

 

If you look at that TransactionID 3b27dd80-d466420b-89e438a3-0167163e-c484b256-d2 it says "Signature is invalid on an SLO message"

 

So, it appears I messed up certificate again.

When you are checking for Signature, following 3 information are always the most critical.

1. Is it trusted? (Certificate Chain)

2. Who issued it? (IssuerDN)

3. Serial Number? (SubjectDN is not that important, Serial Number and IssuerDN is the definite Identity of a certificate)

 

I need to compare the certificate again.

SP Side Signing Key info as below.

 

 

IDP Side Certificate List view.

The correct certificate alias is "servicelab" and at the right end, I can see that this certificate is not associated with ANY partnership so that must be the problem.

 

Looking at the IDP's partnership SSO2SERVICE, wrong certificate was assigned for signature verification as below.

I am switching that to "servicelab" certificate.

 

Federation worked and SLO worked as well.

 

So, we have successfully configured 1 IDP and 2 SP.

In the next article I will demonstrate SLO involving multiple SP.

SungHoon_Kim

Federation Starters 7

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

SungHoon_Kim

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 affwebservices.properties (already done)

3. Modify LoggerConfig.properties (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][FederationTunnelClient.java][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][FederationTunnelClient.java][getAllCAcerts][Number of CA certificates copied to output:1]

[06/17/2016][10:41:34][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][FWSBase.java][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][MessageDispatcher.java][dispatchMessage][Sending the following message to the remote entity:

 

 

[Headers:{SOAPAction=http://www.oasis-open.org/committees/security}]

 

 

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

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><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>

    <Artifact>AAQAAIiA4taf5jz41x0bwoyXaX53YAKTtxYr5/mXnanQ+9xkc53olUJRDgQ=</Artifact>

</ArtifactResolve>

 

 

</SOAP-ENV:Body></SOAP-ENV:Envelope>].]

 

SP then received the Response as below

[06/17/2016][10:41:38][7628][7324][6826e6f8-28e70e03-40336b3d-173638b4-36e45e7d-49][MessageDispatcher.java][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}]

 

 

[Cookies:{}]

 

 

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

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><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>

    <Status>

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

    </Status>

<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>

    <Status>

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

    </Status>

    <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: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-17T10:43:02Z" Recipient="https://www.partner.lab/affwebservices/public/saml2assertionconsumer"/>

            </ns2:SubjectConfirmation>

        </ns2:Subject>

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

            <ns2:AudienceRestriction>

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

            </ns2:AudienceRestriction>

        </ns2:Conditions>

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

            <ns2:AuthnContext>

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

            </ns2:AuthnContext>

        </ns2:AuthnStatement>

    </ns2:Assertion>

</Response>

</ArtifactResponse>

 

 

</SOAP-ENV:Body></SOAP-ENV:Envelope>].]

 

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.

SungHoon_Kim

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.

 

Environment:

 

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 affwebservices.properties (already done)

3. Modify LoggerConfig.properties (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.

 

SungHoon_Kim

Federation Starters 4

Posted by SungHoon_Kim Employee Jun 16, 2016


This is continuation from Federation Starters 3

 

I will be demonstrating how to setup SP Initiated Federation.

And in this case, I will have SP to sign the AuthenRequest before sending it to IDP.

How to know if the captured fiddler is showing SP Initiated Federation? If you see "SAMLRequest" then it is SP Initiated Federation which is also called AuthnRequest.

 

It is initiated by accessing the following URL.

https://www.partner.lab/affwebservices/public/saml2authnrequest?ProviderID=http://www.sso.lab

 

But in the current setup, because SP Initiated Federation is not configured and is not allowed, you will get HTTP 403 if you try.

FWSTrace.log explains the error as below.

FWSTrace.log

[06/16/2016][00:07:41][4528][4224][1923ca15-462c7640-37751807-272dc88e-721b5c36-1cc][AuthnRequest.java][processRequest][SP initiated requests are not supported for SP http://www.partner.lab.]

[06/16/2016][00:07:41][4528][4224][1923ca15-462c7640-37751807-272dc88e-721b5c36-1cc][AuthnRequest.java][processRequest][Ending SAML2 AuthnRequest Service request processing with HTTP error 403]

 

As the federation is already setup, following are the actions I will perform to enable SP initiated federation.

SP side to sign the AuthnRequest is not required but that is additional thing I will be doing.

 

SP Side Configuration:

1. Import existing key pair(since we already tried generating one from AdminUI) for SP side to sign the AuthnRequest. Again, this is optional. And as federation is an agreement, IDP side need to be informed that you will be signing the AuthnRequest and provide them the certificate for them to use for signature verification.

2. Configure SP Side Partnership to allow SP Initiated Federation.

3. Configure SP Side Partnership by assigning the keypair for signing.

 

 

IDP Side Configuration:

1. Import SP signing certificate for verification

2. Configure IDP to allow SP Initiated Federation

3. Configure IDP Side Partnership to use that SP certificate to verify the signature of AuthnRequest.

4. Configure IDP to accept only signed AuthnRequest. (Optional. Even if you did not enable this, if the AuthnRequest comes in signed, IDP will try verifying the signature anyway.)

 

Not really much here because the federation is already setup.

 

Let's perform the SP side configuration first.

1. Import existing key pair

Click "Import New"

You are seeing IDP's signing key but if you had configured SP on a separate policy server then you would see IDP side certificate(not key) and the Type should be "Certificate" not "Private Key and Certificate".

Just to note so that you won't be confused.

Since you are importing a key, you will have to enter the private key's passphrase to import the key.

The alias is automatically generated and is in a format of a GUID.

I am changing it to something more meaningful. No spaces allowed so it will be "SP_Side_Key".

I didn't have to import the "TESTLABCA" RootCA certificate as it was imported previously.

 

 

2. Configure SP Side Partnership to allow SP Initiated Federation.

Deactivate the "PARTNER2SSO" partnership first and then click "Modify".

Goto "SSO and SLO" step and change the "Transactions Allowed" from "IDP initiated only" to "Both IDP and SP initiated". You can also try the "SP initiated only".

 

3. Configure SP Side Partnership by assigning the keypair for signing.

Goto "Signature and Encryption" step

 

At the "Signing Private Key Alias" select "sp_side_key".

AND YOU MUST SELECT "Sign Authentication Requests". It is easy to forget this part.

 

I would encourage you to try out the encryption as well, but later

As you can see here, there are lots of options for you to explore.

 

Finish the partnership configuration and activate it.

Let's move on to IDP side configuration.

 

Deactivate the "SSO2PARTNER" partnership and modify.

 

1. Import SP signing certificate for verification

Well, because I am configuring on one policy server, SP side certificate is actually already imported.

So, we will skip this one.

 

2. Configure IDP to allow SP Initiated Federation

Goto "SSO and SLO" step and change the "Transactions Allowed" from "IDP initiated only" to "

 

3. Configure IDP Side Partnership to use that SP certificate to verify the signature of AuthnRequest.

4. Configure IDP to accept only signed AuthnRequest.

 

Goto "Signature and Encryption" step and select "sp_side_key" at "Verification Certificate Alias".

 

Complete the setup and activate the partnership.

 

Another round of test, this time it will be SP initiated.

Previously we got HTTP 403 and the reason was SP initiated federation was not allowed.

 

As you can see above, AuthnRequest was not rejected.

And by finding a SAMLRequest query parameter at saml2sso, you would know this was an SP Initiated Federation request.

 

If you want to know what that SAMLRequest was, you can use fiddler to decode the content.

It would not be able to help if the AuthnRequest is encrypted but our agreement was that there is no encryption involved.

URLEncode(Base64Encode(Deflate(AuthnRequest))) is how it is generated so you need to reverse the steps to extract plan-text AuthnRequest.

Fiddler does it for you.

AuthnRequest

<AuthnRequest Destination="https://www.sso.lab/affwebservices/public/saml2sso" ID="_f868558d6f75b940077a3c738c9712adca65" IssueInstant="2016-06-16T04:48:14Z" 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>

</AuthnRequest>

 

Basically there are 3 information.

1. Destination: This is where this message should be delivered to. Recipient must ensure that it was meant for them.

2. ID: This is the AuthnRequest ID. IDP must say "InResponseTo" and mention this ID value in the Assertion.

3. Issuer: This is the entityID that generated this AuthnRequest.

 

When you tried IDP initiated federation, the only information you needed was the SPID(SP's entityID).

https://www.sso.lab/affwebservices/public/saml2sso?SPID=http://www.partner.lab

 

So, AuthnRequest message delivers that information to IDP so the assertion can be generated for this partner(entityID).

 

Kelly raised a very interesting question.

If TARGET is not configured at the Service Provider side partnership configuration, and if RelayState is not allowed, what will happen?

 

I thought it would be an HTTP 500 condition but it was not.

If you do not specify the TARGET(which is acceptable), you should enable RelayState to override TARGET.

But, the moment you empty the TARGET, RelayState is accepted automatically.

However, if you do not specify the RelayState in the querystring, you do not have TARGET nor RelayState.

In this case, the result was HTTP 400 at the https://www.partner.lab/affwebservices/public/saml2assertionconsumer.

 

If you want to use a RelayState(deeplink) you can do it like this.

https://www.partner.lab/affwebservices/public/saml2authnrequest?ProviderID=http://www.sso.lab&RelayState=https://www.partner.lab/another_target/

 

When RelayState is received at the SP side and if RelayState is allowed, the RelayState url will be stored in SMFED_TEMPORARY_STATE cookie(encrypted).

 

SP will again read this cookie and say "cookie contains target:https://www.partner.lab/another_target/"

"targetURL:https://www.partner.lab/another_target/ usingRelayState: true"

 

 

Now, let's take a look at SAMLResponse value and see how to extract plain-text.

Again, if it is encrypted, you will not be able to get anything out using fiddler.

 

In the request Body, you will find SAMLResponse but because it is very long, the name was not visible.

You can see the value is there(long base64 string).

Send it to TextWizard.

From my testing, both "From Base64" and "From DeflatedSAML" were able to decode it.

But the correct way would be simply Base64 decode only.

SAMLResponse

<Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_9c1ece3b9e20f33d166dbce220ee0239ddeb" InResponseTo="_f868558d6f75b940077a3c738c9712adca65" IssueInstant="2016-06-16T04:48:34Z" 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="_0ecfa63f835cd2e920483a48ecfb1106d494" IssueInstant="2016-06-16T04:48:34Z" 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="#_0ecfa63f835cd2e920483a48ecfb1106d494">

<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>FQh0IfY30pYDbEPMx3yenPCMhnA=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

L/1vWEw/JKp/hF+60LnAK7bLRqUzPtFG83DAkM3cpNkcoI8MWDGKLjp0+HyX5d0kO5I24fuGcuVc

ceqYjepgChAZXSBJcRuuoZPisdqRciIrV5LFiuKy3hFhHZUYH4IZ2TovhC7+yw1YbBsxQNLap6Ch

v3JaivwKa3kF5FWRWAtQarLZr2p/rHsJ0WAahsHpR3YtnP+4I513+arB/XpABnxHKAfB3JbC4Tdf

T+RF8SUQVBOMt4WiZcJHE/WSh9c28QB0WYYsAraQlTTioNDQlvuB0XfuYo19XxIYTUn1lPCqeOpH

NaXAZL/kUZe5cPtaiv88pRkmCc5h45SvOS0YyA==

</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 InResponseTo="_f868558d6f75b940077a3c738c9712adca65" NotOnOrAfter="2016-06-16T04:50:03Z" Recipient="https://www.partner.lab/affwebservices/public/saml2assertionconsumer"/>

            </ns2:SubjectConfirmation>

        </ns2:Subject>

        <ns2:Conditions NotBefore="2016-06-16T04:48:03Z" NotOnOrAfter="2016-06-16T04:50:03Z">

            <ns2:AudienceRestriction>

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

            </ns2:AudienceRestriction>

        </ns2:Conditions>

        <ns2:AuthnStatement AuthnInstant="2016-06-16T04:48:33Z" SessionIndex="0bPw0g1eWIeZSojKJjAJgkyhtfY=e1ELQw==" SessionNotOnOrAfter="2016-06-16T04:50:03Z">

            <ns2:AuthnContext>

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

            </ns2:AuthnContext>

        </ns2:AuthnStatement>

    </ns2:Assertion>

</Response>

 

 

Again we are seeing 3 information, same as what we saw in the AuthnRequest.

Response ID. I mentioned that it has to say InResponseTo to the AuthnRequest ID _f868558d6f75b940077a3c738c9712adca65

You can see it here in the SAMLResponse.

 

Also there is Issuer.

It means http://www.sso.lab is the EntityID that generated this document.

 

And there is Recipient.

It means this message should be sent to https://www.partner.lab/affwebservices/public/saml2assertionconsumer

Recipient must verify that it was meant for this SP.

 

Now that IDP and SP initiated federation is working, I will demonstrate how to setup Artifact profile.

SungHoon_Kim

Federation Starters 3

Posted by SungHoon_Kim Employee Jun 15, 2016

This is a continuation from Federation Starters 2

 

Just to demonstrate that the IDP initiated federation can be tested without even having an SP, I took a screenshot of fiddler.

In the above fiddler trace, you can see that IDP initiated federation request(http://www.sso.lab/affwebservices/public/saml2sso?SPID=http://www.partner.lab) was received, redirected to Authentication URL.

User authenticated and redirect back to Authentication URL then redirect to saml2sso.

 

Next, it was reaching out to https://www.partner.lab:443, if IDP initiated federation request tries to connect to the SP site, it means it was trying to POST the assertion(SAMLResponse) so you can consider it as success for now.

 

Browser actually showed more info as below.

 

You can see that it was going to https://www.partner.lab/affwebservices/public/saml2assertionconsumer and this is where SP wanted to receive the SAMLResponse via POST.

 

Let's continue configuring the SP side.

 

Again, we need to perform the same steps below.

 

1. Deploy affwebservices on Application Server

2. Modify affwebservices.properties

3. Modify LoggerConfig.properties

4. User Store

5. Authentication Scheme

6. Domain/Application

7. Realm/Component

8. Rule/Resource

9. Policy/Role

10. Session Store (Not required if you only want to achieve Federation SSO and you do not need SLO)

11. Entity(Local and Remote)

12. Partnership

 

 

 

1. Deploy affwebservices on Application Server

 

This is already done while installing/configuring SPS server.

You would have been asked if you want to use Federation Gateway and if your Policy Server is 12.0 or 12.5.

This is already deployed and is one of the advantages to use SPS.

You do not need to worry about deploying on the application server.

 

2. Modify affwebservices.properties

 

The federation web services is deployed at "C:\Program Files (x86)\CA\secure-proxy\Tomcat\webapps\affwebservices"

So you can locate the file at "C:\Program Files (x86)\CA\secure-proxy\Tomcat\webapps\affwebservices\WEB-INF\classes\AffWebServices.properties"

C:\Program Files (x86)\CA\secure-proxy\Tomcat\webapps\affwebservices\WEB-INF\classes\AffWebServices.properties

 

 

AgentConfigLocation=C:\\Program Files (x86)\\CA\\secure-proxy\\proxy-engine\\conf\\defaultagent\\WebAgent.conf

This is also handled by the SPS configuration wizard so you don't have to change anything.

 

3. Modify LoggerConfig.properties

This is also found in the same folder.

 

C:\Program Files (x86)\CA\secure-proxy\Tomcat\webapps\affwebservices\WEB-INF\classes\LoggerConfig.properties

LoggingOn=Y

LogFileName=C:\\Program Files (x86)\\CA\\secure-proxy\\proxy-engine\\logs\\affwebserv.log

TracingOn=Y

TraceFileName=C:\\Program Files (x86)\\CA\\secure-proxy\\proxy-engine\\logs\\FWSTrace.log

TraceConfig=C:\\Program Files (x86)\\CA\\secure-proxy\\proxy-engine\\conf\\defaultagent\\FederationTrace.conf

 

Nothing much here, just need to ensure the Tracing is enabled.

 

4. User Store

 

I created following user directory dedicated to SP.

 

Note that the user search is using "uid" and not the "mail" attribute.

 

5. Authentication Scheme

 

Good thing about Partnership Federation is that the TARGET is protected using a regular authentication scheme. Legacy Federation requires that the TARGET be protected by SAML 2.0 Authentication Scheme.

 

 

 

6. Domain/Application

7. Realm/Component

8. Rule/Resource

9. Policy/Role

 

I am going to create Application called "www.partner.lab" and link the "SP Side User Store" to it.

I will be protecting /saml20/ as that will be the TARGET that I will be specifying in the federation partnership.

 

 

 

 

With what we configured so far, you can actually login to this https://www.partner.lab/saml20/ by submitting user1's credentials. There is no federation involved at this point. It is just ordinary SiteMinder protected resource.

 

11. Entity(Local and Remote)

Let's create the SP side Local and Remote Entity.

In this case, your LocalEntity will be Service Provider and RemoteEntity will be Identity Provider.

As I am creating all these in the same Policy Server, you will see IDP side configuration as well but please ignore.

 

Click "Create Entity" and select "Local" and "SAML2 SP".

 

 

Create Remote IDP Entity.

EntityID must match what was agreed.

EntityName is whatever you want to call it.

"Remote SSO Service" is HTTP-Redirect because we did not configure for HTTP-POST Authentication Request Binding.

"Remote SSO Service" is about how requests will go to saml2sso.

Supported NameID format was "Email Address" so select that one.

As SP must verify the signature on the Assertion, you must specify the IDP side certificate which was used for signing.

In this use case, because both configuration is in the same policy server you see the "idpsigningkey" but if you have separate SP configured then you would have to import the certificate and you can assign an alias of your choice.

Regardless, that certificate must be associated here for signature verification.

From above, only the highlighted ones are for the SP side configuration.

 

12. Partnership

 

Create Partnership "SAML2 SP -> IDP"

By default, "Use Name ID" is used. Whatever string received as NameID would be used as userID.

You can also specify XPath to programatically extract certain information in the assertion to make up a userID to use.

Note the "LDAP Search Specification", this is important part.

Because the NameID that we are expecting is an email address, you need to specify the "attributename=%s" to perform the search. In this case we use "mail=%s" which will guarantee the user1@sso.lab would find "user1" from "SP Side User Store".

 

And in the "Federated Users", I can simply say "All Users" but I have chosed to restrict to only the "OU=People,dc=sso,dc=lab". Well, we only have 1 user in that OU

 

Don't forget to activate the newly created partnership.

Now both partnerships are configured.

 

Let's test and see if it works.

Unfortunately, it did not work. But that gives us a chance to learn how to troubleshoot.

Based on the fiddler, the HTTP 500 is at the SP side https://www.partner.lab/affwebservices/public/saml2assertionconsumer

 

So, we must look at SP side logs first.

What I would look at is the affwebserv.log and FWSTrace.log

The first thing in the log, I will be searching for "6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49" because this is the TransactionID that logged the HTTP 500.

In most case, affwebservices.log gives hint to what could be the problem but in this case it reports

affwebserv.log

[4528/4224][Wed Jun 15 2016 10:33:11][AssertionConsumer.java][ERROR][sm-FedClient-01660] sm-FedClient-01660 (com.netegrity.affiliateminder.webservices.saml2.AssertionConsumer, doPost, java.lang.RuntimeException: java.net.URISyntaxException: Expected authority at index 8: https://, , )

[4528/4224][Wed Jun 15 2016 10:33:11][AssertionConsumer.java][ERROR][sm-FedClient-02890] sm-FedClient-02890 (6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49, ACS_EXCEP_DO_POST, , , )

 

It seems there is something missing in the received data.

 

FWSTrace.log

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][SAML2 AssertionConsumer Service received POST request.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][doRequestLog][Requesting Host: 192.168.201.104 Requesting Host IP: 192.168.201.104 Request protocol: HTTP/1.1 Request was secure: true Authentication type: null]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][Obtained response message from post data for http post binding [CHECKPOINT = SSOSAML2_READRESPONSEPOSTDATA_RSP]]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][createPostRequestContext][SAMLResponse parameter (base-64 encoded): PFJlc3BvbnNlIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIERl

 

 

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][SAMLResponse: <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_b27d347d8a87e57f65454274ef39876392c7" IssueInstant="2016-06-15T10:33:04Z" Version="2.0">

 

 

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][RelayState: null]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][RequestID: _b27d347d8a87e57f65454274ef39876392c7]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][ResponseID: _b27d347d8a87e57f65454274ef39876392c7]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][RequestID _b27d347d8a87e57f65454274ef39876392c7 maps to TransactionID: 6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][IDPID (Issuer): http://www.sso.lab]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAML2Base.java][getIdentityProviderInfo][Trying to fetch SAML2.0 IDP Configuration from cache [CHECKPOINT = SSOSAML2_IDPCONFFROMCACHE_REQ]]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAML2Base.java][getIdentityProviderInfo][SAML2.0 IDP Configuration is not in cache. Requesting to get from policy server [CHECKPOINT = SSOSAML2_IDPCONFFROMPS_REQ]]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAMLTunnelClient.java][getIdentityProviderInfoByID][Provider ID: http://www.sso.lab.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAMLTunnelClient.java][getIdentityProviderInfoByID][Tunnel result code: 1.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAMLTunnelClient.java][getIdentityProviderInfoByID][SAMLTunnelStatus: 0, ]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAMLTunnelClient.java][getIdentityProviderInfoByID][infoIdp: {IncomingBackChannelAuthType=2, ApplicationAttributeValueExps=, TargetOpenCookieEncPassword=<Value not shown>, IsActive=1, MniRequireEncryptedNameID=0, ApplicationAttributeNames=, UrlEncodeAttrCookieData=0, HidingMask=1, InvalidRedirectMode=0, PartnershipSource=3, EnableAuthnRequestRedirect=1, ValidateTargetURLDomain=0, BackChannelAuthType=2, SLOServiceValidityDuration=60, EnableSAMLRequester=0, UnauthorizedAccessRedirectMode=0, EnableSLOSOAPBinding=0, EnableSSOPostBinding=1, EnableServerErrorURL=0, MniSignRequest=0, TargetEnableOpenCookieHMAC=0, FailureRedirectMode=0, Password=<Value not shown>, TargetEnableQuotedOpenCookie=0, MniRequireSignedResponse=0, DSigVerInfoIssuerDN=CN=TESTLABCA, DC=sso, DC=lab, ProvisioningDeliveryType=3, Target=https://, AllowAuthLevelOverride=0, EnableAuthnRequestPost=0, AllowTransactionType=1, MniSOAPTimeout=60, SAMLReqRequireSignedAssertion=0, EnableSLORedirectBinding=0, EnforceSingleUsePolicy=0, RequireEncryptedAssertion=0, RedirectMode=0, AuthnContextUsage=1, RequireSignedArtifactResponse=0, MniRequireSignedRequest=0, CompareUserDNForSMC=1, DisableSignatureProcessing=0, EnableSMC=0, EnableRequestedAuthnContext=0, AssertionConsumerDefaultURL=06-24b16054-3382-4b1c-aff8-a9259584a485, MniRetryBoundary=15, MniRetryCount=3, MniEnableSOAPBinding=0, XPath=, QPOverridesReqAuthnContext=0, ProvOpenCookieEncPassword=<Value not shown>, NameIdType=0, RequireUserConsent=0, PersistSessionVars=0, SMCOverrideProtectionLevel=0, DSigVerInfoSerialNumber=30276d8e000000000008, Oid=21-de5fb651-8fa4-4047-af72-0aab7d8addc0, EncryptNameIDForSLOSOAP=0, AllowIdPtoCreateUserIdentifier=0, DelegatedAuthHashSecret=<Value not shown>, MniEncryptNameID=0, SignArtifactResolve=0, MniAllowUserSelfService=0, MniNotificationAuthType=1, SSOArtifactIndex=1, SPID=http://www.partner.lab, MniEnableNotification=0, SAMLReqGetAllAttributes=0, LDAPSearchSpec=mail=%s, MniEnablePostBinding=0, SSOPostIndex=0, SAMLMajorVersion=2, DelegatedAuthSecret=<Value not shown>, MniNotifyUserName=*, OpenCookieEncryptionPassword=<Value not shown>, RequireEncryptedNameID=0, EnableAttributeMapping=0, MniSignResponse=0, DomainOid=@03-030165a7-7050-4e75-a8ab-811948f61421, UnauthorizedAccessRedirectURL=, InvalidRequestRedirectMode=0, OutgoingPassword=<Value not shown>, EnableSSOArtifactBinding=0, SSODefaultService=https://www.sso.lab/affwebservices/public/saml2sso, SkewTime=30, NameIdFormat=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, ProxyServer=https://www.partner.lab, MniDeleteNameID=0, ProvEnableQuotedOpenCookie=0, Enabled=1, ProvEnableOpenCookieHMAC=0, EnableInvalidRequestURL=0, SAMLReqSignAttributeQuery=0, IncomingPassword=<Value not shown>, ServerErrorRedirectMode=0, UserNotFoundRedirectMode=0, InvalidRequestRedirectURL=, NameIdStatic=*, KEY_IdPSourceID=8880e2d69fe63cf8d71d1bc28c97697e77600293, SignAuthnRequests=0, KEY_IdPID=http://www.sso.lab, MniNotifyPassword=<Value not shown>, MniEnableRedirectBinding=0, SAMLMinorVersion=0, EnableSSOECPProfile=0, SignatureAlgo=1, Name=partner2sso, RelayStateOverridesSsoTarget=0, AuthnContextRowCount=0, ProvisioningType=0, MniNotifyTimeout=60, NameIdAllowNested=0, EnableUnauthorizedRequestURL=0, QPOverrideAllowCreate=0, ServerErrorRedirectURL=, RelayStateOverridesSloConfirm=0}]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAML2Base.java][getIdentityProviderInfo][Tunnel client message: .]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAML2Base.java][getIdentityProviderInfo][Obtained identity provider information from policy server for: http://www.sso.lab.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][encryptProviderPasswords][Encrypted password for attribute MniNotifyPassword]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][SAML2Base.java][getIdentityProviderInfo][Obtained identity provider information from cache for: http://www.sso.lab.]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][getPartnershipSourceValue][Partnership source value = 3]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][getRealmForTarget][Reading the configuration to get the target url [CHECKPOINT = SSOSAML2_READTARGETURL_REQ]]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][getRealmForTarget][targetURL:https:// usingRelayState: false]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][validateTarget][Target: https:// is not in the CookieDomain: .partner.lab]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][getRealmForTarget][Get realm oid for target resource from property [CHECKPOINT = SSOSAML2_REALMOIDFORTARGETFROMPROPERTY_RSP]]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][getRealmForTarget][Realm Name: ]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][getRealmForTarget][Realm OID: 06-24b16054-3382-4b1c-aff8-a9259584a485]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][validateDestination][Using Proxy URL: https://www.partner.lab/affwebservices/public/saml2assertionconsumer]

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][Credentials: <UserCredentials><Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_b27d347d8a87e57f65454274ef39876392c7" IssueInstant="2016-06-15T10:33:04Z" Version="2.0">

 

 

[06/15/2016][10:33:10][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][authenticateUser][Passing response message through login call [CHECKPOINT = SSO_RESPONSEMESSAGEINLOGIN_REQ]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][authenticateUser][result code from AgentAPI login call: 1]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][authenticateUser][Login successful [CHECKPOINT = SSO_LOGINSUCEESS_RSP]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][SAML Assertion based user authentication succeeded.]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][session id is: Kf/C3ZepKbCrcp8DTCfrnwBWjRQ=]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][Response Attributes:]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][   255:SAMLDataResponse=rO0ABXcEAAAABnQADXVzZXIxQHNzby5sYWJ3BAAAAAd0ADZ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDplbWFpbEFkZHJlc3N3BAAAAANxAH4AAHcEAAAACXQAL3VybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkdwQAAAACdAAlXzNkMDQ3ODFmZWYzYWRmMzFkNzQxZWIxZGYyZjYzOTE4M2UxNncJAAAABQEAAAABdAAvNjgyNmU2ZjgtMjhlNzBlMDMtNDAzMzZiM2QtMTczM2QxMDItN2YzZTUyNTMtNDl3EAAAAAsAAAAAV2EvWAAAAAh0ABJodHRwOi8vd3d3LnNzby5sYWJ3BAAAAA90AAExdwQAAAAOdAACLTF3CAAAAGMAAAAA]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][   218:uid=user1,OU=People,dc=sso,dc=lab]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][   152:user1]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][   151:0e-03b4d1c3-010f-4aeb-9066-a0da3eee0585]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][SAMLData returned]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][processSuccessfulAuthentication][

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][Validating input...]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][Creating the smsession cookie for SP domain [CHECKPOINT = SSO_SMSESSIONFORSPDOMAIN_REQ]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][Recived valid input. Attempting to create SESSION cookie.]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][session id is: Kf/C3ZepKbCrcp8DTCfrnwBWjRQ=]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][About to create SESSION cookie.]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][FWSBase.java][createSessionCookie][Placing smsession in browser [CHECKPOINT = SSO_PLACESMSSESSIONTOBROWSER_REQ]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][authenticateUser succeded: 0]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][Redirecting user to target url [CHECKPOINT = SSOSAML2_REDIRECTUSERTARGETURL_REQ]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][handleUserRedirection][Enter: handleUserRedirection]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][redirectUser][

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][redirectUser][Redirecting the user to https:// using '302 No Data' redirect mode.]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][Exception caught in class com.netegrity.affiliateminder.webservices.saml2.AssertionConsumer, method doPost, message java.lang.RuntimeException: java.net.URISyntaxException: Expected authority at index 8: https://.]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][Stack Trace: java.lang.RuntimeException: java.net.URISyntaxException: Expected authority at index 8: https://

 

 

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][Ending SAML2 AssertionConsumer Service request processing with HTTP error 500]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][doPost][Transaction with ID: 6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49 failed. Reason: ACS_EXCEP_DO_POST]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][ErrorRedirectionHandler.java][redirectToErrorPage][Sending HTTP Error 500 ]

 

This new portrait mode on the blog is really making it difficult when trying to look at logs.

The abstract is as below.

 

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][processSAMLResponse][Redirecting user to target url [CHECKPOINT = SSOSAML2_REDIRECTUSERTARGETURL_REQ]]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][handleUserRedirection][Enter: handleUserRedirection]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][redirectUser][

redirectMode: 0]

[06/15/2016][10:33:11][4528][4224][6826e6f8-28e70e03-40336b3d-1733d102-7f3e5253-49][AssertionConsumer.java][redirectUser][Redirecting the user to https:// using '302 No Data' redirect mode.]

 

User1 was found and authenticated so it wants to redirect to the predefined TARGET which I am expecting it to be https://www.partner.lab/saml20/

But the log says it is redirecting to "https://" which is not valid.

 

We need to modify the SP Side Partnership.

 

You can first view it before editing. Once you confirm the error then you can deactivate the partnership and make the changes.

As you can see above, for some reason the Target is saved as "https://" so the log explained the error condition correctly.

 

This clearly shows how much important it is to get FWSTrace.log to troubleshoot.

After fixing the typo, I am testing again.

It was a success.

This is how the IDP initiated Federation is setup.

In the next article, I will demonstrate how to setup SP initiated Federation.

SungHoon_Kim

Federation Starters 2

Posted by SungHoon_Kim Employee Jun 14, 2016

This is a continuation from Federation Starters

In the previous article, it was demonstrating IDP initiated federation.

In this article, I will demonstrate what are the required steps to setup a federation and this is setup in the ALL-IN-ONE VMware Image.

In your case, it would be better to setup a separate IDP and SP configuration so that you won't be confused what is where.

 

Once this article has coverted the setting up, then I will continue with the SP Initiated federation and then touch base on the SLO.

 

Following is my environment:

 

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

 

Firstly, let's create IDP side configuration.

 

1. Deploy affwebservices on NewAtlanta Servletexec

2. Modify affwebservices.properties

3. Modify LoggerConfig.properties

4. User Store

5. Authentication Scheme

6. Domain/Application

7. Realm/Component

8. Rule/Resource

9. Policy/Role

10. Session Store (Not required if you only want to achieve Federation SSO and you do not need SLO)

11. Entity(Local and Remote)

12. Partnership

 

But even before you actually create those objects, you should already have some agreement that was made between the IDP and SP side for federation which is at times missed out.

Many customers who are new to federation simply want to know the configuration steps(such as above) but without knowing the requirement for federation partnership.

 

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

 

1. EntityID

2. Which keys to sign (also need to provide the CA chain and the public certificate) and verify

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. Whether SAML Artifact Profile will be used or SAML Post Profile will be used.(In this use case we are using Post Profile)

10. Whether SP will use HTTP-Redirect mode to send AuthnRequest to IDP or use HTTP-POST. (This is not relevant here because the use case does not involve SP initiated federation. However, configuration requires one to be defined so we will select HTTP-Redirect mode)

 

EntityID is the unique ID that represents you as an entity for federation.

It is usually a fully qualified hostname but it can be a simple text such as "idp" or "sp1" but it may not be so unique.

"http://www.sso.lab" or "http://www.partner.lab" would be a good entityID. This would appear as clear-text in the URL when you initiate federation so it is not a sensitive information although it plays a critical part in the federation.

 

You should already have a key pair generated and have the certificated issued(either by self-sign or via CA).

You must have the certificate readily available to pass to your counter part.

Your counter part must also have their certificate(and the CA chain) made available to you.

 

Federation URLs such as the following for IDP(IDP need to share this with SP):

https://www.sso.lab/affwebservices/public/saml2sso

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

 

And something like the below for SP(SP need to share this with IDP):

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

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

 

NameID is the key "user identity" information IDP is sending to SP.

In this use case, I will be using email address as NameID(user1@sso.lab).

It is commonly used but you can also just use the UID such as "user1".

This information is also visible in clear-text by default and is stored in the Assertion(SAML Response that is sent to SP for authentication).

Optionally you can encrypt this part or the whole document(Assertion).

 

The rest are optional and is not mandatory.

 

RelayState is another TARGET that you can specify telling the SP that you would like to be redirected to this URL instead of predefined TARGET configured in the SP side partnership configuration.

SP has to allow this or the user will simply get redirected to SP's predefined TARGET.

 

Audience is a string that is used for security. You have option not to specify any value but by default it will still add ONE audience which matches the EntityID.

 

SAML Artifact Profile is SAML Assertion being passed to SP via an SSL BackChannel.

In other words, the Assertion does not go through the browser.

SAML Post Profile passes the Assertion via browser.

 

Let's go ahead and start setting up the IDP.

 

1. Deploy affwebservices on NewAtlanta Servletexec

 

If your WAOP is installed and if your NewAtlanta Servletexec is running correctly, you should be able to logon to AdminUI at http://www.sso.lab/servletexec/admin

Nothing really special here, you click "Web Applications ==> Manage" and click "Add Web Application"

Then enter the following and click "Submit".

Application Name: Federation Web Services

URL Context Path: /affwebservices

Location: C:\Program Files\CA\webagent\win64\affwebservices

 

EDIT: Thanks to Karmeng for pointing this out.

ServletExec does not know about /siteminderagent/redirectjsp/ virtual directory so you need to modify the StartServletExec.bat file to define the virtual directory as below. Or, you can protect /affwebservices/redirectjsp/redirect.jsp instead. Restart of ServletExec service is required to recognize this change.

 

StartServletExec.bat entry
Before updateset additionalProgramArguments=-port %sePort% -allow "127.0.0.1, [0000:0000:0000:0000:0000:0000:0000:0001]" -root "C:\inetpub\wwwroot"
After updateset additionalProgramArguments=-addl "/siteminderagent/redirectjsp=C:\Program Files\CA\webagent\win64\affwebservices\redirectjsp" -port %sePort% -allow "127.0.0.1, [0000:0000:0000:0000:0000:0000:0000:0001]" -root "C:\InetPub\wwwroot"

 

 

2. Modify affwebservices.properties

 

C:\Program Files\CA\webagent\win64\affwebservices\WEB-INF\classes\AffWebServices.properties
AgentConfigLocation=C:\\Program Files\\CA\\webagent\\win64\\bin\\IIS\\WebAgent.conf

You only need to ensure that the AgentConfigLocation does point to a valid WebAgent.conf file.

It is ofted mistyped such as the \\ is not used and "IIS" folder is missed out, ...\\bin\\WebAgent.conf so lookout for any typo.

 

3. Modify LoggerConfig.properties

 

C:\Program Files\CA\webagent\win64\affwebservices\WEB-INF\classes\LoggerConfig.properties

LoggingOn=Y

LogFileName=C:\\Program Files\\CA\\webagent\\win64\\log\\affwebserv.log

TracingOn=Y

TraceFileName=C:\\Program Files\\CA\\webagent\\win64\\log\\FWSTrace.log

TraceConfig=C:\\Program Files\\CA\\webagent\\win64\\config\\FWSTrace.conf

You only need to care for the above and TracingOn maybe the only thing you will need to modify to enable.

 

4. User Store

This is already created

Note the user search is "(samaccountname=***)"

Just because you will be using email address for NameID, it does not mean you must login using email address.

You can also confirm that "samaccountname=user1" returns a user.

 

5. Authentication Scheme

This also already exist as below.

 

6. Domain/Application

Use the existing one as below.

You can see "SSO LAB Domain Users" userstore is linked to this Application.

 

7. Realm/Component

For IDP, the only URL that need to be protected is the redirect.jsp(https://www.sso.lab/siteminderagent/redirectjsp/redirect.jsp, you might also have deployed your WAOP on a separate application server and in that case it may be https://www.sso.lab/affwebservices/redirectjsp/redirect.jsp).

 

In this sample, WA and WAOP are installed on the same machine and Web Server proxies to the Application Server so WA actually can service /siteminderagent/redirectjsp/redirect.jsp so that will be the "Authentication URL".

It is the URL that the federation web services redirect users when there is no active session.

 

You need to create a Realm/Component to protect this redirect.jsp and you need to note that it is also called "Authentication URL".

 

In case if you are enabling SLO, this realm must be set to persistent. But will skip it for now as we are not setting up SLO yet.

 

8. Rule/Resource

Create a rule/resource to grant access for GET and POST for "Authentication URL".

 

Note the "Effective Resource" was changed from "/*" to "*" (removed the slash).

This will ensure the "redirect.jsp?xxxx" will also be covered by this rule.

 

9. Policy/Role

There is an existing Role so I will use it.

This Role authorizes users who are at "CN=Users,DC=sso,DC=lab" or "OU=People,DC=sso,DC=lab".

In the previous screenshot for the userstore, the userDN was "CN=user1,OU=People,DC=sso,DC=lab" so this user will be able to access the "Authentication URL"

 

This only allows the user to access the "Authentication URL" but it does not mean this user now can federate.

There is another "User Authorization" that need to be configured in the Partnership later.

 

 

Now this Role must be assigned to the Authentication URL Rule.

 

10. Session Store (Not required if you only want to achieve Federation SSO and you do not need SLO)

Nothing to configure for Session Store from AdminUI. (Not yet)

 

This is end of configuring the regular siteminder objects.

Next is the real Federation objects.

 

11. Entity(Local and Remote)

 

Before you create any Federation objects, you should import the keys and certificates.

If you already have a keypair, you should import it.

If you do not have any, you can easily generate one from AdminUI.

 

In this use case, I will generate a keypair from AdminUI(Self-Signed) and then demonstrate how to get it signed by CA and import the CA signed certificate.

This step is same as renewing your certificate when your certificate expired.

If you are using IE you "MUST ENSURE YOUR ADMINUI FQHN IS SET TO LOCAL INTRANET" otherwise the alert to save the CSR may not be visible.

 

 

Navigate to "Certificate and Private Key List" and click "Request Certificate"

Alias cannot have any space so make it one word.

I changed the key length to 2048. Click "Save".

You will notice the idpsigningkey.p10 (<alias>.p10) file is saved automatically.

If you open it in a text editor, you will find it is a CSR. This will need to be submitted to a CA to get CA Signed Certificate.

But if you decide not to, you can just use the generated keypair.

Note that it was set to 90 days validity while generating so you should set it to 365 days if you want to use it for 1 year.

 

Below is the self-signed certificate.

In case if you have misplaced the "idpsigningkey.p10" file, you can regenerate it.

There is "Generate CSR" option.

Once you get the CA Signed certificate or renewed certificate, you can update this certificate via "Update Certificate" option above.

 

Now, let's send the CSR to a CA and get the CA signed certificate.

 

This use case is using Microsoft Certificate Service.

Click on "Request a certificate"

Click "advanced certificate request"

Click "Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file"

Copy and Paste the idpsigningkey.p10 file content to the "Saved Request" input box.

Change the "Certificate Template" from "User" to "Web Server".

Click "Submit"

You can now download the CA Signed certificate.

Doesn't matter if you download DER or Base64. I prefer Base64 so I will download Base64 format.

Click "Download certificate". You can import this directly from AdminUI.

 

If you click "Download certificate chain" then you will be downloading "certnew.p7b" which is a container with the web server certificate and the CA certificate chain.

You can also import p7b directly from AdminUI. It would be much more convenient if you import the p7b as you will get the whole CA chain and the CA signed certificate.

 

But in this use case, I will download the CA signed certificate only and import "Certificate Authority" certificate separately.

 

Before importing the signing certificate, import the CA certificate(best practice) first.

Navigate to "Certificate Authorities" and click "Import New".

 

I have the CA Certificate downloaded to my desktop.

Click "Browse..." and select the CA certificate.

Don't worry about the path being "C:\fakepath\ROOTCA.cer", it is by design.

Click "Next"

Click "Finish" to complete importing the CA Certificate.

 

Now navigate to "Trusted Certificates and Private Keys" screen.

Click "Action" dropdown menu and select "Update Certificate".

Click "Browse" and select the CA signed certificate.

Again, you can import the p7b file as well.

 

You can see now that the "Expiration Date" has changed.

The "FIPS Status" also changed to green.

This certificate has been updated. The IssuerDN and the Serial Number confirms it.

 

You can now configure the IDP side of federation.

 

When you are IDP, you need to create the following Entities.

 

1. Local IDP (SAML 2.0)

2. Remote SP (SAML 2.0)

 

Let's create LocalEntity first.

Click "Create Entity". If your SP was kind enough to provide you their Metadata export then you can click on "Import Metadata" and import the xml file. It will create the Remote Entity as well as the Partnership.

 

In this use case, I will create Entity manually.

Entity Location must be "Local"

New Entity Type must be "SAML2 IDP"

Space is not allowed so make them all 1 word.

Select "idpsigningkey" from "Signing Private Key Alias" drop down menu.

 

Supported Name ID Formats lists "Email Address" and "Unspecified".

In this use case, because we are using "Email Address" you do not need "Unspecified" but this screen only means you are allowing either "Email Address" or "Unspecified" and you must choose which one at the Partnership configuration.

 

Your first Entity is created successfully.

 

Next is the Remote Entity.

Click "Create Entity".

Entity Location must be "Remote"

New Entity Type must be "SAML2 SP".

EntityID is what you SP told you.

Entity Name is what you want to call it.

Your SP must inform you what is the URL where they want to receive the Assertion.

In case of SiteMinder it is "/affwebservices/public/saml2assertionconsumer" so you just need to add the hostname in front.

 

We are not configuring SLO so we skip that part.

We are also not creating users at the SP when there was no matching user so we skip MNI(Manage Name ID) part.

We are not configuring SP initiated federation yet so we skip the Signature and Encryption Options.

Verification Certificate Alias is the certificate your SP gave you and told you that they are going to sign the AuthnRequest(SP Initiated - SAMLRequest message) so you need to select SP provided certificate to verify that signature.

Encryption is the certificate SP gave you and told you to use that to encrypt the SAMLResponse.

So, since we did not agree on anything about SP initiated(AuthnRequest) nor encryption so we have nothing to configure at the moment.

 

In the Supported Name ID Format, I chose only "Email Address".

Again, this is not final, you must select the final option in the Partnership configuration among the options you selected here.

 

 

Now you have both the LocalIDP and RemoteSP entities created so you can now create a partnership.

 

12. Partnership

 

Select "SAML2 IDP -> SP" from dropdown menu.

 

 

I have named this partnership as "SSO2PARTNER". Then select the respective entities.

I have added "SSO LAB Domain Users" from the available Directories and added to "Selected Directories".

This is to choose which users can be authorized in the next screen.

You cannot continue without specifying a user directory.

In the older version of AdminUI, when you modify the Partnership it somehow removes the Selected Directories and cause the partnership to fail saving so check if there is a userstore linked to this partnership.

 

 

It is easier to just allow "All Users in Directory" which is the default option but if you need to scope the users then you can do so by selecting the filter.

 

My sample user is in OU=People so I will select "Organization Unit"

What will happen is that the Policy Server will scan the userstore for the OU and give you a list to select.

But do not try this if your userstore is unindexed or takes too much time to query for the OU.

Regardless of which Name ID Format you choose in the Entity, you still get a full list to select from.

Select "Email Address" and select type as "User Attribute" then specify the attribute name(mail).

1.JPG

Above is the minimum required for you to do an IDP initiated Federation.

You can see here that the Authentication URL need to be entered manually.

There are 2 Bindings.

1. Authentication Request Binding

This is whether you will make a GET request to "/affwebservices/public/saml2sso" or POST.

In case if you are doing SP Initiated Federation and if the URL gets too long and unable to pass the SAMLRequest message then POST would be your only option. BUT!! this requires Session Store.

 

In this use case, I am using HTTP-Redirect mode so it will be a GET.

And since this is only for IDP Initiated federation, the only things you will find in the URL will be the SP's EntityID and RelayState if that is going to be used.

Nothing to configure here.

For SAML 2.0 Post, IDP must sign the Assertion part of the SAML Response.

So, "idpsigningkey" is specified and signing algorithm is set to RSAwithSHA1 by default.

"Post Signature Options" is set to "Sign Assertion" as specified in the OASIS specification.

None of the others were agreed with SP so none is configured.

 

 

Your Partnership will be set to "Defined" status once complete. You need to "Activate" it if you want to use it.

Even though this partnership is configured, it is not recognized until you activate it.

 

 

 

Now, it is set to Active.

You can initiate the IDP initiated Federation by accessing the following URL.

 

https://www.sso.lab/affwebservices/public/saml2sso?SPID=http://www.partner.lab

 

Although you do not have SP configured at this point, you can still test if the IDP is generating assertion and if it is posting it to the SP side.

 

This article again has exceeded 50 images so I will continue in the next article starting with setting up the SP side.

This is not complete and is Work in Progress.

 

Firstly you will need to have WebSphere installed.

I have WebSphere 8.5.5.0 installed on RHEL 6.5(x64) at "/apps/IBM/WebSphere/AppServer".

It is installed by root.

I have a server configured at "/apps/IBM/WebSphere/AppServer/profiles/AppSrv01/servers/server1"

 

I am not using external JDK. I am using IBM Java that came bundled with WebSphere.

 

You need to have an existing Policy Server that supports WSS Agent.

I have R12.52SP1CR4 Policy Server on the same machine at /apps/CA/siteminder".

It is installed by smuser.

I am running in "FIPSONLY" mode.

 

You need to have an existing User Store.

I am using AD and I have admin account to connect to it.

I also have a test user account to test authentication.

 

You need to have a Web Service to test this.

It must be JAX-RPC Application which has "webservices.xml" file.

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2052%20SP1-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?1609342_1.html#o363933

Sample application has rootcontext of "/securitytest".

 

Install WSS Agent. I would recommend R12.52SP1CR4.

(There were couple of files missing in the CR5, the smreghost.sh and cryptojFIPS.jar)

 

During installation, enter the path to your WebSphere(/apps/IBM/WebSphere/AppServer).

WSS Agent will copy the jar files to "/apps/IBM/WebSphere/AppServer/lib/ext" folder and some other files to "/apps/CA/Web_Services_Security" folder.

 

***After the installation, you must copy the "/apps/IBM/WebSphere/AppServer/lib/ext/thirdparty/cryptojFIPS.jar" to "/apps/IBM/WebSphere/AppServer/java/jre/lib/ext" folder.

 

*** Modify the "/apps/IBM/WebSphere/AppServer/java/jre/lib/security/java.security" file as below.

/apps/IBM/WebSphere/AppServer/java/jre/lib/security/java.security

security.provider.1=com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl

security.provider.2=com.ibm.crypto.provider.IBMJCE

security.provider.3=com.rsa.jsafe.provider.JsafeJCE

security.provider.4=com.ibm.jsse2.IBMJSSEProvider2

security.provider.5=com.ibm.security.jgss.IBMJGSSProvider

security.provider.6=com.ibm.security.cert.IBMCertPath

security.provider.7=com.ibm.security.cmskeystore.CMSProvider

security.provider.8=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

security.provider.9=com.ibm.security.sasl.IBMSASL

security.provider.10=com.ibm.xml.crypto.IBMXMLCryptoProvider

security.provider.11=com.ibm.xml.enc.IBMXMLEncProvider

security.provider.12=org.apache.harmony.security.provider.PolicyProvider

Make absolutely sure that there is no typo or uppercase lowercase mistake.

You do not need to add "com.rsa.cryptoj.fips140initialmode=NON_FIPS140_MODE" since this is running in "FIPSONLY" mode.

 

Logon to WebSphere console and register LDAP userstore.

"Console ==> Security ==> Global security ==> User account repository"

Select "Standalone LDAP registry" from "Available realm definitions" and click "Configure..." button.

Enter required information as below.

Click "Apply".

 

Then click on "Java Authentication and Authorization Service".

 

Click on "System logins".

Click "New"

 

Create "XMLAgent" as below. You MUST name the alias as "XMLAgent".

The order must be followed and all must be set to "REQUIRED".

Login Module Class Name

com.ca.soa.agent.appserver.jaas.XMLAgentLoginModule            REQUIRED 1

com.ibm.ws.security.server.lm.ltpaLoginModule                  REQUIRED 2

com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule   REQUIRED 3

Click "Apply" and "OK"

 

Now goto "/apps/CA" (parent folder of Web_Services_Security folder) and create "WebServices_Security" folder.

Note the missing underscore!!!

The reason is the SystemErr.log reported that it cannot find the log.config file and that filepath was different from where the WSS Agent was installed.

 

 

You will also need to copy the "/apps/CA/Web_Services_Security/wasagent/config/JavaAgent.conf" and "log-config.properties" file as well.

 

For some reason, these files were loaded from "/apps/IBM/WebSphere/AppServer/profiles/AppSrv01/config/" folder but once I created the "/apps/CA/Web_Services_Security/wasagent/config/" it permanently was looking for files in this folder.

I left "SmHost.conf" file in the "/apps/CA/Web_Services_Security/wasagent/config" folder so the JavaAgent.conf is still pointing to that filepath.

 

 

You also need to create "/apps/CA/WebServices_Security/bin/" folder as that is the default folder where soasm_agent.log file is generated. Please ensure the folder has appropriate permission to create files.

 

Next is to deploy the web services.

I have the web service extracted at "/apps/SecurityTest_war.ear/"

Navigate to "/apps/SecurityTest_war.ear/SecurityTest.war/WEB-INF/" and modify the "webservices.xml" file as below.

Please note the <handler> part.

Your application may have existing <handler>. In that case you must ensure the WSS Agent handler comes at the top.

In this case, there is only WSS Agent handler.

 

Restart the WebSphere.

 

Logon to SiteMinder AdminUI and create the following.

 

Create User Directory.

This is the same user directory that you registered at the WebSphere.

 

 

Create "XML Document Credential Collector" authentication scheme.

 

You must ensure the XPATH is defined correctly.

 

Create Domain/Realm/Rule/Policy.

 

 

Please ensure you have chosen "Post", "ProcessSOAP" and "ProcessXML" actions.

 

 

 

Now import a keypair and give it alias as "defaultenterpriseprivatekey".

 

Otherwise, you will get error in the soasm_agent.log below.

 

After import, you will see the "IssuerDN" of your signing key.

 

Next is to use SoapUI to send request.

 

The Soap Document in the Body should have the matching user credential as defined in the Authentication Scheme(XPATH).

At the right panel, you can see the SMSESSION cookie was returned.

So, the authentication looked as if it was successful but there were errors reporting about the structure of XML document missing some elements.

 

 

To be continued...