Luchesar V. ILIEV wrote on 06/28/2010 04:22 PM:
> On Mon, Jun 28, 2010 at 16:05, Andreas Maunz<andreas at maunz.de>  wrote:
>> Luchesar V. ILIEV wrote on 06/28/2010 02:47 PM:
>>>
>>> But my impression was that there will not be any "true" anonymous
>>> access, i.e. you always have to present credentials to the service --
>>> when you want to access as "guest", then you simply get a token from
>>> OpenSSO for the "anonymous" user... Probably that's what the policy
>>> service should do as well?
>>
>> My impression was rather to be able to access resources without presenting a
>> token/credentials, if the resource was publicly available. In that case, the
>> providing webservice must generate a guest token.
>> In that way, we could hide the guest user from the outside and just use it
>> internally to keep our system consistent.
>
> Hmmm, probably we should really clarify this. I'm not sure whether
> we'd like the services to "hide" the anonymous access, as this will
> complicate them (at least to an extent). The hiding could be on part
> of the user interfaces and applications -- that obviously excludes
> people who directly communicate with the API, but they should be
> knowledgeable enough, anyway.

Let's discuss this with the others. If it is not hidden, it will be 
complicated to set up the "callback" approach.

> But let me then ask something different, yet relevant to the topic
> we're discussing: will the services listen only on SSL/TLS sockets, or
> there will be "plain-text" ones as well? The reason I'm asking is
> exactly because of user credentials. It wouldn't be very wise to allow
> authentication through unsecured connections, whether via user/pass
> credentials or token. On the other hand, if we do allow requests
> without any form of authentication, then these could still be
> available as plain-text, thus reducing the load on the services.

I would advocate for maintaining the possibility to do everything 
unsecured, too. This should be no problem to configure on web servers.

> So, let me present the question again: from services' interface (that
> is, API) point of view, how is the anonymous access implemented:
> a) the party making the request MUST authenticate themselves, even if
> they ask for anonymous access (they use the well-known anonymous user
> in this case), or
> b) they authenticate only when they request access to protected
> resources or to create a new resource.
>
> In the case of (b), there's another thing to decide: how the anonymous
> access is further handled:
> 1. The service itself authenticates on behalf of the user as
> "anonymous" and gets such token from OpenSSO, or
> 2. The service entirely skips the authentication process -- that would
> require however each service to "know" which of its resources are
> available publicly in order to serve them without authentication.
> Frankly, I find (a) to be a more consistent approach, even though,
> undeniably, it's a bit less user friendly. Concerning 1 vs 2, while it
> might seem like a stupid question (why would we want to bypass OpenSSO
> and create what is, effectively, a duplicate, if simpler access list
> in the services themselves), there is some reason behind it: because
> the majority of requests would be for public data (correct me if I'm
> wrong), we could relieve the OT infrastructure a lot by virtually
> eliminating any AA steps (and also secure connections which also
> require computational resources) for them. I'm not necessarily
> suggesting we should go that way -- I'm rather suggesting to give it a
> thought before we delve too deep into a specific implementation.

The good thing about it is also that it wouldn't break API 1.1, where 
everything was without A&A.
Backward compatibility could be a benefit here.

> One final thing that seems to be not yet decided: so far we were
> discussing whether the services should always expect user credentials
> or they would allow totally unauthenticated requests as well. How
> about the user credentials themselves: as you remember, we can decide
> between:
> z) accepting only user/password -- then the service does the authentication.
> x) accepting only tokens -- then the user or requesting service does it.
> y) accepting both -- or rather, "any", as "both", literally, wouldn't
> make sense.
> Actually, it's a choice between (x) and (y), because each service (or
> most of them) must accept tokens, anyway -- because of the requests
> from other services -- and this means (z) doesn't suit us at all.

Since user/password are confidential information, we should think about 
passing only tokens whenever possible. In that sense, x) would be best.
Also, a workflow would have no chance of getting started, if the client 
software can not obtain a token (in case SSO service is down). I believe 
this is a benefit.

Regards
Andreas