We had some discussion with Nina and Vedrin and another issue came
out: how will the client know the address of the authentication
(OpenSSO) service? Of course, it would be easiest to hard-code this
information in the clients, but obviously this is also rather
inflexible. And for those users who would bypass any client
applications and communicate with the services directly through the
API the question is even more important.

Nina came with what looks like a nice solution. When the first request
is made -- without any credentials (i.e. a token) -- the service
returns HTTP code 401 Unauthorized; and here it could send along the
address(es) of the AA server(s). So, the complete process would be:

1) The client sends unauthenticated request to the OT service.
2) The OT service responds "401 Unauthorized: Contact x.y.z for authentication".
3) The client sends authentication request to x.y.z (that's the OpenSSO server).
4) The client receives the token upon successful authentication.
5) The client sends the request to the OT service, this time
accompanied by the token.
6) The OT service checks token validity and performs authorization.

Of course, unless the AA servers constantly change for some reason, it
might make sense to have either the address cached by the client or a
hard-coded default address. However, to avoid confusion, it would be
nice then if the client ALSO sends along with the token information
about the AA server it obtained the token from. In this case, the OT
service will compare the "token-issuer" with what it knows to be the
correct AA service, and if there's a mismatch will inform the user of
the correct address. So, again:

1) The client sends a request accompanied by a token and the address
of the OpenSSO server that issued it.
2) The OT service compares the address of the issuer with the address
of the AA service it knows (and it will use to validate the token and
perform authorization later).
3) If there's mismatch, the process will continue with point (2) from
the previous list (OT service responds 401 Unauthorized: Contact x.y.z
for authentication); otherwise point (6) will follow (validation and
authorization).

This should also help when tests are performed and with
troubleshooting problems in general (e.g. when different OT services
have for some reason configured different AA service addresses).

Cheers,
Luchesar


On Thu, Jun 17, 2010 at 19:23, Andreas Maunz <andreas at maunz.de> wrote:
> Since "client" is to be understood as "client software" (not human), I think
> we could give the client the obligation to log out.
> In view of increasing complexity, I also tend to put the burden of obtaining
> a token (which is actually not so much) on the client.
> That way, existing services would have to add a field "subjectid" (which I
> propose to name the token field) and hook calling routines to the OpenSSO
> service into the workflow at the appropriate places (before the actual
> service calls).
>
> Regards
> Andreas
>
> Luchesar V. ILIEV wrote on 06/17/2010 06:07 PM:
>>
>> Let's decide who will handle the authentication process:
>>
>> 1. The service.
>> OR
>> 2. The client/user.
>>
>> (1) means that an OT service will expect only a valid OpenSSO token
>> with each request. It will be up to the user to acquire such token:
>> whether by directly communication with the OpenSSO server or via some
>> client application.
>>
>> (2) means that an OT service will expect username and password
>> provided with each request. It will then try to get a valid token from
>> OpenSSO, and if that fails, will have to report back to the user.
>> Obviously, this relieves the client applications from the burden of
>> authentication, but at the expense of increased service complexity.
>> Furthermore, the services still have to be able to parse requests
>> accompanied by a token (as opposed to username/password), because
>> that's how cascading requests (from one service to another on behalf
>> of a user) work.
>>
>> Please keep in mind as well that whoever does the authentication must
>> also handle log-out.
>>
>> Cheers,
>> Luchesar
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>
> --
> http://www.maunz.de
>
>            According to my calculations the problem doesn't exist.
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>