You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Dobbs <er...@dobbse.net> on 2002/02/08 02:55:43 UTC
Re: Security Changes (3 of 3) - Subject, Principal, Project details
Hi All.
I decided the picture is not enough on its own.
+-------+ 1 N +---------+ 1 N +----------+
|Subject+-------+Principal+----------+Permission|
+-------+ +----+----+ +----------+
|
+-----------+---------+
| | |
+--+---+ +--+--+ +-+--+
|UserId| |Group| |Role|
+------+ +-----+ +----+
Another important point is how the Permissions of a
Subject are determined. This is also where Project
and implies() come in.
Here's some code for an example implementation. I'm
intentionally blending Turbine and JAAS concepts.
SecurityManager sm = SecurityManager.getInstance();
1. PermissionCollection pc = sm.getPermissions(Subject s,
2. Project p);
if (pc.implies(ReadPermission))
{
...
line 1:
I ask the SecurityManager for a PermissionCollection
for the Subject. Notice that I did NOT ask for the
permissions of one of the Principal's. In the
implementation I am proposing, the Permissions
of the Subject is the set of all Permissions that are
granted to *ALL* of the Subject's Principals. It's not
just for the Principal under which I was authenticated.
That way, if ManagerRolePrincipal has been granted a
set of Permissions, and if our Subject has that
Principal, then the Subject is granted those same
Permissions. Same goes for every Role or Group to
which the Subject belongs.
Having said that, there's no reason that the
implementation of getPermissions() couldn't define a
different policy for how the Subject's Permissions are
determined.
line 2: What is this Project thing about?
It is not enough to ask "What Permissions does this
Subject have?". The next natural question is
"Permissions to what?" I don't grant a Subject the
ReadFilePermission without also specifying the file or
directory in question.
In the current Turbine security model, this is handled
with the TURBINE_GROUP. The TURBINE_USER_GROUP_ROLE
maps the user's permission both by their ROLE and by
the GROUP. In my proposal, this same map is between
the Subject, the Project, and the Principals (which
happen to be contained by the Subject).
The Project part is important. Don't just dismiss it.
The reason I have called it 'Project' is because
earlier threads on this discussion have decided that to
be the preferred word. Other options have included
Module, Zone, Realm, and in JAAS this is the CodeBase.
I don't care what it's called with one exception: the
name must not conflict conceptually with the notion of
user groups (consider that a big -1 on TURBINE_GROUP).
Having explained some of those details, the interface
might be simplified to this:
class Foo implements SecurityManager
{
boolean hasPermission(Subject,Project,Permission)
...
}
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (3 of 3) - Subject, Principal, Project details
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> If I understood you correctly I think it is a good
> idea. Are you saying that the application could:
>
> 1. Determine the permissions a Subject has to an
> object. In this case the permission set is ALL the
> permissions for ALL the principals associated with the
> Subject.
>
> 2. Determine the permissions a Principal has to an
> object.
I didn't see number 2 anywhere.
> How would the Security Manager deal with two
> principals having conflicting permissions - e.g. Role
> A has grant X permission and Role B has deny X
> permission. As there is no role hierarchy across the
> principals I am not sure how one would handle this ?
>
> I was also wondering how organization is handled ?
> For example Subject M1 has role Manager. Subjects
> W11, W12, W13... have role Worker. Only Manager M1 is
> authorized to perform some actions on entities for
> which they are the owner.
I believe our current model only considers "grant" permissions.
> - viraf
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (3 of 3) - Subject, Principal, Project details
Posted by Viraf Bankwalla <vi...@yahoo.com>.
Eric,
If I understood you correctly I think it is a good
idea. Are you saying that the application could:
1. Determine the permissions a Subject has to an
object. In this case the permission set is ALL the
permissions for ALL the principals associated with the
Subject.
2. Determine the permissions a Principal has to an
object.
How would the Security Manager deal with two
principals having conflicting permissions - e.g. Role
A has grant X permission and Role B has deny X
permission. As there is no role hierachy across the
principals I am not sure how one would handle this ?
I was also wondering how organization is handled ?
For example Subject M1 has role Manager. Subjects
W11, W12, W13... have role Worker. Only Manager M1 is
authorized to perform some actions on entities for
which they are the owner.
Thanks.
- viraf
--- Eric Dobbs <er...@dobbse.net> wrote:
> Hi All.
>
> I decided the picture is not enough on its own.
>
> +-------+ 1 N +---------+ 1 N +----------+
> |Subject+-------+Principal+----------+Permission|
> +-------+ +----+----+ +----------+
> |
> +-----------+---------+
> | | |
> +--+---+ +--+--+ +-+--+
> |UserId| |Group| |Role|
> +------+ +-----+ +----+
>
>
> Another important point is how the Permissions of a
> Subject are determined. This is also where Project
> and implies() come in.
>
> Here's some code for an example implementation. I'm
> intentionally blending Turbine and JAAS concepts.
>
> SecurityManager sm =
> SecurityManager.getInstance();
> 1. PermissionCollection pc =
> sm.getPermissions(Subject s,
> 2.
> Project p);
> if (pc.implies(ReadPermission))
> {
> ...
>
> line 1:
>
> I ask the SecurityManager for a PermissionCollection
> for the Subject. Notice that I did NOT ask for the
> permissions of one of the Principal's. In the
> implementation I am proposing, the Permissions
> of the Subject is the set of all Permissions that
> are
> granted to *ALL* of the Subject's Principals. It's
> not
> just for the Principal under which I was
> authenticated.
> That way, if ManagerRolePrincipal has been granted a
> set of Permissions, and if our Subject has that
> Principal, then the Subject is granted those same
> Permissions. Same goes for every Role or Group to
> which the Subject belongs.
>
> Having said that, there's no reason that the
> implementation of getPermissions() couldn't define a
> different policy for how the Subject's Permissions
> are
> determined.
>
>
> line 2: What is this Project thing about?
>
> It is not enough to ask "What Permissions does this
> Subject have?". The next natural question is
> "Permissions to what?" I don't grant a Subject the
> ReadFilePermission without also specifying the file
> or
> directory in question.
>
> In the current Turbine security model, this is
> handled
> with the TURBINE_GROUP. The TURBINE_USER_GROUP_ROLE
> maps the user's permission both by their ROLE and by
> the GROUP. In my proposal, this same map is between
> the Subject, the Project, and the Principals (which
> happen to be contained by the Subject).
>
> The Project part is important. Don't just dismiss
> it.
>
> The reason I have called it 'Project' is because
> earlier threads on this discussion have decided that
> to
> be the preferred word. Other options have included
> Module, Zone, Realm, and in JAAS this is the
> CodeBase.
> I don't care what it's called with one exception:
> the
> name must not conflict conceptually with the notion
> of
> user groups (consider that a big -1 on
> TURBINE_GROUP).
>
>
> Having explained some of those details, the
> interface
> might be simplified to this:
>
> class Foo implements SecurityManager
> {
> boolean
> hasPermission(Subject,Project,Permission)
> ...
> }
>
>
> -Eric
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (3 of 3) - Subject, Principal, Project
details
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/8/02 8:04 AM, "Gareth Coltman" <ga...@majorband.co.uk> wrote:
>> Yeah, Group is a bad name for this, Project is much better.
>>
>>> -Eric
>
> Yep, group confused the hell of out all the developers in my team. I ended
> up just telling them to think about it as the domain. Project is also a bit
> of a non-standard term though. Perhaps realm or something is better,
How about the completely abstract term Resource. Just throwing out terms,
feel free to ignore :-)
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (3 of 3) - Subject, Principal, Project details
Posted by Gareth Coltman <ga...@majorband.co.uk>.
> Yeah, Group is a bad name for this, Project is much better.
>
> > -Eric
Yep, group confused the hell of out all the developers in my team. I ended
up just telling them to think about it as the domain. Project is also a bit
of a non-standard term though. Perhaps realm or something is better,
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes (3 of 3) - Subject, Principal, Project details
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> Here's some code for an example implementation. I'm
> intentionally blending Turbine and JAAS concepts.
>
> SecurityManager sm = SecurityManager.getInstance();
> 1. PermissionCollection pc = sm.getPermissions(Subject s,
> 2. Project p);
> if (pc.implies(ReadPermission))
> {
> ...
Just to clarify, I believe this can be made to fit into
the Authorizer architecture I have been proposing. You could
have an implementation of SPPAuthorizer (Subject, Principal,
Permission) whose checkSubjectPermission method does something
like that, and the Project part is passed through a Scope
definition (which, granted, I haven't even added to my proposal
yet...). Basically, a Scope is a class that defines the context
in which the authorization is being attempted. In classical
T2 terms, it would mean the Group; in your terminology, it
would mean the Project; for Jetspeed, it could mean the specific
Portlet the user is trying to execute; etc.
> line 2: What is this Project thing about?
>
> It is not enough to ask "What Permissions does this
> Subject have?". The next natural question is
> "Permissions to what?" I don't grant a Subject the
> ReadFilePermission without also specifying the file or
> directory in question.
>
> In the current Turbine security model, this is handled
> with the TURBINE_GROUP. The TURBINE_USER_GROUP_ROLE
> maps the user's permission both by their ROLE and by
> the GROUP. In my proposal, this same map is between
> the Subject, the Project, and the Principals (which
> happen to be contained by the Subject).
>
> The Project part is important. Don't just dismiss it.
In my view, you could have a SPPScope class that stores
the Project you talk about.
> The reason I have called it 'Project' is because
> earlier threads on this discussion have decided that to
> be the preferred word. Other options have included
> Module, Zone, Realm, and in JAAS this is the CodeBase.
> I don't care what it's called with one exception: the
> name must not conflict conceptually with the notion of
> user groups (consider that a big -1 on TURBINE_GROUP).
Yeah, Group is a bad name for this, Project is much better.
> -Eric
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>