I wanted to share an idea that we have been elaborating on here at Ping. As a part of the work we have been doing for TV Everywhere we have been thinking about how to simplify the IdP Discovery problem. As a result we have come up with a mechanism that we call PingPong aka Browser Based IdP Discovery.

You can download the overview document  here, and view a demo here.

While we developed this in the context of TV Everywhere where the current protocol of choice is SAML 2.0, we think it also  has some applicability in the social media/consumer IdP world as well.

PingPong was not intended  to be a direct response to xAuth, as we were actually working  on this prior to the xAuth announcement. Obviously, comparisons between PingPong and xAuth are going to be made. In my opinion there are different pros and cons to each approach. The most obvious difference is that xAuth currently requires a centralized service while PingPong supports a decentralized model for IdP Discovery.

PingPong is protocol agnostic and works just as well for SAML as well as OpenID. We think it will scale well up to 100 or so possible IdP’s, but is not an option in the context of Enterprise SaaS (who can deal in 1000’s of IdP’s). I think that having the user enter an email address or domain name continues to be the right approach in that case.

We are looking for feedback so please join the discussion group and share your thoughts. In addition, we will be doing a demo and discussion session at IIW on Monday or Tuesday next week.

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.

Earlier this week I discussed SAML and how it meets the requirements around TV Everywhere authentication.  While SAML 2.0 looks to be the de facto solution for solving the TV Everywhere authentication problem, there is still some debate as to what mechanisms and protocols will be used to address how authorization decisions are made by the MVPD’s on behalf of the programmers. XACML is the leading candidate, but XACML is only a starting point that defines the syntax for expressing an authorization query and an authorization response.

The first question is to define an appropriate back-channel protocol to convey the XACML authorization queries and responses between programmers and MVPD’s. This could be achieved via the XACML profile for SAML, or even via a simple REST API.

In addition a TV Everywhere specific taxonomy for authorization queries that programmers ask of MVPD’s needs to be defined. This taxonomy is dependent on the business rules that will be established for TV Everywhere. For example, if the user is trying to watch an R-rated program then the programmer needs to check with the MVPD before making the content available to the user.  The query could be one of ‘What is the users birth date?,  ‘Is the user over 18?’ or ‘Can this user watch Mature content?’.  

Another issue is that, unlike books and ISBN numbers, there is no globally unique identification system for programming content. Each MVPD and programmer has its own content classification and identification system. This becomes problematic if the MVPDs need to make authorization decisions based on the specific program each user is attempting to watch.  What do you do in federated authorization model where the object or resource (i.e. the program) is known by a different identifier at the programmer and the MVPD? Best case is to define an MVPD neutral identification scheme for all programming content.

The TV Everywhere industry is driving to have this all wrapped up by September 2010. It should be a fun ride participating in this effort and watching it all unfold. 

….. and the solution is Federation.

Today we announced a partnership with BrightCove where PingFederate will be a key component of their TV Everywhere solution pack for content programmers. This is an extremely exciting opportunity for Ping as it puts us squarely in the middle of a high profile online media initiative that could shake up how consumers watch television programming. 

To put it simply, programmers like HBO, Showtime, Discovery, etc want to be able to make their programming content directly available to consumers via their web portals such as hbo.com, showtime.com etc. Today, they are explicitly prohibited from doing this, because they have signed exclusive distribution agreements with content distributors (cable and satellite providers commonly called MVPD’s) such as Comcast, Time Warner Cable, DirectTV, etc. TV Everywhere is meant to be a compromise whereby the programmers can make their content directly available to consumers, as long as the consumer can prove that they are a customer of a MVPD and have paid for the right to watch the content. You can get further background here.

From a technical perspective this becomes a federated authentication and authorization problem, and the leading solution candidate is SAML 2.0. Below is an example of what is expected to be a typical user experience:

Step 1: Alice goes to HBO.com to watch the latest episode of her favorite TV series.

Step 2: HBO must first determine if Alice has a valid MVPD subscription to watch HBO, and requests that Alice select from a list of supported MVPD’s  (e.g. Comcast, DirectTV)

Step 3: Alice chooses Comcast and is redirected to Comcast.net

Step 4: Alice successfully logs into Comcast.net with her Comcast credentials

Step 5: Alice is redirected back to HBO.com with a signed SAML 2.0 Assertion

Step 6: HBO.com successfully validates the SAML 2.0 Assertion

Step 7: Alice starts watching her favorite TV show at HBO.com 

Sound familiar?  This is SP-Initiated Identity Federation where the programmers become SAML 2.0 Service Providers, while the MVPD’s become SAML 2.0 Identity Providers

There are a number of user experience optimizations that are also being proposed. For example, if Comcast maintains a browser session for Alice, then Alice would not need to re-authenticate at Comcast if she went to different programmer such as Showtime to watch an episode there. I am pushing for the MVPD’s to take a leaf from Facebook and implement a Facebook Connect style authentication experience.

There are a number of profiling details that are still to be worked out so that all the MVPD’s and programmers implement a common SAML 2.0 solution. Much of this will be worked out via early prototypes from the larger industry participants, as well as through CableLabs who are defining a TV Everywhere authentication/authorization specification on behalf of the industry. Some of these outstanding questions include the appropriate SAML 2.0 bindings (POST or Artifact), the style of user identifier to use (e.g, pseudonym, anonym etc), what if any TV Everywhere specific user attributes must be included in each assertion etc. Fortunately PingFederate is flexible enough to support all of these possible scenarios out of the box.  I’ll have more on TV Everywhere in upcoming blogs.

 Pam Dingle and I have been recently discussing the pros and cons of using enterprise password synchronization tools with SaaS & cloud applications. We are hoping that we can convince everyone that pushing Enterprise passwords into the cloud is a bad idea and in our opinion is certainly not a security ‘best practice’.

Synchronizing passwords inside an Enterprise is reasonably common if you have a provisioning engine.  It is the next best thing to SSO, reducing the burden on users memories if not reducing their typing burden.  If you can push passwords from a central location such as Active Directory, help desk calls are reduced because one password reset fixes a bunch of applications, authentication becomes more about muscle memory than actual memory, and IT departments can demonstrate some streamlining in their processes.

We think a lot of people will make a simple leap towards wanting the same efficiency and automation in the cloud - but to us, this is a mistake of epic proportions.  There are critical differences between pushing a password around inside a domain and pushing a password to different domains, and we personally believe that in the latter case, the ends do not justify the means, and instead expose an Enterprise to a cartload of risk.

• At the time you push a password to the cloud, it has to be translatable to clear text.  It may arrive in an encrypted message with all the security around it in the world, but once you strip the transport-layer or even message-layer security off, that password is accessible to the SaaS service.   You as the Enterprise have given it away.   Hopefully your passwords aren't being stored in clear text in a database somewhere.  Hopefully your passwords haven't been skimmed by a script on their way in.  Hopefully the SaaS service you've contracted with has good security practices and honest staff.

• For every SaaS service you push passwords to, you multiply the number of people who might not be so honest, or so security conscious.

• Every external login screen you teach your users to type their enterprise credentials in represents a new phishing opportunity for attackers.

• Most Active Directory password synch tools require installing a specific software module on every domain controller. This module is needed to intercept the password changes before the password is hashed/encrypted in AD. Installing third party software modules on AD is usually an AD support/ops headache.

And yes, for the detail-oriented in the crowd, you could theoretically share a secret between the enterprise and the SaaS provider so that both parties could do password validation.  If you care enough to do that, you'd be federating with SAML already.

That brings us to the human element: every external login screen you teach your users to type their enterprise credentials into represents a new phishing opportunity for attackers.  A new window where muscle memory takes over and your corporate credentials are compromised.

Lastly, this isn't just about stealing access to a cloud resource.  This could result in compromise of internal resources, through externally facing web applications.  Imagine somebody sells a cloud-synchronized password list to bad guys:  If you don't synchronize passwords, this password list could have a percentage of overlap, simply because your users independently use the same password.  Your security folks have  at least a chance to detect a problem, because there are going to be a suspicious number of failed logins for the percentage of employees whose passwords match.  If you do synchronize passwords, you have 100% overlap - the bad guys can authenticate correctly all the time, every time.  If all you are tracking is failed authentications and lockouts, you won't even know you're compromised.

We tell end users all the time that it is dangerous to use the same password in multiple places.  Any enterprise that institutionalizes this practice is taking a well-known critical mistake, and multiplying that error for every single employee that they take care of.

So what’s the alternative to synchronization? Obviously having your users maintain different passwords at every SaaS application is just ad bad an idea. This is why we think SaaS/Cloud SSO is the killer app for identity federation. Enabling SSO means that your users leverage  a single, centralized authentication service where additional security controls such as strengthening the login process with multi-factor strong authentication.can easily be incorporated.

We announced a key capability in PingConnect™ today - Google Enterprise users can now leverage their Google Apps login to seamlessly access over 60 SaaS applications via PingConnect. 

So what’s the big deal and why should you care?

Our vision is that employees of all organizations (small, medium and large) should be able to seamlessly access the SaaS applications they need to do their job from anywhere, on any device, from any starting point. They should have this flexibility without needing to remember a litany of additional user passwords.

As such in PingConnect we started by providing support for the Windows Active Directory password.   This was a fairly simple choice, considering that the Windows password is a very common authentication credential that employees use when they are at work.  Note how I said ‘at work.’ 

What about when your employees are on the road, or start their day by logging into one of the Google Enterprise Apps such as Calendar or Sites, or your organization does not use or is migrating away from Active Directory, or all of the above?  What are your alternatives when the user cannot leverage or does not have a Windows password? 

We have no aspirations for PingConnect to be ‘yet another’ authentication service to solve this problem. The last thing our customers want or need is another PingConnect specific credential to remember and manage.  Further, Ping does not want to be in the business of user registration, identity vetting, password reset management, password security polices, etc. etc.  We have partners like Google who already do this extremely well.

This is why we decided that it made sense to leverage your Google login to access all of your SaaS applications.

But we aren’t stopping with Google. We have support for additional authentication sources in the pipeline and will be launching them soon.
 

I have noticed a lot of conversation (Pam Dingle, Ian Glazer, Pat Patterson, James McGovern, Nishant Kaushik) occurring recently about the differences between Federated Provisioning and Enterprise Provisioning. Dave Kearns  probably has the best summary of what has been discussed to date.

Federated Provisioning has been a concept we have been discussing at Ping Identity for the last couple of years. We wrote this paper over a year ago to provide some clarity to the synergies of Identity Federation and User Provisioning. If you are interested you can get a copy here.

Over the last 12 months we have added two forms of Federated Provisioning to PingFederate.  I actually prefer to call these capabilities Internet Provisioning to differentiate from the Enterprise Provisioning functionality provided by the large IdM products. The key distinction here is that we are keeping this simple and not looking to emulate all of the work flow, compliance reporting, etc functionality that you find in the IdM products.

The first capability is SAML based ‘Just in Time’ or Express Provisioning that leverages the SAML or WS-Fed protocol to convey user attributes that are used by the Service Provider to create a user account in the directory if it does not yet exist. The back channel SAML Attribute Query protocol can also be used by the SP to get additional user attributes from the IdP. Express Provisioning can be used by companies who have a SAML compliant federation server. It does not require them to buy any additional IdM products. We have a number of customers who use this functionality to great effect.

The second capability is SaaS Provisioning. This is the technology we acquired from SXIP. Both Salesforce.com and Google (and other SaaS vendors) have proprietary REST-based  CRUD API’s for automating user account management. Our SaaS Provisioning capability synchronizes the users in an LDAP Group with the SaaS application.  I am not expecting any SaaS vendor to adopt SPML any time soon unless pushed heavily to do so by customers. This mirrors what actually has happened with SAML over the last couple of years. To be honest I could actually see the Google API for user account management being replicated by other SaaS vendors and becoming a de-facto standard.

We also have some ideas on where SPML fits in. These will have to wait for a follow up post.