|
Forgive me if I missed some previous
discussion answering my question. What is
the need to invent AuthZ at all? Why can't we let the "application" simply
rely on a layer such as JAAS (even if not perfect) and leave the AuthZ policy
modeling and decision to the JAAS provider. This way will allow different situations to be handled differently with a
level of abstraction and transparency at the Higgins framework
level.
So for instance, if user names change or user
deleted, it is up to the underlying provisioning and synchronization processes
involved. Application will assume the user identifier established in its
request (session) context and the corresponding references in the AuthZ policies
(in the policy store) are in sync.
----- Original Message -----
Sent: Wednesday, March 26, 2008 9:47
AM
Subject: Re: [higgins-dev] AuthZ
observation
Right
now, we're identifying needs and use cases. We agreed that our next task
would be to invent some way for an application to ask questions like "does
UserX have OperationY access to ResourceZ?" Yes, it may be a little odd
to invent the way to ask the question before deciding who is authoritative for
the policy.
>>> Prateek Mishra
<prateek.mishra@xxxxxxxxxx> 03/26/08 10:17 AM >>>
Who is
publishing the policy - "UserX has OperationY access to
ResourceZ"? Is it
the owner or custodian of the resource? Or is it
someone else?
And
how is the UserX "known" to the policy publishing entity? Might this
take
the form of "Authority Y states this is Joe". If Authority Y is
a
well-behaved auth engine, shouldnt it guarantee that names arent
re-used?
I guess identifying the different players here would help me
understand
the problem better
- prateek
>
> Duane made
this observation:
>
>
> * If AuthZ allows us to express
something like "UserX has OperationY
> access to ResourceZ", then we
must disallow renames of entities.
>
> ** Otherwise, if the
"UserX" or "ResourceZ" entities are renamed, we
> have a problem where
the AuthZ is disconnected.
>
> *** Worse, if UserX is removed, and
another one added, they will be
> unwittingly granted
access.
>
>
> This is especially true if we allow the AuthZ
to be managed by a
> layered CP, because the underlying Context might be
directly accessed
> to perform a rename, leaving the upper "authZ CP"
unaware of the fact
> that it has a disconnected authZ
statement.
>
>
------------------------------------------------------------------------
>
>
_______________________________________________
> higgins-dev mailing
list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
_______________________________________________
higgins-dev
mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing
list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
| 