So you want to be a millionaire? That’s easy. First, you get a million bucks…
So you want a secure SSO system? That’s easy. First, you get an authenticated user…
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.
- Go to http://autoconnect.pingidentity.com, type in your SignOn.com email address and click ‘Sign In’.
- The long version
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.
Just came back from our trip to India. It was a good break from the routine discussions in/around identity.
It was an amazing experience and I got to meet quite a few old friends and relatives. The environment in India has changed a lot since the last time I was there. Almost everyone I met is working crazy long hours and very happy about it. It seems like everyone realizes that there are growth opportunities and doing their bit to grab it. I remember reading an article a while back on how the IT in India is mainly services based. To me, it seemed like a lot of product based work is beginning to happen.
A buddy of mine shared the following statistics that reflects the optimistic attitude.
- The average age of population in India is ~24 years. Given the total population of the country is over a billion, this means a lot of young people.
- The middle class in India is ~300 million (close to the total population in US).
- The organized retail industry is still at ~2-3 percent. 97% of shopping happens at mom and pop shops. Prediction is to have the organized retail number up to 15% in the next couple of years.
- For the past few years, India’s GDP (Gross domestic Product) has been close to 8-9% compared to ~3% in US.
- ~500 malls are currently being built around the country.
- The telecom sector is growing with ~5 million new subscribers every month.
Net/Net – a very positive outlook.
I’ll be traveling to India later this week (reason why I’m missing out on IIW). It’s been a while. Our last trip was in 2003. And I’m told that a lot has changed since then.
I’m a bit leery of how the kids will handle the 15 hour flight, but I’m looking forward to spending some time with family and old friends.
One of the reasons behind launching SignOn.com was to compare and contrast different identity protocols. There are things that you can learn by reading the specs. And then there are things that you can learn by deploying/implementing the specs.
We have had support for OpenID and Information Cards for a long time. With the latest release, we have added support for SAML by leveraging PingFederate.
Additionally, we have integrated with Google Apps. Google Apps is a service from Google that features applications for mail, calendaring, docs etc.
This allows SignOn.com users to
- Add Google Apps services to their SignOn.com accounts (e.g. you can have an email address like firstname.lastname@example.org that’s hosted by Google Apps).
- Single Sign-On to Google Apps via their SignOn.com credentials (username/password or Information cards).
In order to enable your SignOn.com Google Apps Account, do the following:
- Login to SignOn.com (register if you don’t have an existing account).
- Go to My Profile tab and make sure that you have your firstname and lastname populated (we need this information to create your Google Apps Account).
- Go to My Accounts Tab.
- Scroll down and you will see ‘Partner Accounts’. Click Add. This will enable your account with Google Apps.
- Go to the home page again. And you should see another link e.g.<username>@signon.com. Click on this and this will take you to your mailbox.
- For the first time access, you will have to go through Google CAPTCHA to complete the registration process with Google Apps.
For future access, you can either go to your SignOn.com home page and click on Google Apps links (IdP initiated SSO).
Or you can access Google App services directly by going to the following URLs, and it will redirect you to SignOn.com for authentication (SP initiated SSO).
- Mail: http://mail.signon.com
- Calendar: http://calendar.signon.com
- Docs: http://docs.signon.com
- Start Page: http://start.signon.com
Appreciate any feedback.
- Persistent Storage for Amazon EC2: This new feature provides reliable, persistent storage volumes, for use with Amazon EC2 instances. The volumes will be significantly more durable than the local disks within an Amazon EC2 instance. Additionally, our persistent storage feature will enable you to automatically create snapshots of your volumes and back them up to Amazon S3 for even greater reliability.
- Google App Engine: Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.
- Arcot announced A-OK On-Demand Solution: Arcot Systems announced that its A-OK On-Demand solution is available for immediate use. This is a multi-factor authentication solution for Web-based, on-demand applications. The tool addresses the burning issue of stolen passwords with on-demand applications
- Google, Salesforce link up for business apps: The companies on Monday announced that Salesforce.com’s customers now have the option of using versions of Google Apps, Gmail, Calendar, and Google Talk that are tightly linked to Salesforce.com. Google is in effect becoming Salesforce’s productivity suite. Google documents, spreadsheets, and presentation can be created from within Salesforce’s CRM application. GTalk works as the de facto instant messenger within Salesforce.
- TriCipher Acquires Sxip User Manager: The AppExchange-certified solution, which will be re-named myOneLogin User Manager, is the only way Salesforce.com administrators can centrally enable and disable user access to both Salesforce.com and Google Apps from within the Salesforce.com application.
I’ll be at RSA Conference next week participating in the following events.
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
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.
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).
See you there.
- Share with everyone (a.k.a OpenID)
- Share with a selected few (a.k.a Shibboleth/InCommon)
- Share with the chosen one (a.k.a SAML, WS-Fed)
- Share with no one (a.k.a my kids and of course the identity silos).
Trust (using the word here in a broad, abstract way) has been one of the strongest reason for the OpenID adoption. The spec does not require for OPs and RPs to get together and discuss key exchange, business value, liability issues, attribute data and so forth. OPs and RPs work independently of each other and as long as they adhere to the core specification, things just work.
Trust has also been one of most critiqued area of OpenID. As an RP, why should I outsource my user authentication to someone I have never even interacted. Call me crazy but I don’t feel like accepting users from Iwillstealyourusers.com. There have been suggestions that it should be acceptable for the low-value transactions. But then, there is no definition of a low value transaction. And
beauty value lies in the eyes of the beholder.
All that led to the discussion of OpenID whitelist. One might argue that it’s against the spirit of OpenID. Anyone should be allowed to run an OP without contacting all the RPs to be added to their whitelist. On the other hand, it gives a cozy feeling to the RPs to only have a handful of trusted OPs (which by the way there is no way to determine; but that’s a topic for some other day).
One of the ways the concept of whitelist can manifest itself is for OPs to provide an ‘OP Button’ for the RPs. Yahoo did exactly that couple of months ago. It’s good for the users since they don’t have to remember their OpenID URL and the user experience is much better. Most of the RPs (at least the current crop) won’t mind accepting users from Yahoo. I figured sooner or later, Google and Microsoft will join the OP list (along with AOL), have their own set of buttons that RPs will happily accept;practicality will take over; the OpenID identifier as we know today will go under the covers; the small OPs will cease to exist. We’ll all wait for a couple of years and then start over.
Except…ClickPass launched last week with it’s own button. There are still some discussions on the what and the why of ClickPass. But beyond that, it does paint the picture of what the future RPs might look like – a Nascar billboard (with buttons and branding from every OP)…or something like this building.
This is where the discussions get into discovery, which is a really hard issue to address.
- This is how social news sites address this:
- This is how RSS Readers address this:
- This is how SAML address this : Okay…let’s not go there
The common pattern – a Nascar billboard.
So… David and I spent some time talking about this. This is still a ‘thought in process’ but I wanted to write it down before I get heads down into the RSA preparations.
- The user shouldn’t need to type the OpenID identifier.
- There should be one OpenID button. Not two. Not three.
- The RPs shouldn’t need to host the Nascar billboard (and hence add an icon every time a new OP comes on board).
- The user should be in control of his identifier and who to share it with.
IMHO, this is how it should work from a user’s perspective:
- I signup with any OP of my choice. Or setup my own OP.
- I enter my identifier once. On a client side component. Either a browser extension/plugin or a desktop client.
- I visit the RP and click on the single OP button. It invokes the client component and verifies if I want to share my idenifier.
- On clicking okay, it redirects me to the OP and rest of the OpenID flow resumes.
- If I don’t have the extension or haven’t picked an OP yet, it redirects me to a central (OIDF/Community hosted) Nascar page.
- The central Nascar page should host the OPs logos/buttons. It should allow me to pick my OP and redirect me back to the RP.
- Additionally, the central Nascar page should allow me to signup with a listed OP (redirect);add the selected OP to my client component; And allow me to enter my own OP(text field).
- No registration should be required by the Nascar page.
- What should be done to be listed on the Nascar page? – Well..that’s where some of the existing work that’s being done by SpreadOpenID, OpenIDDirectory and Nat comes into play.
As I write this, I do notice the similarities with the CardSpace flow. Ergo…it will be interesting if MS (now member of OIDF) adopts OpenID in the client.