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

["Weaver, Scott" <Sw...@rippe.com>]

What I have got now is T2 security specific, but you could get the general
idea of what I am trying to accomplish.  

I admit I have no experience on t3, so this stuff is pure t2.  The code
needs some cleaning (read: fix VAJ's formatting) up and some decent
documentation.

Also, the packages refer to my application and would need to be migrated out
to  o.a.t.s.eric, correct?

There is a Polling implementation I use in the service that allows for
changes to the xml to be detected and applied with out re-starting the
container.  I can include this if it is of interest.

If everything above sounds cool, let me know and I'll fix it up asap.

Thanks,
Scott



> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: Friday, February 08, 2002 12:03 PM
> To: Turbine Developers List
> Subject: 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>

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

[Eric Dobbs <er...@dobbse.net>]

On Friday, February 8, 2002, at 10:29  AM, Weaver, Scott wrote:

> Also, the packages refer to my application and would need to be 
> migrated out
> to  o.a.t.s.eric, correct?

Please use o.a.t.security.turbine

> There is a Polling implementation I use in the service that allows for
> changes to the xml to be detected and applied with out re-starting the
> container.  I can include this if it is of interest.

I'm interested, but would like to keep that out for the time
being.  My first goal at the moment is to find the common
ground Gonzalo's and my security proposals, and I don't think
that is going to add much in that context. (there's that word
again. 8^)

> If everything above sounds cool, let me know and I'll fix it up asap.

+1

-Eric

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