ADFS V2.0 Lingo

Patrick Harding is the CTO over at Ping Identity. His post on “ADFS 2.0 – Learning the Lingo” is worth a read so you clearly understand the difference between the way Microsoft defines the various bits of their federation goo and how that translates into the way that non-Microsoft federation goo has been described. As Patrick says:

“…we all need to make sure that we can speak the same language.”

Indeed we do. Here’s his post – and like one reader commented, you can substitute Sun, CA or whomever you favorite non-MS federation software vendor is with “Ping” below…
 
This week Microsoft announced that ADFS 2.0 was GA. For those that have used PingFederate for some time, I thought I'd normalize the terminology that Ping Identity and Microsoft use to describe similar concepts when enabling identity federation. I make no claims (no pun intended) that one set of terms is better than the other, just that we all need to make sure that we can speak the same language.
ADFS terminology centers on the notion of an STS, Security Tokens and Claims.

STS (Security Token Service)
Microsoft asserts that an STS is a Security Token Service that issues/validates Security Tokens that contain Claims about a Subject.

PingFederate and ADFS are both implementations of an STS.

Further, the STS can play different roles. An IP-STS (Identity-Provider STS) is an STS that authenticates a subject, and issues a security token on behalf of that subject, while an RP-STS (Relying-Party STS) validates that security token and returns the claims contained within the security token.

PingFederate in IdP mode is an implementation of an IP-STS.


PingFederate in SP mode is an implementation of an RP-STS.

Lastly the STS can be used with different clients – a Passive STS interacts with a browser while an Active STS interacts with a client, web service or web application.

PingFederate in regular Web SSO mode (where you are using one of the SAML1, SAML 2 or WS-Federation Web SSO protocols) is an implementation of a Passive STS.

PingFederate in STS mode (where you using the WS-Trust protocol to support security token processing on behalf of a client or application) is an implementation of an Active STS.

It is this last definition that can cause some confusion when comparing ADFS and PingFederate as Ping has historically had a much narrower definition of the term STS. This is as a result of the STS term being specifically defined as an entity in the WS-Trust specification and that we then mapped directly into our product.

When PingFederate is enabled as an IdP for Web SSO; it’s a Passive IP-STS.

When PingFederate is enabled as an SP for Web SSO; it’s a Passive RP-STS.

 When PingFederete is enabled as an STS (using WS-Trust) to issue a SAML token on behalf of a client or application; it’s an Active IP-STS.

When PingFederete is enabled as an STS (using WS-Trust) to validate a SAML token one behalf of a client or application; it’s an Active RP-STS.

Still with me? Lets keep going.

Security Tokens
When security tokens are discussed in the context of ADFS and its support of WS-Federation and WS-Trust, Microsoft is actually talking about SAML Tokens. Further confusing matters is that Microsoft has been fond of saying ‘we support SAML’ when they actually mean SAML Tokens carried in WS-Federation/WS-Trust messages rather than the SAML 1.1/2.0 Web SSO protocols.

Ping always specifies the type of security token that is being processed, whether it is a SAML Token, Kerberos Ticket, X.509 Certificate, Password, SMSession Cookie, OpenToken, etc.

Claims
Microsoft defines a ‘claim’ as a statement about a user that is used for authorization purposes in an application. These claims are conveyed in security tokens, which as I described above are quite often actually SAML Tokens. When using WS-Federation and SAML 1.1/2.0, the ‘claims’ themselves are actually included in the AttributeStatement of a SAML Token as Attribute name/value pairs.

PingFederate 'attributes' are equivalent to 'claims' .

Microsoft defines a ‘claims aware application’ as an application that uses claims to make authorization decisions. Generally these claims have been made available to the application via ADFS. PingFederate’s design philosophy has always been to integrate with applications by passing user attribute information into and out of web applications. This attribute information is, at a minimum, a user identifier.

Every application ever integrated with PingFederate is a ‘claims aware application’.

Lastly Microsoft defines ‘claims transformation’ as the ability for ADFS to transform existing claims and import claims from other identity data sources. Ping has historically called this attribute mapping., which involves performing a user lookup against an identity store and mapping user attributes dynamically.

PingFederate 'attribute mapping' is equivalent to ‘claims transformation’ .

I am sure there are others, but I believe I have captured the major terminology differences. Look for some follow up posts that highlight some of the other differences between PingFederate and ADFS 2.0.

Technorati Tags: Ping Identity,PingFederate,Microsoft,ADFS,federation,identity management