Re: [protocol] Authentication

To be clear, I don't think we should specify *authorization* at all, nor
the exact method of *authentication*, but have a standardised workflow
which would allow clients to pass the users credentials to the service
without necessarily knowing what those credentials are or even how they
were obtained, and standardised error responses so the client knows that
the user is not authorized to perform the action attempted.  It needs to
work across arbitrary domains, and via XMLHttpRequest. It should work for
browser and non browser based client applications, for human and software
agents.

What I think should be out of scope:
* Authorization rules and scope.  e.g. we will not require that users have
their own explicit identity, the concept of user groups, the sorts of
actions that they can perform, etc.  That can all be system specific, so
long as the client knows how to discover and send the necessary user
information to the service over the protocol.
* The specific authentication sub-system.  It could be basic auth[1],
shibboleth[2], oauth[3], openid connect[4], webauth[5], CAS[6], or
something totally home grown.


We're never going to get agreement that everyone who wants to run an
annotation service will get their organization to implement OAuth2 (or any
other specified system). The business logic for authorization is also
impossible to specify and will doubtless rely on very different attributes
of the user in different situations.  Instead we need a pattern that allows
different authentication systems to be seamlessly plugged in without
requiring the client to know the details, just pass them through.


Some concrete use cases to consider:

1. As an annotator, I want to use my own client to annotate the web
annotation data model and store those annotations in the webplatform.org
service so that they are rendered to other users.  That service requires
authentication to use. At the same time, I also want to store that
annotation in my own service, which uses a different
authentication/authorization system.
2. As a web application developer [e.g. ruby on rails], I want to allow my
already authenticated users to be able to annotate my resources and store
those annotations in my service via the protocol.  The user should not have
to log in again, as my application has already taken care of that, and
instead I want to pass those credentials directly to the annotation service.

3. As an annotator, I want to know that the web application I'm interacting
with is not spoofing an external authentication system (such as facebook or
google) in order to steal my credentials.

3b.  As an annotator using a web application that is pulling in resources
from multiple sites for comparison, I do not want to lose my application's
state to have to authenticate to a new service.

4. As an annotation system manager, I want to use an authentication system
that allows non-human agents to manage annotations, such as batch import of
annotations from external annotations services (either standards based or
proprietary).  That non-human agent should require configuring a completely
different authorization system than my human users.


I agree it's not annotation specific. I disagree that client credentials
are appropriate, as that is identification of the client itself, not the
user, such that it can (for example) update its client secret.
I'll have a look at 7523, thanks for the reference :) but I'm not sure that
it helps in the non-browser, non-human user case.


Rob


[1] http://tools.ietf.org/html/rfc2617
[2] https://en.wikipedia.org/wiki/Shibboleth_(Internet2)
[3] http://oauth.net/2/
[4] http://openid.net/specs/openid-connect-core-1_0.html
[5]
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/WebAuth/WebAuth_Dep_Guide.html
[6] https://en.wikipedia.org/wiki/Central_Authentication_Service


On Wed, Jun 10, 2015 at 8:05 AM, Paolo Ciccarese <paolo.ciccarese@gmail.com>
wrote:

> I echo Randall concern.
>
> We implemented OAuth2 in Domeo/Annotopia with another mix of technologies.
> I think suggesting to use OAuth2 as authentication model is good enough.
>
> On Mon, Jun 8, 2015 at 2:22 PM, Randall Leeds <randall@bleeds.info> wrote:
>
>> 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
>>>>
>>>
>>>
>
>
> --
> Dr. Paolo Ciccarese
> ORCID: http://orcid.org/0000-0002-5156-2703
>



-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305