Identity Meta-System SSO

In his entry “OpenID bootstrap to ID-WSF”, Paul describes the results of a very interesting IOS session in Brussels. As he outlines, the bootstrapping possibilities are pretty straight forward. An interesting point of the second option is that the RP would need to know how to obtain the appropriate security token in order to invoke the Discovery Service (DS) as defined in the publicly available DS-EPR. In the OpenID case, the OpenID “assertion” would need to be exchanged for the appropriate token used to invoke the Liberty DS service (in most cases a SAMLv2 assertion).

It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...

1. User visits RP-A which only supports SAMLv2
2. User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
3. RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
4. User authentications and the IdP sets authentication state cookies in the user's browser
5. The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
6. User is not authenticated at RP-A
7. User now loads RP-B which only supports OpenID
8. User's browser has a stored cookie identifying the last OpenID used with RP-B
9. RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
10. The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
11. The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
12. If the federation exists, then the IdP can return the OpenID authenticated response

This would allow seamless SSO between different front-channel identity systems, though it is dependent on “identifier federation” at the IdP. However, if the IdP's are not the same, it should still be possible, but more complicated, as the user's identity would need to be federated across the involved IdP's.

Tags: Identity, OpenID, SAML, SSO, metasystem

A knife... a real knife... magnetized!

To anyone familiar with the Tray Table blog, it is certainly no surprise that a certain unnamed individual was once again traveling in 1st class. However, just a metal knife in business class? Boring... Mine were magnetized!


Not sure what caused the magnetism. Feel free to post theories in the comments.

AOL releases OpenAuth

As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.

There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).

The basics for web developers are...

• Provisioning

1. Get a provider id (called a developer key)


• At runtime

2. Request an authentication token

• requires both authentication and consent from the user before returning the authentication token

3. Invoke AOL identity based service

• requires user consent (can be remembered) before returning requested data

Much more detailed documentation is available at http://dev.aol.com/openauth.

Full disclosure: I work for AOL but not directly as part of the Authentication team.

Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF

Spring Blossoms

When it is a Phish

So after my experience with getting a valid notification from eBay (thanks again eBay), I received the following email supposedly from PayPal.


This one was immediately suspicious. For one, the href for the URL was a dotted quad (85.234.150.131). Two, the “whois” entry wasn't in anyway associated with PayPal.

OrgName: RIPE Network Coordination Centre
OrgID: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL

ReferralServer: whois://whois.ripe.net:43

...

% Information related to '85.234.128.0/19AS29550'

route: 85.234.128.0/19
descr: PH-Network Europe, operated by Euroconnex Networks LLP
origin: AS29550
remarks: *********************************************
remarks: For Peering and more info: www.euroconnex.net
remarks: *********************************************
mnt-by: POUNDHOST
source: RIPE # Filtered

And three, the email was not sent to the email address associated with my PayPal account.

The rest of the email looked pretty legit however, and after my experience of the previous week... I had to look closely to file this in the “scam” folder. I have to wonder if this email is in any way related to the credit card fraud of the previous week.

Tags: Phishing, eBay, PayPal

Happy Easter!

"He is risen!" ... "He is risen indeed!" <><

When it's not a Phish

On March 29 I received the following email from eBay (I left out the “boiler plate” text regarding how to protect yourself from fraud).


My first thought was another clever phishing scheme as I don't have a credit card on file with eBay other than my PayPal account. So I looked through the email for links or other telltale signs that would indicate a phish. I couldn't find anything so I went to eBay and logged in (not via the email of course). There were the same two emails in my eBay “inbox”. I checked my account at eBay and everything looked fine. I then checked my associated PayPal account and there were no purchases via that account. Next step was to check my credit card balance.

Hmm... there on my activity statement was a charge from snapfish.com. The immediate red lights started whirring as I don't have a snapfish account. So off to the hassle of calling the credit card company, snapfish.com etc. The result of these calls was to watch my credit card account (the first fraudulent charge was $1.33). The following day there were two more fraudulent charges from snapfish.com ($2.90 and $41.65 respectively). Now back to the phone to remove these charges from my bill, cancel the credit card and get a new card issued with a new number. The biggest hassle being finding all the companies that have re-occuring charges against that card. Yet another thing to keep track of in the event this happens again.

A BIG thank you to eBay for sending this email and helping me catch the fraud right from the start. Needless to say this experience has not been pleasant, including monitoring of online credit card statements while on vacation this week. This is my first experience with this sort of fraud and I don't hope to repeat the process anytime soon:)

Tags: Fraud, Credit Card, Phishing