Category: SignOn.com

SignOn.com as an Auto-Connect IdP

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. joe@signon.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.

    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 user@signon.com.
  • 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?

autoconnect

  • User sends a logon request with an email address to the SP application. For example: joe@signon.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.

SignOn.com / Google Apps Integration

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.

Google Apps

This allows SignOn.com users to

  • Add Google Apps services to their SignOn.com accounts (e.g. you can have an email address like joe@signon.com that’s hosted by Google Apps).
  • Single Sign-On to Google Apps via their SignOn.com credentials (username/password or Information cards).

Your username for Google Apps will be the same as your user name for SignOn.com. For example, if your SignOn.com username is joe, your email address will be joe@signon.com.

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

Appreciate any feedback.

OpenID Thoughts

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.

dish

This is where the discussions get into discovery, which is a really hard issue to address.

  • This is how social news sites address this:

social bookmarking

  • This is how RSS Readers address this:

RSS

  • 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 requirements:

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

Thoughts?

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.

What is your mother’s maiden name?

A while back I spent some time researching into several strong authentication methods that are available in the online world. In order to get real user experience, I ended up creating online accounts with several banks and financial institutions . I got to try out various methods including OTP, biometrics, device fingerprinting etc. However, I found that every bank had something in common. They had all implemented some form of KBA (knowledge based authentication), also referred by some as challenge-response or Q&A. It was either implemented as a secondary authentication method i.e. give me your password and then tell me the color of your eye. Or as a means for back-end authentication (either to recover the password or to register my computer).

So….when we first launched SignOn.com with Infocard authentication (and account recovery via email) , we received some feedback that the site is only as secure as the weakest link. Hence in the follow up release, we upgraded the account recovery to use KBA.

We spent some time coming up with the right questions for the users. Should we ask

  • What’s the name of your first spouse? OR
  • What’s the name of your first love?

The difference is that the answer to the first question is a “fact”. And the answer to the second question is an “opinion”.

To illustrate this further, here are some “fact” based questions:

  • What is your mother’s maiden name?
  • What is the color of your eye?
  • What was the make of your first car?
  • In what city were you born?

And here are some “opinion” based questions:

  • Who is your favorite sports team?
  • Who was your childhood hero?
  • What is the name of your best friend?
  • Who is your favorite movie star?

It’s a lot easier for others to find facts about you. And hence the ‘fact’ based questions are a lot less secure than the “opinion” based questions. However, based on my experience and others that I have talked to- it seems when presented with a choice, most of the users choose the ‘fact’ based questions…simply because they are easier to answer and don’t make you think.

convenience

To me, it seems like another area where security and convenience are at odds. I’ll be interested to hear if others have an “opinion” on this.

SpreadOpenID Launched

To give OpenID a kick start in 2008, Thomas Huhn and Carsten Poetter have launched SpreadOpenID. The goal of the site is to assist users in picking up an OpenID provider (given that there are quite a few) and getting a bit educated in the process. Congratulations on another great community effort.

My only feedback will be to somehow integrate this with OpenIDDirectory. Currently SpreadOpenID lists the feature set of a few providers. And OpenIDDirectory allows the users to vote a provider up or down. It will be nice to consolidate the two lists.

IIW2007B – My Takeaways

I’m back from IIW2007B. As always, there was a lot of energy, lot of discussions and lot of networking.
OpenID 2.0 was announced. OAuth 1.0 was announced. There were quite a few sessions on VRM. Some good discussions on reputation around OPs, RPs and users. I also got to spend one afternoon in the OSIS session where the discussions have moved beyond the “happy path” and the vendors (me included) are ready to tackle the edge use cases around Information Cards.

One of my favorite session was “What’s next for OpenID” led by Dick (Sxip) and Josh(JanRain). Now the OpenID 2.0 is wrapped and shipped, what needs to be improved for the next version(s).

Here are my notes from the session: (if you were there and I have missed or misinterpreted anything, feel free to correct).

  • Single Sign Out: OpenID allows the user to have a single identifier and get a single sign on experience across multiple applications. RP applications have different session time outs and this results in an inconsistent user experience as well as security issues. The protocol should have a way to “single log out” from all the applications.
  • Phishing resistant: OpenID has a couple of security issues, phishing being the primary one. It’s very easy for a rogue RP to redirect the user to a fake IdP and steal his/her credentials. There are a few solutions e.g. firefox plugins but it will be nice to have support for it in the protocol (or at least a best practice or recommendation for providers).
  • User experience less geeky: It may seem easy to some but typing (and remembering) whatever.myfavoriteopenidprovider.com is confusing and cumbersome for non-geeky, non-identity people.
  • Performance: Too many redirects. Direct authentication to the site using username/password results in a faster experience.
  • Cardspace – OpenID integration: CardSpace and OpenID are both addressing one fundamental problem – “Reducing Password overload”. Both have their strengths and weaknesses. It will be nice to have some convergence.
  • Identifier control: This is the identifier recycling issue plus some additional concerns. e.g I have my own domain name that I have redirected to my favorite OpenID provider. RPs may attach my identifier (i.e. my domain name) to my account at the RP. If I forget to renew my domain name (or I get hit by the bus), someone else may acquire my domain name and thus get access to my account at the RP.
  • Non-browser authentication – Ability to authenticate to non-browser applications.
  • Consolidation / Synonyms – If a user has multiple OpenIDs, then the RPs should allow attaching multiple OpenIDs to the same account.
  • Identifier management – The users may already have an OpenID identifier from AOL,Yahoo etc. but don’t know how to use it at the RP. This is a usability issue for the RP sites.

In the past, if you raise issues like “phishing”, the standard response was “this is a problem with SAML too” OR “this is out of scope for OpenID”. It was refreshing to be able to openly discuss the weaknesses and figure out ways to improve the protocol. I consider this a sign of maturity.

Three days more / Interop Zen

Suiwo, the disciple of Hakuin, was a good teacher. During one summer seclusion period, a pupil came to him from a southern island of Japan.

Suiwo gave him the problem: “Hear the sound of one hand.”The pupil remained three years but could not pass the test. One night he came in tears to Suiwo. “I must return south in shame and embarrassment,” he said, “for I cannot solve my problem.”

“Wait one week more and meditate constantly,” advised Suiwo.Still no enlightenment came to the pupil. “Try for another week,” said Suiwo. The pupil obeyed, but in vain.

“Still another week.” Yet this was of no avail.In despair the student begged to be released, but Suiwo requested another meditation of five days. They were without result. Then he said: “Meditate for three days longer, then if you fail to attain enlightenment, you had better kill yourself.”

On the second day the pupil was enlightened.

It’s good to have deadlines and interops every now and then.

Re:Reconciliation

Paul lists some Reconciliation  ideas in a recent blog entry. His post raises two issues:

  • Why does SignOn.com require the profile information in the card (even though the site has the information already)?
  • As an RP/SP, how do you deal with the user’s profile information?  Do you keep a copy? Do you ask it every time from the IdP? How do you handle claims freshness, expiry, etc?

The second one is a bigger question since it is dependent on several other things like RP business model, IDP/RP relationship etc. We need to have a F2F session to drill down on that one.

Let me attempt to answer the first one. We did spend a significant amount of time on this particular subject before coming up with what we have. It’s not perfect but it’s the best among the choices that we had.
If you (or anyone else) have a better idea to address this, please share and beers are on us next time we meet.

At SignOn.com, we had the following requirements:

  • we wanted our users to have the option of registering multiple cards (one for work, one for home etc).
  • Once the user has registered a card with SignOn.com, he/she should be able to go to the My Account page, look at the registered cards and quickly determine if a card has already been registered.

We prototyped 3 ways to address the requirements:

  • Display PPID – This option will require the card to only have a PPID (every personal card has one). And then under My Account, the user will see a list of PPIDs. In case you haven’t seen, this is how a PPID looks alike – 7n+eg3TBKNP1ylqPrksKmS0xB8uyhTVX36XcdiEDdk0=.  Needless to say, it isn’t exactly user friendly. Additionally, the PPID is created on a per site basis. In order to see the PPID, the user has to submit the card to the site. Therefore if the user likes to verify if a card has already been registered, he/she has to invoke the card selector, select a card and submit it. 3 clicks only to find out if the card has already been registered.
  • Card name / label – At the time of registration, allow the user to enter a card name or a label to identify the card. The CardSpace client has a card name associated with the card. However, when a user submits the card to the site, the name does not get transmitted to the site. Therefore the name/label at the site has to be a completely manual process and will have no link with the card name in the identity selector. (We could have used nickname as the card name, but it meant overloading the claim and we didn’t want to go that route).
  • Additional claims – Ask for more claims from the user (e.g. firstname, lastname, email address) and hopefully that will give the user enough indication if a card has already been registered. It still has the problem since the user might have multiple cards with the identical claim values.

We had an independent team perform a usability test on the 3 prototypes and they preferred option 3.  Personally, I would have preferred a way for the cardspace client to send the card name to the site and then pick option 2.

Net/Net as it stands today, we aren’t using the claims in the card to map it to the user’s profile data but merely as a visual clue for the users to look at their registered cards. If you have a better idea, I’m all ears.

SignOn.com Upgrade

We have added a couple of new features to SignOn.com. Your comments/suggestions are always welcome.

  • Support for SeatBelt
    SeatBelt is a Firefox plug-in by Verisign. It assists you while logging in to OpenID RP sites. You can find more information as well as download it from here:
    In a nutshell, it allows for the following:
    - One click to get to your IdP.
    - Status indicator if you are currently logged in to your IdP.
    - Convenient way to switch OpenID providers.
    - OpenID form-fill at the OpenID RP. If you are not logged in to your IdP, it challenges for authentication. If you are already have a browser session with your IdP (e.g. SignOn.com), it does form-fill at the RP.
  • Support for OpenID Provider Authentication Policy Extension (PAPE)
    PAPE is an OpenID extension that allows the RP to specify an authentication policy. It allows the IdP to inform the RP what authentication policy was used. It’s similar to the concept of AuthnContext in SAML. Since SignOn.com support multiple means of authentication (username/password and information cards), we update the OpenID response accordingly. Currently, there aren’t many RPs today that leverage this feature. That should be changing soon. You can find more information on PAPE here.
  • About Me
    This is one of the most requested feature by our users. The ‘About’ page allows you to share your information with the world. Consider it the digital equivalent of your business card. Once logged in to SignOn.com, you can fill in your information in the ‘My Profile’ section and click on the publish_true.gif  image to publish it and share it with the world. As an example, checkout http://ashish.signon.com .

Online Payments using Information Cards

Here are the slides from Sid’s DIDW presentation.

To try out the demo, go to DIDWDemo, get yourself a card and ‘Go shopping at Starbuzz Coffee’. You need to have IE7 and MS CardSpace to checkout the demo (the bank site doesn’t support Firefox).

From the outside, it looks like any other ‘Managed Information cards’ demo. But behind the scene, the merchant site and the issuer are integrated with ACI’s Access Control Server and Payment engine. In the coming weeks, we’ll allow the user to monitor the transaction details between the merchant and the issuer.

For more information on the concept, checkout Sid’s post here .

acipingdemo2.jpg

Image | WordPress Themes