While setting up PayPal.com as an OpenID provider to enable third party authentication, two issues came up for session management:
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.
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.
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.
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
More than an year or so ago, PayPal announced its participation in Open Identity for Open Government initiative. We worked closely with Janrain in helping us standup a beta OpenID provider at PayPal-IdS.com that links with our proprietary Authentication service. At Innovate last year (in partnership with Janrain and Gigya), we showcased a few sites that were enabled to accept PayPal as an IdP. The beta OpenID provider gave us a chance to work closely with our partners and consumers and get a better understanding of requirements around setting up a commercial identity provider.
I’m happy to share that we now have an OpenID provider that’s hosted on PayPal infrastructure and completely integrated with PayPal.com. The new functionality will allow consumers to login to a PayPal approved OpenID relying party using their existing PayPal account.
Identity, OpenID, PayPal | Ashish Jain | 
June 7, 2011 4:27 pm | 
Comments (0) 
Subscribe