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 18:02:41 UTC

Re: Security Changes (3 of 3) - Subject, Principal, Project detai ls

On Friday, February 8, 2002, at 07:14  AM, Weaver, Scott wrote:

> I've actually already started using this in reverse.  I have a service 
> based
> on an XML file that binds a set of Groups, Roles and Permission to a
> specific context.
> Currently I use it to prevent hard-coding required security into 
> actions and
> screens.  The isAuthorized() method of screens and actions query  the
> service to find out what security is required for that specific context
> (which could be a screen or action or just about anything).
> Sample config file
> <SecurityContext>
>   <context name="Security.vm">
>   <description>Seceurity Maintenance</description>
>   <group name="agora_system">
>     <role>user_maintenance</role>
>     <permission>change</permission>
>     <permission>add</permission>
>   </group>
> </context>
> </SecurityContext>

With Gonzalo's enthusiasm for this example, I am convinced that
our proposals are converging to some common ground.

Scott, here's where I see your example fitting into my proposed
implementation.  It's the persistent data structure that is
searched inside this method:
PermissionCollection getPermissions(Subject, Project);

Using the terms from your XML config file:
PermissionCollection getPermissions(Role, Group);

(I should add, I'm not attached to PermissionCollection, just
using this JAAS term for expedience).

And obviously Gonzalo sees this fitting into a notion of Scope
in his proposal.

I think it would be good to see how you've implemented this.
Maybe we can check it into the proposals directory in the
rundata_security_branch so we can have a look.  I think it will
help catalyze Gonzalo's and my proposals.

-Eric


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>