Skip navigation
All Places > Products > RSA SecurID Access > Blog > Author: Ingo Schubert

RSA SecurID Access

6 Posts authored by: Ingo Schubert Employee

We looked at SFDC apps before here (Salesforce Rich Client setup by Karim Elatov) and here (Salesforce1 app login video by Joseph Macaluso).

Today, I just wanted to give a quick update on this, specifically about SalesforceA.

SalesforceA is the app that SFDC administrators can use to perform various administrative tasks such as unlock user accounts.

 

In terms of authentication and setup it doesn't really differ that much from the standard Salesforce1 app.

 

Look at the guide by Karim for the details about setting up SFDC as a SAML SP.

 

Once you did that you can then log into SalesforceA - but keep in mind that this only succeeds if the account you use is a SFDC admin.

Here are some screenshots:

When you start the app the first time you are asked (unsurprisingly I might add) to log in:

 

Screenshot_20160801_154015.png

 

Click on the "Sign In" button.

You'll be presented with something that looks a lot like the SFDC login screen in your web browser. That's because what you see is a web page rendered in a browser object inside the SalesforceA app.

 

Screenshot_20160801_154029.png

 

Now you have to click on the "Use Custom Domain" link on the lower right corner.

You'll be asked for your custom domain.

 

Screenshot_20160801_164554_2.png

 

Next you'll be presented with the login screen of the target domain OR you might be automatically redirected to the IDP (SecurID Access). This really depends on the setup at SFDC. In my case the SFDC instance I use actually has multiple IDPs it trusts. So I have to select the one I want:

 

Screenshot_20160801_154223.png

 

After I did that I'm redirected to my SecurID Access login page and fill out the username and password fields.

Again: this has to be for a user that has administrative rights inside SFDC - otherwise SalesforceA won't like it.

Screenshot_20160801_154258_2.png

 

After the login completes (and maybe after a step-up if the policy requires it) the SalesforceA app will present this screen to approve access by the user to the SFDC instance.

Some technical background: SFDC consumed the SAML assertion from SecurID Access and now exchanges that session information for a OAuth token - as soon as "Allow" is selected.

 

Screenshot_20160801_154313.png

 

....and we are in!

 

Screenshot_20160801_154331.png

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.

Screenshot_20160519_113906.png

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.

 

 

 

 

Screenshot_20160519_113947.png

 

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

Screenshot_20160519_114027.png

 

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.

Introduction

Name Mapping is easily the most complicated and least understood part of SAML. That makes it a perfect subject for the first deeper look into SAML. If you get NameID mapping the rest of SAML will be a walk in the park.

What is a NameID?

A NameID is the subject of a SAML assertion.

Let's look at part the SAML assertion from the last article:

 

<saml:Subject>

      <saml:NameID  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">

John Doe

</saml:NameID>

</saml:Subject>

 

... and remove the clutter:

 

<Subject>

     <NameID>

          John Doe

     </NameID>

</Subject>

 

So the NameID is the guy/girl the SAML assertion is all about.

Why map NameIDs?

With a "NameID" SAML means the  identifier of a SAML subject.

That is in most cases the user ID on the IDP or the SP... and this is where the trouble starts.

 

It is unlikely that a user has the same user IDs at both the IDP and the SP.

 

Example: While the old RSA employee userID schema used <first letter first name><lastname> e.g. ischubert, EMC uses <first five letters last name><first letter first name> e.g. schubi.

EMC also has that badge number which doesn't relate to the real name at all.

So just imagine the mix of different user IDs in a bigger environment.

Additionally there are scenarios where e.g. a group/role from one side is mapped to a single user on the other side. E.g. instead of sending the individual user ID from Company A employees over, the subject would be "Company A employee".

What are NameID Formats?

NameID Formats are rules how to submit user identifier information from the IDP to the SP and vice versa.

A NameID format has a Identifier (a name...) and mandates certain formats for the Subject ID of the SAML assertion.

That doesn't make it terrible clear, doesn't it?

 

Let's get more specific:

SAML 2.0 knows 8 formats (and you can make up your own too....):

  • Unspecified
  • EMail
  • X.509
  • Windows Domain
  • Kerberos
  • Entity Identifier
  • Persistent
  • Transient

 

The most popular NameID format is...

EMail!

The EMail NameID Format Identifier is: "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
As you can see from the identifier this format exists since SAML 1.1.

A Subject definition with this format could look like this:

<saml:Subject>

      <saml:NameID  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">

          John.Doe@company.com

     </saml:NameID>

</saml:Subject>

 

In the SAML standard docs (SAML 2.0 Core) it says for this format:

It indicates that the content of the element is in the form of an email address, specifically "addr-spec" as
defined in IETF RFC 2822 [RFC 2822] Section 3.4.1. An addr-spec has the form local-part@domain.

Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded
in parentheses) after it, and is not surrounded by "<" and ">".

 

Or way shorter: the NameID must be a valid eMail address (valid in the sense that it follows RFC 2822 - not that the eMail address actually exists).

So if a IDP and SP agree on using this NameID format they agree to use the user's eMail address every time they send a SAML assertion or request about this user to one another.

 

The Email NameID format is probably the most widely used format. Almost every cloud service uses the user Email address as the primary identifier. Makes sense: it's a nice flat namespace and a familiar format for everybody involved.

 

The other NameID Formats explained

Persistent

As the name suggests this means the NameID matching a user exchanged between IDP and SP stays the same over a very long period of time or even forever.

You could say that EMail is also persistent - true but with the NameID format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent has some unique characteristics to it. It is not only about using a unique permanent identifier - It is also about how this identifier looks like and how it is handled accross multiple IDPs and SPs.

How does it look like?

The SAML 2.0 Core doc has a good explanation:

<The persistent NameID Format...> Indicates that the content of the element is a persistent opaque identifier for a principal that is specific to an identity provider and a service provider or affiliation of service providers. Persistent name identifiers generated by identity providers MUST be constructed using pseudo-random values that have no discernible correspondence with the subject's actual identifier (for example, username).

The intent is to create a non-public, pair-wise pseudonym to prevent the discovery of the subject's identity or activities. Persistent name identifier values MUST NOT exceed a length of 256 characters.

 

Example: FE9ADE3FFA97C8DF225BBBC05D3521AB6850005312B03

 

Important to know:Each IDP-SP releationship has a unique persistent identifier for a  given user (e.g. schubi).

The ID for the IDP-SP1 releationship could be FE9ADE3FFA97C8DF225BBBC05D3521AB6850005312B03  but for IDP-SP2 it is 1170EECBC620B97BC599A1608CEBFFF1271813.

There is one exception to this rule. IDPs and SPs that are part of a affiliation agree to always use the same opaque, persistent ID for a specific user.

An example for a affiliations could be a large corporation that uses federation internally between all divisions. Personally I have never seen this feature (affiliations) of SAML 2.0 in real life.

How is a persistent ID generated and mapped to a real user ID?

This  opaque identifier is of course mapped to a real user ID on each side. On the IDP side if a user is federated out the first time to a specific SP the IDP generates a new opaque identifier and sends it to the SP in the SAML assertion. The SP obviously has no idea who the persistent ID is for - it never encountered this ID from the specific IDP before.

To find out which local user this persistent ID is for it asks the user to identify & authenticate.

If the user can do that the SP matches the (now known) local ID with this new persistent identifier.

The next time the persistent ID comes in the SP knows which local user this is all about. So this little dance (login at IDP, go to new SP, authenticate at SP) is needed every time a user goes from one IDP to a SP he hasn't SSO'd into via this IDP. There is the more exotic case where the IDP and SP can do this matching in the background via a batch job. Nothing is really specified here in the SAML standard. With good reason: Seldomly will the SP and IDP have user repositories with all needed profile info to link two local IDs to a persistent ID - if they could they may as well use another NameID format or make up one one their own to map the user IDs.

Preserving privacy with persistent NameIDs

So what about "non-public pair-wise pseudonym to prevent the discovery of the subjects identity or activities"?

This is the cool part: That prevents SP1 and SP2 working together to trace what a user does across SPs - they can't simply ask the other "what is user X doing on your side?" because X is different for both - even if it is about the same user. They simply can't tell. There is no way for them to look into the other's NameID for a specific user - this is why they are called "opaque" identifiers after all.

Managing a persistent ID

SAML 2.0 also specifies that users can manager their own persistent IDs. They can request a new one or delete a specific one. That comes in handy if you like to cut the link between a IDP and SP because you do not longer user the SP and like to tell it to forget everything about you. I've never seen this used in real life but I can imagine this could come in handy.

Advantages and Disadvantages

There are obviously a bunch of strong advantages:

  • user can have different IDs on both the IDP and SP
  • IDP and SP don't have to communicate directly to link the local IDs to the opaque identifier. The user does this by loggin into the SP and proofing he "owns" the opaque ID send by the IDP.
    • Also possible in bulk in the background but hardly practical
  • preserves the user privacy by making it really hard for th SPs to work together to find out what the user does at the other SPs.

But of course there are some disadvantages:

  • The user has to logon at the SP to proof he owns the persistent ID.
    • This requires that the user has an account at the SP including some form of credential to authenticate.
    • The user has to perform a login at the SP the first time - sometimes that is seen as not very user friendly.

Why all this effort?

One of the big changes of SAML 2.0 over 1.x was the introduction of NameID formats. SAML 1.x could only work with flat namespaces: IDP and SP needed to use the same ID for a particular user.

That was seen as a disadvantage if federation was to be used between e.g. different companies. The chance that the same user had the same ID on both sides was seen as minimal.

That is still true to some extend today but it is not such a big problem it turns out.

In enterprise use cases the employees are the ones that are federated to cloud services or to partner companies. The user eMail address does just fine for that.

Consumer type use cases nowadays use OAuth or OpenID Connect and usually create the user profile on the fly on the first federation. I'll write about OAuth/OpenID Connect later in this series - let's finish the SAML part first before opening up another box full of toys...

Transient

The IDs for urn:oasis:names:tc:SAML:2.0:nameid-format:transient look the same as the one for the persistent NameID format however they behave differently. Firstly the IDP generates a new opaque identifier every time the user is federated out. So the SP shouldn't even try to map this to a known local user. That would be hopeless - the next time the same user is federated over the ID will be different. Mapping to a known local SP user is not the intend behind the transient NameID Format. It is all about federating out temporary users so that the SP can tell that they come from trusted IDP and that maybe that user has certain attributes (if included in the assertion).The SP is supposed to handle this temporary user just as such: create a temporary account and forget (delete) it after use (or a short time after). This is useful for SPs that do not rely on a real user as the basis for their offering but only need to know that a trusted business partner (the IDP) trust those users enough to let them use the service at the SP. An example would be a service that provides real-time stock charts. It really doesn't care who the user is as long as it comes from a partner (e.g. a bank) that has a relationship with the SP (and presumably pays a flat fee for all it's customers to use the service).

Unspecified

"Unspecifie"d doesn't mean it is unimportant. Quite the opposite. If all the other NameID formats don't fit your requirements because

  • Persistent requires the user to log into the SP manuall the first time
  • Transient isn't peristent (doh!)
  • eMail doesn't fit 'cause you don't know the eMail of the user
  • Kerberos is not you thing
  • You don't use certificates (X.509)

 

"Unspecified" NameID format doesn't mean you make up your own NameID Format Identifier. There is actually a NameID format Identifier for Unspecified: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

If you use this in your SAML assertions you assume that the SP (and potentially other members of the circle of trust) know what the ID means because you agreed on what this means beforehand.

"Unspecified" today is also used to transport just Email addresses as NameIDs - it's basically used as a dummy NameID format.

 

An example:

A country has a unique ID for each citizen (1984 for me please!). The IDPs like to tell the SPs this unique ID.

 

At the first look it is tempting to use the persistent NameID Format. Which so wrong! That has been done before (I know of at least two EU govenment projects which did this in the past) but doesn't work and is actually against the SAML standard because... "Persistent name identifiers  generated by identity providers MUST be constructed using pseudo-random  values that have no discernible correspondence with the subject's actual  identifier (for example, username)." Remember?

 

So instead they should use urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified - and tell all the SPs and IDPs what that means for them (= use the citizen ID as the NameID).

 

In one EU member state uses federation with NameID format "unspecified" to transfer a "doctor ID". Perfect. Good choice! They did it right!

 

Of course you could also completely make up your own NameID Format Identifier.

For example urn:rsa:names:federation:nameid-format:really-cool-format

If this is really needed or if you get away with just using "unspecified" really is up to the IDP and/or SP you are dealing with.

Whatever you do however: don't misuse persistent to do things it is not meant to do. That will cause huge issues.

How does RSA Via Access handle NameID Formats?

RSA Via Access can handle all the SAML 2.0 NameID formats as an IDP.

This is configurable in the "Advanced Configuration" section of the "Connection Profile" screen for the application (a.k.a. SAML SP) you are configuring.

Changing that will set the selected NameID format accordingly in the SAML assertion. There is one caveat to this: persistent and transient NameIDs will be not be generated but whatever is set as the subject of the assertion.

As a SP, RSA Via Access assumes the NameID sent over maps to the LDAP attribute set as the user tag (a.k.a. logon name)- So RSA Via Access (as of writing the post) ignores the NameID format of incoming SAML assertions.

What is SAML?

SAML stands for "Security Assertions Markup Language". That should give you a hint that SAML is somewhat based on XML.

All those things I wrote about in part 1 of this series can be done using SAML.

 

SAML is a familiy of messages and protocols used to implement a identity federation system.

The bit about "messages and protocols" is important. If somebody talks about "SAML" they usually mean the combination of the message syntax and protocols - but in some cases (Microsoft did this in the past but they are cool now) SAML only refers to the message syntax (I'll briefly touch on WS-Federation at a later stage).

There is also a Wikipedia Article that you may want to have a look at.

 

Participants in a SAML system

There are generally three participants in a SAML transaction:

  • Identity Provider (IDP, Asserting Party, the one that issues SAML assertions)
  • Service Provider (SP, Relying Party, the one that trusts the IDP and consumes the SAML assertions)
  • The Subject (somebody or something which likes to interact with the Service Provider and that can authenticate to the IDP and/or the IDP has profile information about)

 

Shortcut: The IDP tells the SP something about the the state of a Subject.

 

SAML History

The first version was published in 2002 as a OASIS standard. The most common version (2.0) was published in 2005.

SAML 2.0 is especially important as it is a significant feature jump from 1.1. Two other standards (both based on SAML as well) were taken, mixed up and then published as SAML 2.0.

Note that SAML 2.0 - while derived from ID-FF 1.2 and Shibboleth 1.2  - is not compatible with those two. But that is hardly an issue nowadays ID-FF is history and Shibboleth implementations can fall back to SAML 2.0. SAML 2.0 is used for new deployments, and to be honest there aren't a lot of ID-FF or Shibboleth deployments out there anyway. If you are in an academic environment however Shibboleth is used quite a bit - but the rest of the world doesn't care that much.

Here is a diagram showing the history of SAML 2.0:

federationHistory.pngIn short: it was a bit of a mess for a while but all is good now. SAML 2.0 it is. WS-Federation is used sporadically but you are unlikely to find it used in cloud environments for example.

 

SAML Assertions

If you look at a SAML assertion and you are familiar with XML and some surrounding standards (such as XML Digital Signatures) you feel right at home.

Even with just some basic HTML knowledge you are able to read a SAML assertion and make sense of it.

 

Do you want a taste of how an assertion can look like?

Here is one:

 

<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd" ID="_470ee542-ca32-11de-b313-cdf5016ad5a0" Version="2.0" IssueInstant="2009-11-05T17:40:15Z">
<saml:Issuer>TheBigFatIssuer</saml:Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#_470ee542-ca32-11de-b313-cdf5016ad5a0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>qLq9x06+oW2m74pa5WpuRWpwJQc=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>WrEyMVpzsuvzSGhJeKQ8IoqcvmxFhtS8RMXPy0tXa6ZWeIAyFgA8LeOoA/sm/FNC
euT3E1B+aegtVI7jzbdHxqZ7uDvHV1swMeteWoHWR2vuzqpce6mhyMB9b/MMun0x
wo9JoLjXafotf3tuZgj2whNcvPEtra6e0ImfqfE9qUU=</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIID2DCCAsCgAwIBAgIBCjANBgkqhkiG9w0BAQUFADBUMSAwHgYDVQQDExdBQyBD
TkFNVFMgVGVzdCBTZXJ2aWNlczESMBAGA1UECxMJMTgwMDM1MDI0MQ8wDQYDVQQK
EwZDTkFNVFMxCzAJBgNV FAKE ==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
   <saml:Subject>
     <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
John Doe</saml:NameID>
     <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches">
       <saml:SubjectConfirmationData NotOnOrAfter="2009-11-05T17:48:15Z" Recipient="http://myServiceProvider"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions NotBefore="2009-11-05T17:38:15Z" NotOnOrAfter="2009-11-05T17:48:15Z">
     <saml:AudienceRestriction>

          <saml:Audience>http://www.service.provider.com/sso/ACS</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement AuthnInstant="2009-11-05T17:26:50Z" SessionIndex="_470ee542-ca32-11de-b313-cdf5016ad5a0">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartCard</saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute Name="title">
       <saml:AttributeValue>Some kind of Manager</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
</saml:Assertion>

 

It may look confusing but let's break this down into the important bits.

SAMLBlocks (1).png

 

Control

This is everything which helps the IDP and SP to establish trust (like digital signatures) and to control how the assertion is used. That's basically all the rest. Who issued it assertion? "TheBigFatIssuer". Who is it for? "www.service.provider.com".  There is a digital signature plus the certificate. The assertion is also only valid within a time window "NotBefore" and "NotAfter" etc.

The Who

A SAML assertion will always contain for which subject (=user in many cases) this assertion is for. In the example above "John Doe"

This block may also contain information about how the IDP knows who the user is. For example: What authentication method was used? In the example "SmartCard" was used.

This block is (like many others) optional - it's not needed if the IDP tells the SP just about a user's profile updates.

The What

What does the IDP know about the user besides who she is and how she authenticated? This could be anything else that is part of the user's profile. Address, telefone number etc. The example shows the John's title "Some kind of Manager".

The "What" is optional too - the IDP could just tell the SP that the user is logged on via SmartCard without providing more info about the subject.

The most common use case for SAML (authenticating to a SP) the "Who" and the "Controls" are present.

SAML Protocol, Bindings, Profiles

The SAML Protocol describes how the IDP and the SP and the Clients interact with each other to e.g. request an assertion or how an assertion is sent from A to B. This is like a blueprint of how the participants should interact.

 

There a number of "Bindings" - transport mechanisms - that tell how the protocol messages are transmitted. For example via a SOAP message, a HTTP POST or a HTTP Redirect.

 

Then there the combinations of the protocol and the different bindings: the Profiles.

The Web SSO Profile describes how a SP can tell a Subject to go to a IDP, the IDP to authenticate the user and then send the user with a SAML assertion back to the SP.

The next article will into details about the "Who" - how the IDP tells the SP for which Subject the assertion is about. It's not quite es simple as you may think.

Preamble

This is the first of a series of article about identity federation. It is an updated version of an older series that was hosted on the EMC community site but since publishing this is a read-only thing...

 

This series should give a overview about Identity Federation actually is, what it is used for and what we (RSA) do with it.

In this series of articles I'll plan to go deeper into the standards, use cases and RSA's implementations of them.

Most articles will first describe a certain aspect of a standard or use case and then show how e.g. RSA Via Access could be used to implement it.

There will be a number of blog posts - each looking at some specific topic in more detail. Here is the planned list:

 

  1. Introduction into ID Federation (this post)
  2. SAML Part 1: Overview
  3. SAML Part 2: NameID Mapping and Formats
  4. SAML Part 3: Authentication Statements
  5. SAML Part 4: Attributes
  6. SAML Part 5: Security
  7. tbd

 

 

What are we trying to solve with ID Federation?

 

In my opinion the most fundamental problem that ID Fed solves is:

 

How can the state of an identity be securely transferred from point A to point B?

 

To be a bit more specific: The state mentioned above could be one or all of:

  • If and how the identity identified itself to point A

  • What/who is the identity at point A (and maybe at point B)

  • Up-to-date profile information about the identity

 

Too abstract? Let's give the participants names and provide some examples

Point A and Point B are just that: different entities that either know something about an identity (A) or like to know something about the identity (B).Generally Point A is called Identity Provider, IDP or Asserting Party whereas Point B is called Service Provider, SP or Relying Party. The individual could be either a real person or a abstract service (e.g. a server or program that needs to communicate to another server/program). Assume an individual is authenticated at the IDP. The IDP could tell the SP that it knows who the individual is and e.g. a attribute of the user. The SP could take this information to provide services to the individual. An important aspect of this is that the SP trusts whatever the IDP tells it. That 's the point: the SP "outsources" (at least partly) things like authentication, profile management etc. to the IDP. The SP may have chosen to outsource these things either because it doesn't want to be bothered with them or simply can't do them on it's own.

 

Let's leave the world of IT a second and explain this with real life examples

 

Entering a foreign country

Assuming it's your fist visit to country B the only piece of authentication is your passport.At the border they use the passport to find out who you are (in case Interpol likes to have a chat with you) and if the profile information (picture, size, eye color etc.) matches your appearance. This maps to:

  • Trust in the issuing country (the trusted third party) that they issued the passport for somebody they know. "Authentication" is done remotely.
  • Use profile information collected and vetted for by the issuing country

Renting a movie

The rental place knows you by name. If you walk into the store and they recognise you.However if you want to rent a "18+" rated movie ("R" rated for you US colleagues) than they are obliged to check how old you are by looking at your divers license, passport or ID card. This maps roughly into:

  • Authentication is done locally (they know your face)
  • Profile validation (you are older than 18) is done by checking a document issued by a trusted third party.

Getting a drink in a bar in most parts of the USA

THey guy or girl behind the bar doesn't really care who you are as long as you pay and can give proof that you are old enough. This Maps into:

  • Order a alcoholic drink
  • Show the barkeeper a trusted photo ID. This could be your passport or driving license issued by a third party. This document contains your birth date.
  • Barkeeper does advanced math to determine your age based on your birthdate
  • You get a drink (or not... sorry kid).

No authentication done either locally or via trusted third party - they don't have to know who you are just how old you are.

 

In contrast here is how you get a beer in Germany:

  • Look old enough and order one

 

Back to IT - Some examples of ID Federation

Portal uses external IDP to authenticate users it doesn't know locally

A good example would be a customer from Europe back when there was a bit of craze about swine-flu (or bird-flu - can't remember which animal it was):A portal that handles the issuing of flu vaccination vouchers needs to be accessible not only for a bunch of users that can be authenticated locally with password or RSA SecurID but also by doctors. The doctors don't want to / can't use SecurID but they do already have a SmartCard they use to authenticate to some other systems. Instead of configuring the flu portal to work with the SmartCards and to know every single doctor (they do need an account of course) with all the profile information (name etc.) federation was used to handle all that. The doctors do authenticate to the foreign system (the IDP) as they use to already. If they want to access the flu portal (the SP) they get federated to it.The portal will know who they are and some profile information (e.g. Name) and therefore can provide whatever service a swine/bird-flu portal must provide. The advantage of using federation here were clear:

  • No cumbersome registration of the doctors at the portal.
  • Profile/account registration is not needed
  • Handling of all the dirty bits of certificate authentication (revokation etc.) is not needed - the IDP takes care of that.
  • If something changes on the other side (name change, new certificate, even new CA) it doesn't matter
  • The doctors don't have to change the way they work. They simply see the swine/bird-flu portal as another source of information that is available to them.

Company likes to provide the employees SSO into a external training portal

Without federation the users would need to authenticate again when accessing the training portal - even if it looks like an internal resource it feels external with all the issues such as managing the password, profile information etc.

 

Additionally the information about who reports into whom is not at that training portal but only in the internal MS ActiveDirectory.

Without federation this information would need to be send to the training portal manually using some kind of batch job or maybe some form of agent that syncs the data into the portal every day.

With federation not only would the users have SSO but during federation the information about the user's manager could also be transferred.

This would then enable the managers to see which team members took the training already.

 

The company would be the IDP and the training portal the SP.

 

Inter-Service communication

Here it get's a bit harder to understand because there is (hardly) any end-user involvement.

This is about one service communicating with another. No user interaction.

Webservice (SOAP) A likes to call webservice B.

B needs to authenticate A or even needs to know who told A to ask B to do something. In other words B may need to authenticate the service A and/or may need to know who originally called A and triggered the SOAP request to B.

 

Let's assume user X orders something from portal A. To fulfill the order one of the things that A needs to do is to tell webservice B to send a bill to X and service C to get money from X's credit card.

 

"A" could send a SOAP request to B telling B to mail a invoice to X. B may be an external service.

B should know who A is and if A is authorised. Federation could be used for the authentication part. A basically tells B "I'm A and I need a invoice with content abcd send to X".

 

An even stronger argument for identity federation in a web service environment is if a webservice needs to know who initially "pressed the button" that caused all those calls.

"A" needs to tell C that the user's credit card should be used to settle the bill. C not only likes to know who A is (that's almost a given) but likes to have proof that X really initiated all this.

 

"A" could send a SOAP request to C and use identity federation to  proof to C that X really was the one that placed the order.

That enables C to really trust the request as well as maintain a good audit trail.

 

Granted: this use case is a bit harder to understand - especially if you're not into web services.

 

What is this Howto about?

This guide will show you how to get Salesforce and SecurID Access configured in a way that makes SFDC a external identity provider to SecurID Access. This enables users to login to the Via Access portal using existing SFDC credentials.

 

Pre-conditions

  • SFDC instance with full admin access
  • SecurID Access instance with admin access
  • Shared user IDs (email addresses) between SFDC and Via Access
  • The logon ID format that Via Access expects must be what SFDC is configured to return e.g. eMail address)

IDP configuration on the Salesforce Side

Log into SFDC with an admin account.In the lower left corner you'll then see a menu called "Administration Setup".(If that doesn't show up click on "Setup" on the upper right corner)

Bare-bone IDP setup

Select "Security Controls"->"Identity Provider"SFDC_as_IDP_25.pngYou need to click on "Enable Identity Provider".In the following screen select "Create a new Certificate..."SFDC_as_IDP_26.pngGive the certificate a meaningful nameSFDC_as_IDP_3.pngHit "Save" and you'll see a screen with the details of the newly created certificate.You should download it by clicking "Download Certificate" - we'll need it later.SFDC_as_IDP_4.pngNow comes a strange step... either to back to the "Identity Provider" section like before or click "Back to List" on the certificate detail screen.Either way... you'll need to click again on "Enable Identity Provider" and this time select the certificate you just created.SFDC_as_IDP_5.pngOnce you clicked "Save" on that screen you are finished with the bare-bone IDP setup. You'll see a summary screen similar to the one below:SFDC_as_IDP_1.png

Setting up the Connected App (aka SP) definition at SFDC

From now on it's a good idea to have a separate browser window or tab open in the Via Access admin console.This part jumps a bit between Via Access and SFDC so be patient and pay attention.On your Identity Provider Setup screen click on the "Service Providers are now created via Connected Apps. Click here." link - or go to "App Setup"->"Create" ->"Apps" and then click "New" in the "Connected Apps" section of the screen.... I never said it's going to be easy.You'll see a screen like this:SFDC_as_IDP_27.pngFill in what you know or can make up on your own already:Names, email addresses etc.Provide your IDR portal URL for the "Start URL" in the "Web App Settings" sectionClick on "Enable SAML" in the "Web App Settings" just below the "Start URL" field.SFDC_as_IDP_28.pngNow we need to switch over to Via Access

Adding a SAML 2.0 IDP definition in Via Access

In RSA Via Access to to “users”→”Identity Providers” and click “Add an Identity Provider”.SFDC_as_IDP_8.pngClick "Add" for the "SAML 2.0 IDP"SFDC_as_IDP_9.pngGive it a meaningful name:SFDC_as_IDP_10.pngClick "Next Step"... the "Connection Profile Section" appears.

Let there be "Copy & Paste" - copying information from SFDC to Via Access and vice versa

This is the screen that has the info that you need to either fill in from the SFDC screen or that you need to copy over to SFDC.

Leave the Audience ID as it is and the Audience URL too.

  • Copy the Audience ID from Via Access and paste it into the SFDC screen under “Entity ID”
  • Copy the Audience URL from Via Access and paste it into the SFDC screen under “ACS URL”.
  • Copy the Issuer from SFDC into Via Access “Issuer ID”.
  • Copy the “SingleSignOnService” HTTP-Post binding URL from the SFDC Metadata file to the Issuer URL in Via Access
  • Upload the Certificate you downloaded earlier from SFDC by hitting “Select File” in the “Certificate” section of RSA Via Access and selecting the downloaded file.
  • Note on the SFDC side "Subject Type" was left at the default "Username". As username in SFDC is the email address you need to make sure Via Access is configured to accept the email address for logon. This is done in the "User store" section in the Via Access admin GUI. The "User Tag" must be "mail" (or email... depending on your LDAP schema). If you have it configured to accept sAMAccountName and you then use SFDC which sends eMails by default, you will be logged in but the user can't do anything.

SFDC_as_IDP_12.png

SFDC_as_IDP_13.png

 

The next screenshot is just FYI. It shows the user store setup of Via Access. Note the "mail" as the User Tag. If you have done that previously you are all set. If not... change it to "mail". The alternative is to configure SFDC to send the content of e.g. sAMAcountName - but that of course requires that this information is in SFDC. This could be e.g. the federationID or a custom attribute in SFDC. For this exercise we just assume everybody uses email as the login ID - which is common now.

SFDC_as_IDP_30.png

 

 

Just for clarity... here is a screenshot of my SFDC IDP metadata XML file. Look at the URL I highlighted. That's the ACS (assertion consumption service) URL of SDFC. SFDC supports both POST and redirect binding for AuthNRequests - Via Access supports one POST so you have to copy that one.

SFDC_as_IDP_17.png

 

In SFDC you now need to grant permissions to the appropriate user profiles to be able to access the "Via Access" Connected App. Without this SFDC will deny access (and with that outbound federation) every time.

 

On the "Connected  App" screen of "Via Access" scroll down to the "Profiles" section and click on "Manage Profiles":

SFDC_as_IDP_22.png

 

Now you need to select the user profiles you want to be able to federate out to Via Access. In my case I selected both "System Administrator" and "Standard Platform User". This might be different in your environment. Standard Platform Users are the "normal" users and should work for most. The test user I used is an administrator so I had to select that profile too.

 

SFDC_as_IDP_23.png

 

Click "Save" and then head back to Via Access.

 

Configuring the Authentication sources for Via Access

 

Now you need to add the newly defined SFDC IDP to the Authentication Sources of Via Access.

Click on “Access” → “Authentication Sources” and hit “Add”. Select “Salesforce” and hit “Save”

SFDC_as_IDP_14.png

Now it should look something like this:

SFDC_as_IDP_15.png

Publish the changes to the IDRs.

Then head over to the IDR portal

How the login into the IDR portal looks and behaves now

If you access the portal you'll see a new link at the bottom of the logon box that points to your SFDC IDP

SFDC_as_IDP_19.png

Click it and you'll be redirected to SFDC

SFDC_as_IDP_29.png

 

You can customize this page (left and right side) in the configuration screen of your custom domain. If you don't have a custom domain the standard SFDC login page will be shown.

 

Once you logged in you'll be redirected back to Via Access and see your portal page for the user you logged into at SFDC:

SFDC_as_IDP_24.png

 

-> Success!

Filter Blog