- Quick... give me a SAML Service Provider to test with!
- What the demo site does
- Getting IDP initiated SSO working
- 1. Create a SAML application
- 2. Import the SP metadata
- 3. Set other configuration parameters
- 4. Test!
- Getting SP initiated SSO working
- Using the RSA SecurID Access Cloud Authentication Service IDP (aka Cloud IDP)
- 1. Create a new SAML Relying party
- 2. Define how authentication is done
- 3. Connection Profile
- 4. Download IDP metadata file and import into sptest.iamshowcase.com
- Creating custom SAML Authentication Requests
- Is it secure?
Quick... give me a SAML Service Provider to test with!
Did you ever encounter the scenario where you have to show a SAML integration working and you (or your customer/partner) doesn't have a demo/test SAML application available?
Silly question... of course you did!
While there are cloud services out there that offer trial/test instances they are usually time limited and you have to go thru the process of requesting such a trial - not impossible but certainly an annoyance. The time restriction (e.g. 30 days) also means your demo system will need to be reconfigured every month and you have to go thru the process again to get a new test instance... doable but certainly not pretty.
Because of all of this we created a simple SAML service provider and deployed it on a host that is accessible from anywhere.
Feel free to use it yourself, tell your colleagues and friends, customers, partners...
If you can't wait to start, here is the URL: https://sptest.iamshowcase.com
The site itself should have all the instructions needed but just in case you need some hand-holding here are more detailed descriptions and instructions.
This works perfectly with the SAML Identity Provider that RSA SecurID Access provides but any other SAML 2.0 compliant IDP should work too. In fact this Demo Service Provider is used with non-RSA IDPs on a constant basis.
What the demo site does
The demo site acts as a SAML service provider and supports IDP and SP initiated SSO.
Once you configured everything correctly you can federate into the demo SP and see things like the user ID (SAML Subject), attributes (if any...) and more. If you want you can also get the raw SAML assertion from the page.
This is what you'll get:
The site is responsive - meaning it should work fine on any device and scale accordingly. Great for demos from your phone/tablet!
Getting IDP initiated SSO working
IDP initiated SSO only requires that you download the metadata from the demo SP and import it into your IDP and configure whatever needs to be configured on your side.
The start page of the demo site has the download link for the metadata.
For RSA SecurID Access here is what you need to do:
1. Create a SAML application
Give it a cool name.
"Demo SAML Application" is what I chose. I'm not cool.
2. Import the SP metadata
Click the "Import Metadata" button on the "Connection Profile" section and import the metadata file from the demo SP you download previously.
It'll fill out a couple of things like the ACS URL and SP Entity ID.
Just accept the defaults.
3. Set other configuration parameters
Select the "IDP-initiated" radio button - don't worry, if you like to get SP initiated working this won't stop you from doing this so don't worry.
You can leave the "Connection URL" (which is the RelayState) empty or put in there a color scheme name you want the demo site to use (more on that later).
Create (or re-use) a certificate bundle.
Set the User Identity to whatever you like. The SP doesn't really care. EMail is fine but if you like to send something else feel free to do so.
In my example I chose "Attribute Hunting" as I have two LDAP directories setup.
You can also send any other attributes over - in my example I chose to send "Firstname" and "Lastname". You can send whatever you like and name the attributes to your liking too. If you do send over things like firstname, givenname etc, those will be used to greet the user instead of displaying just the nameID.
Finally select the policy this app should be protected with, publish the changes and Bob's your uncle.
4. Test!
Log into the portal with a user that has access to the newly created application. You should see the icon you chose.
Click it...
You should see something similar to this (depending on the screen resolution it might look slightly differently):
See this wonderful pink color? You can control how the page looks like by setting the RelayState to one of the support color schemes - see the documentation on the site itself. This can be useful if you want to show e.g. different colors for different authentication policies done at the IDP.
Scroll down and you'll see further information like the NameID and NameID format as well as the attributes:
... and your IDP entity ID, timing information and the raw SAML assertion in case you want to take a closer look can also be displayed:
Getting SP initiated SSO working
OK, IDP initiated SSO works but 9/10 times somebody will ask for SP initiated SSO. Rightfully so!
To get SP initiated SSO working you need to first export the IDP metadata and import it into the demo SP site.
You can upload the metadata file on the instructions page of the demo site.#
Once you did that you'll be presented with a screen that shows you your unique logon URL:
That URL (e.g. https://sptest.iamshowcase.com/ixs.jsp?idp=cie8348382093) you need to remember. Copy it and make a bookmark out of it.
If you hit that URL the demo SP will send a SAML Authentication Request to your IDP which in turn will respond with a SAML Assertion. You might have to log into the IDP if you don't have a session there already.
That is how the "IDP discovery" is done - similar to what e.g. Google or SFDC do. They also provide unique login URLs that will trigger an AuthNRequest.
After a successful SAML SSO transaction you can also logout and click on the link to the protected page again - it'll trigger a SAML AuthNRequest again.
Should you forget/loose the URL simply re-upload the metadata again and the same URL will be displayed again.
Using the RSA SecurID Access Cloud Authentication Service IDP (aka Cloud IDP)
The Cloud IDP works independently of the IDP on the Identity Router and it's main purpose is to be used by 3rd party SSO solutions (such as VMware Workspace, Citrix Netscaler, Ping Federate or Microsoft Azure AD).
Of course the demo service provider can be used with this IDP too.
In face... you can demo/test things like putting a NameID into the authentication request or ask for a specific Authentication Context Class (to require the Cloud IDP to evaluate a specific policy). How do that part is described in the section following this one.
In this section however we concentrate on how to set up the Cloud IDP to work with the demo service provider.
1. Create a new SAML Relying party
Who doesn't like parties? Relying parties in RSA SecurID Access are "attached" to the Cloud IDP.
To create one you need to select "Authentication Clients->Relying Parties", then click on "Add a Relying Party" and finally select to add a "SAML" relying party. You'll end up with a screen like this:
Give that new Service Provider a name and continue to the "Authentication" tab.
2. Define how authentication is done
In this screen you have to decide on whether to require RSA SecurID Access to handle the primary and additional authentication or just the additional authentication.
In the example below, RSA SecurID Access is only used for additional authentication. This means the SP needs to send a SAML Authentication Request containing a NameID (email address) that can be mapped to an existing user record inside RSA SecurID Access.
The service provider may also send a policy name with the request as a Authentication Context Class Reference inside the SAML authentication request. This part is optional however. If no AuthNContextClassRef is sent, the default policy will be evaluated.
The example below shows a configuration that tells RSA SecurID Access to do the primary and additional authentication.
A AuthNContextClassRef might be provided in the request but if it is not there the default one will be used.
As primary authentication you can either select "Password" or "SecurID".
So pick whatever you desire and continue on to the next screen.
3. Connection Profile
In this final screen you do all the SAML specific configs. The best approach is to upload the SAML metadata file from the service provider and finish the configuration.
4. Download IDP metadata file and import into sptest.iamshowcase.com
After you finished the configuration the IDP side the last thing to do there is to download the metadata. To do that, click on the arrow besides the "Edit" button besides the Service Provider you just created. Then choose to view or download the metadata.
You'll be presented with a screen like this:
Either just copy the content or download the file.
Go to SAML 2.0 Test Service Provider and either select the file you downloaded or past the content into the text area. and press the corresponding "Submit" button.
After that you'll see the login URL you have to hit to trigger a SAML AuthNRequest:
If you configured your IDP to do primary and additional authentication you are good to go - just use this URL and you should end up on the login page of your IDP:
Creating custom SAML Authentication Requests
The SAML Authentication Requests send by the demo site by default pretty blant... they just ask the IDP to authenticate this unknown user somehow - it's entirely up to the IDP to determine what policy to use for example.
There is however a way to customize the AuthNRequest before it is send to the IDP.
For this to work, you first need to setup SP-initiated SSO (see above) and federate from that IDP at least once. Then the "AuthNRequest Wizard" shows up in the menu bar.
You can use this to add a NameID and/or to add a AuthenticationContextClassRef to the request.
The fields for NameID Format and AuthenticationContextClassRef have some pre-configured options - just type in "email" or "unspecified" for the NameID Format and you'll be able to pick the full format identifier from a list. Same goes for the authNcontextClass - there is e.g. "password". However if you want to use the RSA SecurID Access Cloud IDP I suggest you create a policy first and use that together with the "urn:rsa:names:tc:SAML:2.0:ac:classes:spec:stepup:" prefix - type in "rsa" into the field and see some suggestions. If you name your policy after such a suggested name it'll just work (promised!).
Is it secure?
We do not store any part of your metadata except the ACS URL of the IDP - that is what we use to create that unique login URL.
We do not store your subject names, attributes etc.
We do also not validate the SAML signature - at least in the current release. This is a demo site and not really concerned about security. So if you send a SAML assertion with a invalid signature don't expect it to trigger any alarms.
