SungHoon_Kim

Federation Starters 8

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

Outcomes