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>