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.

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.

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.

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.


>> And then we get to the contradiction that:
>>
>> 1. The service, which has created the resource A (on user request),
>> now requests a policy to be made for that resource A.
>> 2. The policy service, in response, asks the service to access the
>> said resource A -- before any policy has been created.
>> 3. The service, to which the origin of the request is irrelevant (it
>> doesn't care whether it's an "ordinary" client or the policy service),
>> now asks OpenSSO for a policy check -- the policy, which has actually
>> been requested in step 1 and has not yet been created...
>
> Yes, and
> 4. OpenSSO would deny access, thus service returns probably 401
> (Unauthorized).
> More detailed, in 2. no token/credentials are presented, while in 3., the
> guest user would be used.
> This could also lead to grant access in 4, but that's not important.
> The only important aspect would be that AA service receives a code different
> from 404 (Not found) in step 4.
>
>> It will probably work, but it's kind of "unclean" solution to me, and
>> I'm afraid there might be pitfalls in it. I have to say, however, that
>> I don't have an alternative solution at the moment.
>
> This approach seems to me quite common. It is a "callback" solution to check
> for presence of a resource.
> The same happens when you e.g. join a mailing list (double opt-in) to verify
> your identity.

Hmmm, yes that makes sense... Sort of checking "hey, have you really
published that resource you want me to register a policy for"... But
we probably still need to be careful, as there is still a potential
recursion here -- maybe not in that scenario, but in some more complex
one.

>> One more thing, too: we were discussing when exactly will the resource
>> be published: right away or only after the policy service confirms
>> that the relevant policy has been created... However, because the
>> default policy of OpenSSO is "deny", I believe the decision was made
>> to publish the resource straight away; is that correct?
>
> Yes, I would go for that.

If nobody objects, let's assume this point to be finally decided upon:
when a resource is created, it's published immediately, and only after
that a request to create a policy is being made to the policy service,
OK? We still have to decide how exactly we handle the situation when
the policy creation fails -- I have to check again the discussions
from last week.

Cheers,
Luchesar


>
>> Otherwise,
>> obviously, when the policy service checks the resource, it still won't
>> be there, waiting for the policy to be created.
>
> Sure, I implied that in my previous explanations. ;-)
>
> Greetings
> Andreas
>