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
  

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

• 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

• Redirect Binding for SLO

• 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

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
  

• Drive to standardized naming convention for EntityID’s

            1. abc.com becomes https://saml.abc.com/idp

            2.  App1 @ xzy.com

<!--[if !supportLists]-->

For Technical Details - Click Here

• Apache Integration Kit 1.0 (NEW) - enables secure Internet single sign-on to applications running on an Apache Web server.
• PHP Integration Kit 1.0 (NEW) - enables the integration of PHP applications to PingFederate, thereby enabling SAML & WS-Federation SSO to and from PHP applications. This integration kit is similar to the generally available kits for Java and .NET applications. Users authenticated by PHP applications can securely single sign-on to other applications over the Internet, and PHP applications can receive authentications via SAML or WS-Federation.
• Java Integration Kit 1.3 (UPDATED) - now forces the use of the Sun Java Cryptography Extension (JCE) on the agent JDK; if this option is not selected, the default JCE provider (SunJCE or IBMJCE) is used. In addition, you can pass or receive multi-value attributes in the SAML assertion and restrict that the PFTOKEN cookie (used between the Java application and PingFederate) is sent only on a secure channel.
• SiteMinder Integration Kit 2.0 (UPDATED) - now works with multiple SiteMinder Policy Servers. It also supports SSO zones (via SMSESSION token prefix-naming) and the passing of the Authentication Context/Method in the SAML assertion.

Announcing PingFederate Web Services 2.5 (formerly PingTrust) 

In addition, the updated PingFederate Web Services 2.5 (formerly PingTrust) is now available for immediate download. PingFederate Web Services is a full-blown Security Token Server, which now supports Version 1.3 of the WS-Trust specification and eliminates the XML C14N Transform Injection security vulnerability.

Announcing New Apache Agent for PingFederate Advanced Authentication (formerly PingLogin) 

The new PingFederate Advanced Authentication Apache Agent 1.0 is now available for immediate download. This new integration allows the PingFederate Advanced Authentication module (formerly PingLogin) to provide authentication and session management services (with little or no development work) in protecting applications running on Apache.