Re: [protocol] Authentication

There is also the OAuth 2 client credentials grant where the access token
is returned directly.

Or the new RFC 7523 where you could probably return the access token
directly from a JWT assertion token request.

I think it's pretty ambitious to be specifying authorization, generally.
There are so many ways to handle it and it's not annotation specific.

On Mon, Jun 8, 2015, 08:26 Susanna Netseven <martinelli@netseven.it> wrote:

> Hi Robert,
> I would like to share our solution regarding Oauth2 authentication.
> Basically we have an architect which is based on two major components: a
> Client,  that is a sort of chromium extension that user load once landed in
> a html page he wants to annotate (Pundit client) ,  and a server that
> provide a RESTFul API facade  and a storage layer (Pundit server).
> Here you can see a draw for the different layers.
> http://old.thepund.it/documentation/pundit-server-api/
>
> We have recently introduced, in order to replace the old OpenID
> Authentication the Oauth2 authentication.
>
> We've choose to use Symfony as Oauth2 provider, because it comes with a
> robust backend in order to manage users (creation, modification editing),
> moreover by adding a particular bundle it provides Oauth2 authentication:
> https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
> Symfony Oauth bundle can be also integrated with Google and Facebook
> authentication.
>
> In order to maintain Symfony DB aligned with users into RDF repository we
> have implemented a mechanism that permits update for all user's
> informations.
>
> Here you can see 2 different workflows.
> This first one describes a login with authentication for a not existent
> user (first time login)
>
> https://docs.google.com/drawings/d/1J6z2HFrqZuV1n6bMS2EVNOa6XDVJdIzLTZWoq2SEW_0/pub?w=960&h=720
>
> This second one instead describes login process for already created user:
>
> https://docs.google.com/drawings/d/1MeffLYUY8JEMeYPbPozvIIHc2pk09hr7THIr_YCfNoE/pub?w=960&h=720
>
> Last but not least, Pundit server is Tomcat servlet and authentication
> method could be selected at starting time (by editing web.xml file).
> There are mainly 2 kind of authentication now, Basic or Oauth both of them
> provided by the special class.
>
> Cheers
> Susanna
>
> On Fri, Jun 5, 2015 at 9:20 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> Dear all,
>>
>> On a recent call we discussed authentication with respect to the protocol
>> draft.
>>
>> Following on from the conclusions of that call, we (Stanford) tried to
>> implement OAuth2 directly as the framework for auth over top of our
>> annotation service... and failed.
>>
>> The major issue we ran into was where, in a straight client/server
>> interaction, does the OAuth redirect go back to in order for the client to
>> obtain the authorization code.  We started down the line of changing it to
>> simply return the code directly to a client, but it became a significant
>> implementation challenge that was much more easily solved in other ways.
>>
>> So we changed course to implement a very similar workflow that allows the
>> modular inclusion of any authentication system (so far demonstrated with
>> basic auth and various OAuth2 providers) without the client needing to know
>> any of the user's information.   Instead it can just pass it through. That
>> workflow was designed for access to protected image content, but works the
>> same way for access to annotations:
>>       http://image-auth.iiif.io/api/image/2.1/authentication.html
>>
>> (You may recognize one (or more) of the editors)
>>
>> I believe that the spirit fits within the discussion from the call, but
>> would appreciate any feedback!
>>
>> And, for discussion, should the protocol document discuss
>> authentication?  Any real world implementation is going to need to have
>> authenticated and authorized users, so I'm wary of either
>> non-interoperability or lack of implementations if we don't.
>>
>> Rob
>>
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
>>
>
>

Received on Monday, 8 June 2015 18:22:46 UTC