Federation Starters 2

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

3. Modify

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




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




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 ", [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 ", [0000:0000:0000:0000:0000:0000:0000:0001]" -root "C:\InetPub\wwwroot"



2. Modify


C:\Program Files\CA\webagent\win64\affwebservices\WEB-INF\classes\
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


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


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


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


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.




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.