[OpenID] Multiple Domains and State

[Trey Long]

I don't know openId as well as I should either but your insights are  
very informative.

On Apr 23, 2008, at 11:04 PM, Nate Klingenstein wrote:

> Trey,
>
> Bear in mind I'm relatively new to this spec, and going pretty deep  
> into it to answer you, so I might make a mistake.
>
>> In the example auth.com would be a trusted resource and if the user  
>> had no session would ask about his identity (openid.com/trey).  
>> Auth.com would confirm the authentication in the standard way and  
>> communicate with the original domain that this users identity  
>> "openid.com/trey" has been verified.
>
> "Communicate with the original domain" is the tricky step.  How?  It  
> can't forward the claimed identity because the claim was issued for  
> auth.com's eyes only.  It can't claim the identity openid.com/trey  
> because it doesn't control the URL.  It also can't spoof the  
> response because it's signed.
>
> It could spoof a request on behalf of the original domain to  
> openid.com, getting the right return URL, but then why route the  
> flows through auth.com in the first place, since it's not  
> maintaining state?  It becomes a lookup service for OP's exactly  
> like Shibboleth's WAYF; useful in some situations, but probably not  
> what you're looking for.
>
> This is a generic feature of security protocols that use bearer  
> tokens, I'm afraid.  It's a deliberate measure to prevent a  
> legitimate recipient of an assertion from replaying it at another RP.
>
> You're trying to circumvent this security measure in a legitimate  
> way, but doing so requires either:
>
> A) extra trust between auth.com and the end domain (and, in this  
> case, a different protocol if you want to remain spec-valid); or
> B) a trust fabric between openid.com, auth.com, and the end domain  
> so that you can make use of the Realms feature in 2.0 Auth(section  
> 9.2).

I apologize but the language of the spec (9.2) from a standpoint of  
speculation is hard to follow. I can't quite grasp how realms would  
facilitate the task at hand. Also I would assume auth.com is a trusted  
resource of some kind which is given permission to act as a proxy from  
which openId authentication occurs from.

>
>
>> I would expect auth.com to act as a proxy for the entire  
>> authorization chain and would be the return URL. This would allow  
>> auth.com to establish state and then return the user to the  
>> original domain. The original domain would then do the requisite  
>> communication directly with auth.com to confirm.
>
> Depending on how you do it, various things would fail, again by  
> design.
>
> A)  If you pass along the entire assertion unmodified, the original  
> domain MUST dump it because the return URL doesn't match (11.1);
> B)  If you try to send openid.com/trey from auth.com, the signature  
> won't be verifiable, because you don't control the domain it  
> resolves to; or
> C)  If you send auth.com/trey, the original domain will be receiving  
> the wrong identifier.
>
>> If you think it's a resource that would help with this problem send  
>> it on. Ideally it would be great if I could either fit this within  
>> openId or extend openId to support trusted chains or proxies. If  
>> not, home brew will do.
>
> Probably, but it's pretty dense.  I'd just homebrew this part, or  
> hardcode some overrides into your validation code if you really want  
> to use OpenID.
>
> Peter's suggestion to use attributes would work too.  That's what we  
> did in Shibboleth.  There's just too much riding on successful  
> identifier validation in OpenID, so deliberately breaking that's  
> kinda dangerous.
>
>> It does seem though that single sign on for multiple domains is  
>> desired elsewhere. I would like to hear other thoughts on the topic  
>> as well, outside of my original idea that may apply. Perhaps I am  
>> being stupid about the solution, it certainly wouldn't be the first  
>> time.
>
> It's definitely not the first time I've heard the use case.  The  
> trouble is that there's no good, lightweight solution. ;D
>
> Take care,
> Nate.

Thanks for the ideas, if auth.com is just a home brew session state  
server that will be fine. This problem seems so close to openId though  
I really wanted to see a solution that involved it. It seems a logical  
next step anyway.

Trey