When I started Ping Identity back in 2002, fresh off my Jabber experience, I made a commitment to leave the protocol wars to others. Having found myself in a position where Jabber was simultaneously trying to create a new standard (XMPP), and also build great software, I realized how tough that was to do. Due only to great and determined people at Jabber that continued on after I left, they've succeeded on both fronts.
With that experience still fresh in my mind however, I concluded that Ping Identity should spend the bulk of our energy building great software to an existing agreed to standard. While I believe this was the right approach for the time, I find today's deployment reality of SAML falling just short of that required to achieve a real market tipping point. Note that I do not believe the SAML specification is deficient, in fact, quite the opposite, it's almost too robust. If you look at today's reality of SAML deployments, you'll notice the following reality:
- SAML Web SSO primarily used for B2B interactions
- Mostly IdP Initiated and Form POST
- Real business value is being realized
But,
- Takes weeks (in the best case using PingFederate) to establish a Federation Connection with a Business Partner
- Mixture of technology and business issues need to be coordinated
Net/Net: Current federation paradigm Will Not Scale to 100’s of partners
If you really take a look at what's going on, its not hard to identify where all the friction gets introduced. While not all technical, there certainly is a lot of technical friction to deal with, namely:
1. Partners must negotiate which of many SAML options to use
- Multiple profiles & bindings
- Multiple identifier options
- Flexible attributes
- Authorization overloaded onto authentication
2. Service Providers NOT leveraging SP-Initiated SSO - IdP Selection/Discovery is poorly defined
3. Products implement manual partner meta-data export/import
4. Certificate Management is problematic
- Trust established through manual exchange of certificate
A New Paradigm?
What if every time you wanted to send an email, you had to get your IT administrator to coordinate a secure connection between your email server and the email server of the receiving company? I seriously doubt if email required this level of pre-configuration, Internet email would have become as ubiquitous as quickly as it did.
Pondering this question, and taking seriously the entire notion of how to enable a network effect in federated identity, we’ve started inventing something entirely new for the SAML community to consider.
We’re referring to it as ‘dynamic federation’ or dynamic SAML, because it’s designed to leverage the inherent security of SAML and without changing the specification (but instead simply adding some conventions on how it’s used), make SAML single sign-on completely automatic.
To make dynamic federation a reality, we needed to tackle how an Identity Provider was discovered when a user showed up at a Service Provider, and to solve that problem, we borrowed what I think has been a really great idea from the OpenID community, namely their use of a URL to help identify where the identity provider data could be retrieved. But instead of using a new identifier (e.g. an identity URL), we simply required a user enter their email address.
While this may or may not stick in the B2C use-cases, in the B2B world, corporate email address is a commonly used corporate identifier, and as such, it’s completely appropriate to use when the enterprise is also acting as the identity provider in a federated SSO interaction.
The results of our work effectively eliminates the notion of manual configuration of a SAML-based SSO interaction between two or more entities. Instead, companies simply designate which partners or customers they trust, or have a pre-existing relationship with (by domain name), and everything after that is completely automatic. The configuration couldn’t be easier, literally, you type the domain name of your partner, hit save, and you’re done.
From an end-users perspective, imagine if I was an enterprise user of Salesforce.com and SF.com leveraged dynamic federation to enable enterprise SSO to their on-demand application. The experience from the user’s point of view would work something like this:
The New End-User Experience
- user navigates to the relying party login screen as usual
- user sees a new login option, which simply asks them to enter in their email address
- after typing in their email address (a one time thing), the two SAML servers (with dynamic federation support) would auto-configure themselves for a secure SAML connection.
- on all subsequent logins, if the user has already logged into their corporate network, they will experience seamless single sign-on into the relying party from then on forward.
- no manual IT configuration of a SAML connection is required. Everything is 100% automatic.
To achieve this and not change or break the SAML specification, we had to narrow the use-case down significantly and also introduce several ‘conventions’ which attempt to standardize how this would work in not just our product PingFederate, but every vendors product.
It’s worth saying that we will publish everything we do, and we’ve opening communicated our intentions and our specifications with Sun, Concordia, Internet2 and several other groups, in the hopes that they implement the conventions and/or standardize them as appropriate. For the more technical in the crowd, here are some of the details of what we're doing.
Initial Focus - Two Use-Cases Only
1. Business to Business
- Enterprise Employees Accessing Outsourced Application Service Providers (e.g. SaaS, BPO)
2. Citizen to Government - Citizens Accessing Government Agency Services
- Government agencies prefer no TTP’s
How We Did It
Step 1: Reduce SAML Options
- IdP-Initiated and SP-Initiated Web SSO/SLO
- POST binding for SSO
1. >90% of federation implementations use it anyway 2. Artifact Binding adds significant complexity 1. SOAP Binding adds significant complexity given limited use - AttributeStatements are optional but SP must understand
Step 2: Fix IdP Discovery
- SP-initiated SSO must break out for federation to be truly dynamic and scalable
- Conventions are the key
- SP should leverage user’s email address to derive user’s Identity Provider
1. Discovery Service asks user for email address 2. Determine IdP via domain name
Step 3: Meta-Data Discovery
- Partner meta-data must become auto-discoverable
- Leverage ‘Well Known Location’ Meta-Data Discovery
- This mechanism uses your SAML EntityID
1. So EntityID’s must be a URL
2. Again conventions are the key - Drive to standardized naming convention for EntityID’s
1. abc.com becomes https://saml.abc.com/idp
2. App1 @ xzy.com
<!--[if !supportLists]-->
