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

They’re back! CLEAR is back.

Nearly a year later and CLEAR is back! And, they are excited to exceed your expectations.

CLEAR is back and under new ownership. We are transforming the CLEAR service, and with it your travel experience. For those of you who are not familiar with CLEAR please click here to learn more about us.

For our existing members, we appreciate your patience and loyalty. It is important for you to know that we will honor your remaining membership terms. The new CLEAR is a customer centric company - we want to rebuild it with you and for you.

Please click here to provide us with your current information and we will keep you up to date on the details of our progress.

The new CLEAR team is excited to exceed your expectations.

Last year I blogged a couple of times about CLEAR:

• CLEAR is still unCLEAR
• CLEAR is dead. What about my retinal scans?

The new CEO is Caryn Seidman Becker. I couldn’t find out much about her or the new backers. In any case I really doubt I’ll be re-joining CLEAR. Why not?

1. The airlines control priority lanes at most airports. At most airports I can jump to the front of lines or join an “express” line with my airline status.
2. At some airports the CLEAR lane would merge into other lanes so you really didn’t a jump on things.
3. The TSA has done a much better job of speeding things up and the rotten things about security you will still be subject to whether you have CLEAR or not – like full body scans (aside: I prefer the European full-body pat down!).
4. CLEAR is not owned or run by the government. How long does Caryn last before we go through this again?
5. CLEAR is not everywhere – certainly not in my home airport of Seattle. Oh, and it was closed everywhere. Now they have to re-build their network. Can they be successful? Who knows.

Last but not least: My CLEAR membership expired. By what right does the new company “get” my retinal scans and biometrics? Perhaps Ms. Becker would state that in the FAQ what they are going to do with expired membership data. It’s unCLEAR what will happen to former members data who do not re-join:

Q: Is my personal data safe?
A: Our member’s biographic and biometric data has been stored in a secure facility since June 2009, when the former company shut down.  In the next 30-60 days, that data will be transferred to another secure facility governed by the appropriate safeguards.

Q: How will the new CLEAR be handling privacy issues?
A: We will publish a privacy policy reflecting the information practices of the new CLEAR program.  By opting in, former CLEAR customers may join the new program, at which time their personal information will be governed by the new privacy policy.  In the meantime, we will abide by the terms of the privacy policy issued by Verified Identity Pass, the former owner of CLEAR.

I just don't see the value anymore - sorry CLEAR.

Technorati Tags: FLYClear,CLEAR,Caryn Seidman Becker,Alclear,biometrics,privacy,identity management

Top 10 IAM Challenges for Heterogeneous Enterprises

Enterprise Journal has published a two-part series I authored on this topic on their website.

An enterprise with a complex, heterogeneous environment faces many challenges when it comes to identity and access management (IAM). Too many identities and directories; inconsistent password policies across systems; diverse, time-consuming auditing processes; too much repetitive manual work; and the ever-increasing need to stay on top of compliance regulations are among the huge challenges faced by IT in an environment of multiple operating systems and applications.

This first part of a two-part series examines:

• Multiple identities and directories
• Single sign-on
• Synchronization
• Inconsistent password policies across systems
• Traditional Unix directories (NIS) vs. compliance

The second part takes a look at:

• Auditing
• Entitlement management
• Excessive manual/repetitive work
• Compliance
• Original purchase versus original expectations

Take a look and I hope you enjoy it.

Technorati Tags: identity management,QSFT,Quest Software,Jackson Shaw

Update: Extend your Corporate Active Directory Boundary to your Blackberry!

I blogged earlier on this topic here. Now that Research In Motion's WES 2010 conference is over the slides from the session are available here. In a nutshell, the benefit of the Quest/RIM partnership is all about extending single sign-on capabilities to BlackBerry® phone users and BlackBerry administrators. Here are some of the details:

• Use Active Directory for authentication of your Blackberry phone and achieve single sign-on
• Authentication to AD Using Your Blackberry phone to become a trusted network user
• End-to-end authentication between users and backend services without logging in from your Blackberry phone
• Single sign-on is enabled for Blackberry Enterprise Server administrators when they access the BES console

All of this was enabled through the use of Quest Single Sign-on for Java. One of the key benefits in using Quest Single Sign-on for Java is our support of Microsoft’s Kerberos extensions (S4U2Proxy & S4U2Self). These extensions enable the BES server to obtain a Kerberos ticket on behalf of the end-user. This means that all security – like when you are accessing an application via the Blackberry – occurs in the context of the end-user. So what’s the end result?

1. BES administrators will be have single sign-on enabled to the BES console. No need to enter their credentials.
2. Blackberry users will have single sign-on enabled to internal corporate resources via their phone’s browser. No need to enter their credentials.

Cool stuff!

Technorati Tags: RIM,BlackBerry,identity management,single sign-on,Kerberos,SSO,BES,Quest Software,QSFT