Re: IDP delegation protocol ?

Hi Olivier,

On 07/10/2012 07:01 PM, Olivier Berger wrote:
> Hi.
>
> I've made a few tests using Melvin's libAuthentication PHP library
> (actually with our fork at [0]) and I'm wondering if there ain't some
> shortcomings with the current "IDP" delegation protocol which is
> implemented by foafssl.org/srv/idp and auth.my-profile.eu/auth/index.php
> (using the authreqissuer, signed response, etc.)
>
> First is this specified somewhere ?
There's no official specification AFAIK, but maybe we should write one.

On the other hand I'm working on a "Lite" version of libAuthentication, 
which I plan to release tomorrow. It retains only the delegated 
authentication aspects of the previous version, so I think it suits the 
current situation very well.

>
>
> Then, the problem I found with the current "protocol" implementation :
>
> Melvin's implementation chooses a default IdP (foafssl.org) and declares
> its cert statically in the code, so if you don't use that one, for
> instance with a :
>   https://auth.my-profile.eu/auth/index.php?authreqissuer=http://myapp.com/index.php
> then it's difficult to instruct $auth->isAuthenticated() that another
> service's cert must be used to check the sig.
>
> It seems that Andrei implemented a referer= arg passed with the
> response, which can help find another cert in the store, so
> auth.my-profile.eu/auth will respond with something like :
> http://myapp.com/index.php?webid=...&ts=...&sig=...&referer=https://auth.my-profile.eu
Indeed I had to add the 'referer=' param, as my server did not set the 
referer when performing the redirect, and also because the referer value 
didn't count much at the begining (since foafssl.org was the only IdP).

> But that doesn't warrant I should trust this parameter, unless it is
> signed by the IdP (which isn't the case at the moment).
Yes, you're right. Maybe this can be included in the proposed 'spec'. 
I'm not exactly sure how many applications use foafssl.org or 
auth.my-profile.eu at this point, so we shouldn't hurry to change the 
current way it works.

> So... my understanding is that there should be some kind of a "from"
> origin of the IdP's response, passed back in the signed part of the
> response, (maybe called referer, but I fear some confusion with the HTTP
> server referer).
>
> So the lib could first get that from, find the corresponding cert in its
> store of trusted IdP, and check the signature with that cert's pubkey,
> wich would then validate that we can trust this IdP and declare
> delegated authenticate succesful.
>
> I thinks OAuth has already covered much of these aspects (in the 2 legs
> variant IIRC), so I'm really wondering if that's worth implementing such
> a novel protocol instead of relying on Oauth...
AFAKI, the current protocol is more a hack than an actual protocol. I'm 
not sure, however, that using OAuth will help much, other than adding 
another layer of complexity. Maybe we can try to combine a possible 
protocol proposal with the Authorization Delegation [1] topic?

> Any comments, opinions ?
>
> Thanks in advance.
>
> [0] https://github.com/WebIDauth/libAuthentication
>
> P.S.: FYI, I'm working on trying to implement WebID auth for
> FusionForge... hence looking for PHP libs, and testing ;)
>

Andrei

[1] http://www.w3.org/wiki/WebID/Delegation#Use_cases

Received on Tuesday, 10 July 2012 22:07:31 UTC