It was great to see Pam setup and configure PingFederate to accept PayPal OpenID and show login to Google Apps.
The following screen cast illustrates:
User accesses integralcurve.com (a Google Apps domain)
SAML SP Initiated SSO to PingFederate.
PingFed redirects to PayPal OpenID endpoint for authentication.
User authenticates at PayPal.com.
PingFed accepts PayPal OpenID response, creates a SAML assertion and redirects to integralcurve.
User is logged in to integralcurve.
Another feature that’s not shown here is to configure the solution for user’s to select their own IdP at run time. This can potentially allow Google Apps hosted enterprises to offer their employees a handful of IdP options (PayPal, Enterprise AD, Facebook…) and let the employees pick the one they feel most comfortable with.
I moderated a session at the recent SSO Summit titled “What is OAuth and WS-Trust, and where does it fit into your web services SSO initiatives“.
“User-centric identity” is past-its-prime and “Identity as a Service‘ has already been beaten enough. And hence I was glad to get a chance to dig into the services/API use cases (some of the which are very complementary to the browser SSO use cases).
Here are some of the scenarios that we discussed:
(Eve was the scribe…so I’m hoping she has better notes).
Server-2-Server mashup – User goes to travelsite.com and books his flight. And expects the travel site to make an API call and add an event to his Google Calendar.
Enterprise SOA – An enterprise had a legacy/maiinframe system. An overpriced consultant convinced them to put an SOA layer in front and expose the functions via a web application. The user logs in the web application (SSO or otherwise), makes an API call to the SOA layer and the system requires the call to be ‘identity enabled’ for security as well as audit purposes.
SSO + Data (User present) – User login to flight.com. Books his flight. SSO to hotel.com. Hotel.com has the username but requires the flight information – dates etc (transient data) to auto-populate the reservation fields. Hotel.com makes an API call back to flight.com to retrieve the data.
Desktop Client – SaaS vendor (think Salesforce etc) has a web front, which the customer uses to access their data. The SaaS vendor also makes the data available via an API (which can then be leveraged via an Outlook or Eclipse plug-in or a mobile version). SAML handles the browser based SSO use cases but the it gets tricky for desktop based clients when there is no browser present. The consumer equivalent of this will be TurboTax or MS-Money, which currently ask the users to enter their FI credentials to allow them to retrieve data on user’s behalf.
The OAuth vs WS-Trust/WS* has many similarities to the OpenID vs SAML debate. Much like OpenID, OAuth was started in the consumer centric world. Both the protocols boasts to be light weight, focus on limited set of use cases and does it very well. SAML as well as WS-Trust/WS* have roots in the enterprise world, require an engineering degree to be able to understand the specs but they are much ahead in terms of maturity and have gone through many security reviews.
However, in the case of OpenID / SAML, there seems be to a resting state - OpenID is the front-runner in the blog/consumer/social networking space (MySpace, Orange recently announced support for it) and SAML is the defacto in the enterprise as well as SaaS space (Google, and recently Salesforce announced support for SAML).
In the case of OAuth/WS-Trust, it’s a little less clear. OAuth seems to have a lot of traction in the consumer space (twitter, flickr, pownce etc). WS-Trust/WS* has better adoption in the conventional enterprise web services/ SOA space. However, the enterprise SaaS space is still open. The likes of Google Apps are trying to merge the lines between the consumer and the enterprise market. Google GData API recently announced support for OAuth (it supports SAML for browser SSO). And hence an enterprise with a traditional SAML/WS-Trust/WS-* infrastructure may be tempted/required to have OAuth support to access their data. Or they may ask their SaaS vendors to enable their APIs with WS*.
We have just enabled SignOn.com as an Auto-Connect IdP end point. What does this mean?
If you are an SP and are interested in evaluating Auto-Connect, you can now use SignOn.com as an IdP to validate your setup.
The short version
A few months ago, Ping Identity announced the concept of Auto-Connect. Auto-Connect eliminates the need of manual configuration for SAML connections. It relies on SAML assertion to carry user’s information but follows an OpenID style IdP discovery process; thus allowing the SPs and IdPs to connect dynamically. As an example, a user can simply type in his email address at the SP application to initiate the process, which then allows the user to SSO to the SP application via the Identity provider. To see it in action:
Go to SignOn.com and create an account.
Enable Google Apps for your account via My Account (more details here. This will give you an email address e.g. email@example.com.
What is Auto-Connect?
Majority of the SAML implementations today require a decent amount of configuration to setup a partner connection. This includes setting up the right bindings, profiles, certs etc. This model works for a limited number of partners but has trouble scaling as the number of partners increase. A few months ago, Ping Identity announced the concept of Auto-Connect. The objective being to avoid any manual configuration and setting up partner connections dynamically. The feature is especially useful to an entity who wants to provide SSO capability to a large number of partners. A Software-as-a-Service (SaaS) provider, for example, can provide SSO to innumerable clients without specifying redundant connection information for each one. Or an enterprise that has a need to SSO to multiple outsourced services. Once the initial setup is done, adding a new partner is simply adding the partner’s domain name in the white list.
How to try it out?
If you simply want to see it in action, we have setup a demo SP application at http://autoconnect.pingidentity.com. If you want to set it up for your enterprise, use the following steps:
Run through the PingFederate ‘Getting Started’ guide.
Set up your SP application (you can use any of the bundled sample applications as a starting point).
Enable Auto-Connect (configuring your metadata endpoint etc).
Add SignOn.com to your Auto-Connect whitelist.
Access the SP application and enter firstname.lastname@example.org.
User will be redirected to SignOn.com.
Authenticate using userid/password or Information card.
User will be redirected to the SP application.
SP application will display the user’s attributes as specified in SignOn.com.
What happens behind the scene?
User sends a logon request with an email address to the SP application. For example: email@example.com.
The application parses the email address and sends a request to PingFederate. For example: https://sp_host.com:9031/sp/ startSSO.ping/?Domain=signon.com.
The SP PingFederate server looks up the domain in the Auto-Connect white list.
If the domain is in the list, the SP retrieves connection metadata from the IdP’s public endpoint. By default, PingFederate looks for the metadata by prepending http://saml to the domain. In case of SignOn.com, the metadata is hosted at http://saml.signon.com.
After validating the metadata, the SP sends an authentication request to the IdP’s SSO service.
PingFederate IdP server at SignOn.com verifies the domain name of the requester.
The IdP retrieves the SP’s metadata via its public endpoint and verifies the metadata signature.
The IdP requests user authentication (SignOn.com supports username/password and Information Cards for authentication).
Once the user is authenticated, the IdP returns a signed SAML assertion to the SP’s Assertion Consumer Service (ACS) endpoint.
The SP logs the user on to the requested resource.
Slideshare doesn’t handle animation very well. So here is a run-down on the final demo.
In addition to demonstrate inter-operability with other vendors, I was able to show how to login to Google Apps, using SAML IdP/Infocard RP from Ping, CardSpace from Microsoft and an information card from Sun. In terms of platforms, Sun’s server was running on OpenSolaris, Ping’s on Linux, CardSpace on Windows XP (which in-turn was running on Mac OS X) and Google’s on ‘whatever they run over there’.
I’ll be at RSA Conference next week participating in the following events.
Concordia What: The current goal is to demonstrate that SAML, WS-Fed and Information cards can co-exist and some of use cases where it makes sense. For instance, if you already have a federation setup (using SAML or WS-Fed), you can leverage Information Cards as an authentication mechanism and tighten the security. Similarly if you are planning on authenticating using an Information Card, you can extend the reach (and hence get more value for your investment) by federating using SAML/WS-Fed. Who: Fugen, Internet2, Microsoft, Oracle, Ping Identity, Sun, Symlabs. When: April 7th, 9AM-12:30 PM Where: Red Room 302, Moscone Center North/South, Esplanade level
OSIS What: This is an interop event where you will get to see most (if not all) of Information Card as well as OpenID providers and consumers. What started off as an informal interop session at IIW, now has 57 participants. A lot of credit for this goes to Mike, Dale and Pam for continuing to encourage (read harass) other participants. Who: 33 Companies. 24 Projects. 57 Participants. When: April 8th, 9th. Working session 11AM-4PM. Demos: 4-6PM. Where: Mezzanine Level Room 220, Moscone Center.
Mix-it-up What: This has now established itself as a standard event at the main identity conferences. This is where we leave the vendor, customer, big enterprise, small company hats behind and just have a good time. Most end up getting wasted and missing out on their next day appointments. Who: All available. When: April 8th. 6-8 PM (it’s not really going to end at 8). Where: 111 Minna Gallery (Tel: 415.974.1719).
Borrowing from one of Dick’s presentation – federation needs to become a Viagra solution (i.e. giving more powers) and not just a painkiller (i.e. solving an immediate pain). More and more enterprises are accepting the SaaS model and outsourcing their key business data and functions. Security is an obvious concern for all of these SaaS vendors. However, there are hardly any SaaS vendors that support standard federation protocols. And I believe one of the reasons is that they consider federation as part of a security solution (i.e. painkiller) and not something that can add more value to their business proposition. I agree with Mark and Eric that federation needs to become a cello tape and an enabler.
One more thought on the love and trust linkage. One of the fellow identerati told me this:
Identity federation is like high school sex. Everyone is talking about it. But hardly anyone is doing it. And even the ones that are doing it, are not doing it right (and not for the right reasons either).
For federation to be long lasting, there should be love. And trust.
I heard a great line recently. Michael Price – one of the senior guys at Evercore and a long time friend (we were on the PeoplePC board together) was interviewed. Buried in the middle of a bunch of questions was a gem when the interviewer asked Michael about trust. The following popped out:
“Trust is the business word for love.”
How this relates to SAML (which requires pre-established trust) and OpenID (which requires no trust) is left as an exercise for Paul .
Paul is right. They have met before. But this is different since both have reached a certain point of maturity and have proven themselves.
Interestingly, on both occasions, it’s the SAML kid that’s making an attempt. He is definitely feeling insecure;which is ironical given it’s the more secure, mature protocol and all that. But then, may be you get wiser and more accomodating as you grow.
Regarding the Zen comment, we all need to empty our cup; Or get a bigger one; Or make a hole at the bottom; or start drinking faster;or just switch to beer and then I know that your cup will never runneth over.