[OpenID] The "keep context" problem

[Peter Williams]

The equivalent SAML spec REQUIRES a containing protocol to protect the
integrity of values such as return_to - being "relying party state" that
is an data asset worth interfering with when attacking the security
properties of the webSSO protocol run.

So, the question was..does OpenID protocol have the required state
management feature/requirements? - not: shall each RP programmer do its
own funky thing when improving the standard OpenID in the area of
webSSO-related state management?

If we think like a compliance lab: either they test an OpenID provider
via its API using the standard test for such as RP state management...
or they don't.

The RP implementation, using the normal factory/provider pattern, should
surely be able to assume standard, compliance-tested security of RP
state management (for webSSO purposes) regardless of which provider is
installed.

If one assumes that SSL is the integrity mechanism protecting the
integrity of return_to state and that https assures the OP Provider's
trustworthiness in that same area, once again we are making OpenID
DEPENDENT on a priori trust management properties of https (which
probably means certs and thus PKI-centric trust practices, in practice).

https used programatically (versus in a browser) tends to be done very
poorly. Folks just skip the hard bits of implementing an https client
using an SSL provider.




-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Thursday, June 14, 2007 11:28 PM
To: general at openid.net
Subject: Re: [OpenID] The "keep context" problem

=drummond.reed wrote:
> Has anyone else had this same experience?
> 
> 1) You follow a link or navigate to a page on an OpenID-enabled wiki
page
> that you realize you need to edit.
> 
> 2) You click the Edit button/tab/link and it presents an OpenID login
box
> saying you have to login first.
> 
> 3) You enter your OpenID and successfully authenticate via your OP.
> 
> 4) The site returns a vanilla "login successful" page with a big
smiley face
> saying welcome to the site!
> 
> But you're not wearing a big smiley face because your original context
is
> completely lost. The "convenience" of being able to use an OpenID
login
> means you now have to go back to the home page of the site and
navigate back
> to the page you want to edit -- which you may not even know if you
followed
> an external link to that page!
> 

This is not a problem inherent to OpenID. The Mediawiki plugin's RP code

is flawed. There are a number of ways around this which vary in
complexity:
  * Just add a query field to the return_to URL that contains the URL to

send the user back to once authentication is completed. This is how most

sites implement traditional "interrupting" login forms anyway.
  * Use your web framework's concept of "session storage" to remember 
where the user was before you did the redirect dance. This is kinda lame

because it gets confused if the user does another auth-requiring action 
in a different tab or window.
  * Go Jyte-style and try to first do the authentication using an 
AJAX-type request and see if you can succeed without taking the user 
anywhere. If that fails, only then do you ask them to log in and you do 
one of the other options above. This only works if they've logged in to 
your site before and they've told their OP "Yes; every time"

The latter is, in my opinion, the best from a user experience 
perspective, but I would guess is near-impossible to do in situations 
like the MediaWiki plugin when you're trying to shoe-horn OpenID support

into an app that was traditionally all about local user accounts. It's 
easy for Jyte because they are OpenID through and through. I'd be 
satisfied if the MediaWiki plugin would just do the first of these.


_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general