Category: OpenID

Session Timeout for PayPal OpenID

While setting up PayPal.com as an OpenID provider to enable third party authentication, two issues came up for session management:

  1. The session timeout for PayPal.com is set for a short duration. As a payment provider, it makes complete sense; However, as an Identity provider it didn’t result in an ideal experience It required user authentication for every RP access and hence added to user friction. RP’s preference was for a more seamless user experience and reduce (if not eliminate) the login challenge.
  2. The concept of login to a site using another site’s credentials is still new. Users were not sure if they were login to a RP or PayPal or both; Users didn’t always realize that by using PayPal.com to login to a RP, they were leaving an active session at PayPal.

We wanted to make sure tha the security of the user’s PayPal.com account wasn’t compromised; while providing the best experience that we can offer. We took a couple of measures:

  • Decouple the OP session from PayPal.com – If you use PayPal as an OP, it will not result in an active session at PayPal.com.
  • Allow the OP session to be longer lived – The maximum duration for OP session is 8 hours. Depending on the RP’s preference, user may not be challenged again for 8 hours.
  • Allow RPs to request session duration via max_auth_age – Depending on the sensivity of the transactions, RPs can request their session duration preference. It can be done either at on-boarding time or during the OpenID Authn request.

There are a still a few more tweaks that we are planning to make in the near future, but we believe the current solution will allow RPs to have a better control of the user experience.

SAML SSO using PayPal

One of the benefits of using Open standards is the interoperability with other product and solutions. I connected with the Intel Cloud Access 360 team during IIW. And it took less than an hour to hook up PayPal Authentication to Google Apps and Salesforce login via SAML.

The following screen cast illustrates how Intel Cloud Access 360 can
a. initiate OpenID request to PayPal
b. accept PayPal OpenID response
c. create a SAML assertion with appropriate attributes to login into Salesforce.com

PayPal OpenID Implementation details

Follow up to the previous entry for PayPal OpenID provider:

Main Links

OpenID Endpoint https://www.paypal.com/webapps/auth/server
OpenID Identifier https://www.paypal.com/webapps/auth/server
This should return the XRDS that can be used to discover the end point)
Docs Link https://www.x.com/community/ppx/xspaces/identity
Submit RP for whitelisting https://www.x.com/create-appvetting-app!input.jsp


Simple Registration (
http://openid.net/sreg/1.0)

Prefix http://openid.net/sreg/1.0
openid.sreg.required email,fullname,dob,postcode,country,language,
timezone

 

Attribute Exchange (http://openid.net/srv/ax/1.0)
Generic Attributes

first name http://axschema.org/namePerson/first
last name http://axschema.org/namePerson/last
email http://axschema.org/contact/email
full name http://schema.openid.net/contact/fullname
dob http://axschema.org/birthDate
postcode http://axschema.org/contact/postalCode/home
country
http://axschema.org/contact/country/home
language
http://axschema.org/pref/language
timezone
http://axschema.org/pref/timezone
street1
http://schema.openid.net/contact/street1
street2
http://schema.openid.net/contact/street2
city
http://axschema.org/contact/city/home
state
http://axschema.org/contact/state/home
phone http://axschema.org/contact/phone/default


PayPal Specific Attributes

Verified Account https://www.paypal.com/webapps/auth/schema/verifiedAccount
Payer ID https://www.paypal.com/webapps/auth/schema/payerID

PAPE (http://specs.openid.net/extensions/pape/1.0)

preferred_auth_policies  

 

 

http://schemas.openid.net/pape/policies/2007/06/phishing-resistant 

http://schemas.openid.net/pape/policies/2007/06/multi-factor

http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

max_auth_age [ integer value greater than or equal to zero in seconds]
preferred_auth_level_types papeauthlevel1 papeauthlevel2
auth_level.ns.papeauthlevel1 http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
auth_level.ns.papeauthlevel2 http://www.jisa.or.jp/spec/auth_level.html

OAuth vs WS-Trust/WS*

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

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.

Identity at RSA

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

See you there.

Ways to share

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

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.

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.

Trust Is The Business Word For Love

From Feld thoughts

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

Perfect.

How this relates to SAML (which requires pre-established trust) and OpenID (which requires no trust) is left as an exercise for Paul :-) .

Image | WordPress Themes