Chris has an interesting post about user experience around OpenID - Does OpenID need to be hard?
I raised the issue of Nascarization more than an year ago . There should be one OpenID button. Not two. Not three. Else it’s not scalable for the relying parties. And it’s confusing for the user.
OpenID isn’t new in terms of the user flow. Every other SSO type protocol (SAML, WS-Fed, OAuth) essentially has the same flow where the user shows up at the RP, authenticates at the IdP and logs in at the RP. VerifiedByVisa, PayPal user flows aren’t much different either.
They all also have the the following major constructs (one could argue that different protocols could learn/leverage from each other, but let’s not go there) :
- Token format
- Key Management
Discovery is the hardest since that has the most impact on user flow. SAML doesn’t really have to face the issue to the same extent as OpenID since most SAML federations today are in B2B with limited or clearly defined IDPs.
Great to see the acknowledgment of the issues and a focus to address the problem. I’m hoping to see more developments in IDIB and/or a cleaner discovery service. And as a user, I get my one button.
Speaking of elephants in the room, it would be nice to have some agreement on a way to exchange attributes/claims between IdP and RP. As it stands today, I can use SReg, AX or OAuth. There is definitely some overlap there and the lack of clarity often results in “wait” for most implementors.
Since last fall, I’ve been going to Denver University for my EMBA program. This quarter a team of us were to present a paper and as it turned out, our topic was privacy. Even though the topic was broader and we were required to cover many other aspects of privacy as – workplace privacy, citizen privacy, privacy laws and statues in the country and so forth, we found it interesting to add in a piece for consumer privacy. As part of our class presentation, we picked a fellow student (hey Toby!) and simply by knowing his name, in less than 5 minutes, we were able to find his:
- Date of Birth
- Home Address
- Phone number
- Home Price
- Cars that he drive
- Previously known home addresses
- Wife’s name
- Relatives names
- Mortgage info
- Employer Info
- School Info
- Pictures of him and his family
Here are some of sites that we used to get this information:
And interestingly enough, while doing so we didn’t break any laws (nor did we spend any money – a lot more is apparently available for $9.95).
Now…in the past few years I have spent decent amount of time going through the use cases around user’s personal information especially date of birth. Should we exchange ‘DOB’ or ‘Age’ or simply the claim that the user is ‘over 21′. I have read and articulated many times, Kim’s Laws of Identity and why user control and consent should be required and why RPs should respect the ‘minimal disclosure for a constrained use’.
However, I’m wondering the practicality of it. The privacy statement at the home page of http://www.birthdatabase.com interestingly states that “Our birthday data is obtained from public records and available to anyone with a simple knowledge of public record access.” If all of my information is publicly available anyway,what’s point of splitting hairs on what part of information should be shared. It’s not like it’s even possible to hide my age from anyone….and do I really care for the control and consent of the information on a per RP basis – information that’s available publicly for everyone.
A while back, Sun’s CEO Scott McNealy made a statement “You have zero privacy anyway, Get over it”. As much as I appreciate the thinking behind some of the identity laws, I can’t help agreeing with the sentiment that argues ‘Get over it’.
Now if the information is indeed protected by law, that changes things. But for everything else, why bother?
Here are some of the slides that were used in our class presentation.
I have started the new year with a new employer – Symantec. I’ll be part of Symantec’s new initiative around identity.
Past four years with Ping Identity had been an extremely rewarding experience. But I’m looking forward to the ‘power of yellow’.
James, my partner in crime had recently asked about features in federation products. I want to leave out the comparison part to analysts and customers since it’s very much depend on the end use case.
However (getting a bit specific), I was recently in a conversation on ‘why should the customer use PingFederate instead of a home grown solution to do SSO to Salesforce.com’ (SSO to Salesforce.com was the big focus for PingFederate’s latest release in September). Here are some of the reasons I came up with:
- Multiple access methods for Salesforce.com
- SP-Initiated SSO via Direct Logon: The user navigates directly to Salesforce.com, enters a corporate email address and password, and is authenticated via the PingFederate Authentication Service.
- IdP-Initiated SSO: The user logs on to an Identity Provider (IdP) application integrated with PingFederate. By clicking a specific URL that goes through PingFederate, the user can SSO to salesforce.com. The admin can choose to deploy this use case using either Delegated Authentication or SAML.
- SP-Initiated SSO via “Deep Linking”: The user clicks a link in an email to a Web page inside salesforce.com, which sees that this user has performed SSO previously and redirects the user to the IdP for authentication. After logging on, the user is redirected back to salesforce.com—to the “deep link”, rather than the default home page.
- SP-Initiated Single Logout (SLO): The user is logged on to salesforce.com and wants to log out of both salesforce.com and the IdP application. Upon clicking the logout link, the user is also logged out of the IdP application.
- Outlook Access via the Rich Client Proxy Service: The user is using the Microsoft Outlook plug-in that Salesforce develops and maintains. The plug-in stores the user’s corporate email and password, which are used to authenticate to the corporate LDAP directory via a Rich Client Proxy service. The user’s salesforce.com data synchronizes with Outlook; thus, by using PingFederate, the corporate credentials are not transmitted outside the firewall.
- Works with existing infrastructure: PingFederate provides out-of-the-box integration with a number of authentication and enterprise identity systems including Integrated Windows Authentication (IWA), LDAP authentication, CA Siteminder, Oracle Access manager, BEA Weblogic etc. You can find the up-to-date list of supported systems here.
- Automated account provisioning: Administrators create a group or filter to contain all Salesforce.com users in the existing corporate directory. As changes are made to user accounts in the corporate directory, PingFederate automatically replicates each change to Salesforce.com via the Salesforce.com provisioning API.
- Proven architecture: Over 30 customers are using PingFederate for SSO to Salesforce.com including Cox Media, Rearden Commerce, Cognos, LandAmerica and many others.
- Rapid Deployment: PingFederate can be setup for SSO to Salesforce in a matter of days. The latest release of PingFederate bundles a quick-connection template for Salesforce.com that automatically configures many of the settings required for Salesforce SSO as well as provisioning in the PingFederate administrative console.
- Standard/Independent server to manage SSO: Adding another SSO partner (internal or external) is as simple as adding a connection within PingFederate console. Other than Salesforce.com Delegated Authentication Protocol, PingFederate supports SAML 1.0, 1.1, 2.0 and WS-Federation.
Expect a call from our sales team, James .
Next week is DIDW and you are all invited to Ping’s party on Tuesday night. As always, expect a lot of fun. And lot of drinking. Hopefully, you would recover by Wednesday 3 PM for our session on ‘Identity Enabling Web Services’. I am really excited to get a chance to co-present with Eric Sachs (Google) and Peter Dapkus (Salesforce) and discuss some real world use cases revolving around API/Web service access.
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.
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.
- Go to http://autoconnect.pingidentity.com, type in your SignOn.com email address and click ‘Sign In’.
You will be redirected to SignOn.com for authentication and then SSO to autoconnect.pingidentity.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:
- Download PingFederate from here.
- 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.