Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2016 > April


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:NameID  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">

John Doe




... and remove the clutter:




          John Doe




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


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:NameID  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">




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


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


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


"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="" 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" ID="_470ee542-ca32-11de-b313-cdf5016ad5a0" Version="2.0" IssueInstant="2009-11-05T17:40:15Z">
<saml:Issuer>TheBigFatIssuer</saml:Issuer><Signature xmlns="">
<CanonicalizationMethod Algorithm=""/>
<SignatureMethod Algorithm=""/>
<Reference URI="#_470ee542-ca32-11de-b313-cdf5016ad5a0">
<Transform Algorithm=""/>
<Transform Algorithm=""/>
<DigestMethod Algorithm=""/>
EwZDTkFNVFMxCzAJBgNV FAKE ==</X509Certificate>
     <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:Conditions NotBefore="2009-11-05T17:38:15Z" NotOnOrAfter="2009-11-05T17:48:15Z">

   <saml:AuthnStatement AuthnInstant="2009-11-05T17:26:50Z" SessionIndex="_470ee542-ca32-11de-b313-cdf5016ad5a0">
     <saml:Attribute Name="title">
       <saml:AttributeValue>Some kind of Manager</saml:AttributeValue>


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

SAMLBlocks (1).png



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


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.

Filter Blog

By date: By tag: