You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2003/12/14 16:53:50 UTC
[RT] Security Protection Mechanism in Merlin
Gang,
Maybe this has been discussed before, but I haven't seen it for quite a while,
so I start with a blank piece of paper.
Security Protection Mechanism is about a simplified way for all components to
protect objects, methods, resources and so on. The Protection Mechanism
should support both "trusted system components" as well as "non-trusted
users" and everything in between.
I have been thinking a little bit about this recently, and would like to get
it going;
My very short Wish-list
1. Codebase security a la standard Java security policies, to fulfill the
"trusted system components" vs "untrusted system components" difference.
2. Subject level security, leveraging the JAAS, for User based authorization
at any granularity.
3. Ease-of-Use for both Component Author and Component User. Very little code
should be required by each of these groups.
4. Pluggable architecture for the management of users, roles and rights, to
allow for simple authorization systems or all the way to DB driven ones.
Neither the component author nor the component user should need to worry
about what authorization system that is in place.
I have been drawing on a piece of paper for quite a while now, and the
"cleanest" (IMHO) way I see it happening is to introduce support for it in
Framework. The strong argument would be that security is (or should be for
all non-M$ apps) a very central piece of concern;
public interface SecureServiceManager extends ServiceManager
{
Object lookup( String role, Object securityContext );
// returns a securityContext, i.e. an javax.security.auth.Subject
// instance. Not sure if it is a security risk to return the Subject
// to the caller. Need to be investigated.
Object login( CallbackHandler callback );
void logout( Object securityContext );
}
and the corresponding
public interface SecureServiceable
{
void service( SecureServiceManager manager );
}
BUT, one could harness the Context as well, so that the "User Code" would be
something like;
public void contextualize( Context context )
{
SecureServiceManager secman = (SecureServiceManager) context.get(
"avalon.security.servicemanager" );
// and so on...
}
It doesn't look as neat, and I suggest we keep that debate separately. Below
is showacse of the use with the introduction of SecureServiceManager.
Let's look at "use-case" part;
The service that contains the protected operations should be fairly simple to
write.
public interface MyService
{
void doSomeOperation();
}
public class MyComponent extends AbstractLogEnabled
implements MyProtectedService
{
private Permission m_RequiredPermission;
public MyComponent()
{
m_RequiredPermission = new WhatEverPermission( "ForInstanceAName" );
}
public void doSomeOperation()
{
AccessController.checkPermission( m_RequiredPermission );
// :
// :
}
}
Now let's say a web service component want to use the service above, BUT where
doSomeOperation() is granted only to some people.
First of all we need to provide some authentication, and secondly the
authorization and interceptor for the above component.
public interface MyWebService
{
Object login( CallbackHandler callback );
void logout( Object securityContext );
void serveTheRequest();
}
public class MyComponent extends AbstractLogEnabled
implements SecureServiceable
{
private SecureServiceManager m_Manager;
public void service( SecureServiceManager man )
{
m_Manager = man;
}
// The CallbackHandler is from javax.security.auth.callback
public Object login( CallbackHandler callback )
{
// Returns, if successful, a security context to be used
// in protected calls.
return m_Manager.login( callback );
}
public void logout( Object securityContext )
{
m_Manager.logout( securityContext );
}
void someWebRequest( Object securityContext )
{
MySecureService mss = m_Manager.lookup( MySecureService.ROLE,
securityContext );
mss.serveTheRequest();
m_Manager.release(); // Not going to argue if this is required now...
}
}
IMHO, the above use-case is "really clean" :o)
Minimal amount of work for both the component author and the component user.
The above scenario is nice, BUT doesn't it only covers part of the problem,
i.e. protecting a particular method?
What about I need to protect individual objects or resources, based on users??
The establishment of the AccessControlContext in Merlin, will provide full
protection to everything, so by creating sophisticated Permission classes, I
can practically protect according to any strategy, for instance;
Let's say I want to protected a persisted database object.
public class MyValueObject
{
private String m_PrimaryKey;
private String m_Name;
private String m_Description;
private Collection m_Widgets;
public MyValueObject()
{}
public String getPrimaryKey()
{
return m_PrimaryKey;
}
public String getName()
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".name", "read" );
AccessController.checkPermission( perm );
return m_Name;
}
public void setName( String name )
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".name", "write" );
AccessController.checkPermission( perm );
m_Name = name;
}
public String getDescription()
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".description", "read" );
AccessController.checkPermission( perm );
return m_Description;
}
public void setDescription( String descr )
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".description", "write" );
AccessController.checkPermission( perm );
m_Description = descr;
}
public Collection getWidgets()
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".widgets", "read" );
AccessController.checkPermission( perm );
ArrayList clone = new ArrayList( m_Widgets );
return clone;
}
public void addWidget( Widget widget )
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".widgets", "add" );
AccessController.checkPermission( perm );
m_Widgets.add( widget );
}
public void removeWidget( Widget widget )
{
DatabasePermission perm =
new DatabasePermission( m_PrimaryKey + ".widgets", "remove" );
AccessController.checkPermission( perm );
m_Widgets.remove( widget );
}
}
But then you would need to create some fairly fancy DatabasePermission class,
which understand how permissions granted would imply access or not according
to the permissions required. This is bringing us over to the Authorization
Management, which is outside the scope of this RT (see below). However, it is
important to notice that the DatabasePermission above, is therefor NOT a good
solution, since it ties the compont to tightly to a particular Authorization
Management system (DB).
Now, back to Merlin and how to implement this;
Each lookup in the SecureServiceManager, needs to make sure that the security
context is the same, otherwise instantiate a new Proxy (!), but not
necessarily a new component.
The ApplianceInvocationHandler would need to wrap the whole call with
something like this (Exception handling left out);
public Object invoke( final Object proxy,
final Method method,
final Object[] args )
throws Throwable
{
MyAction action = new MyAction( m_Instance, method, args );
return Subject.doAs( m_Subject, action );
}
private class MyAction
implements PrivilegedAction
{
private Method m_Method;
private Object m_Instance;
private Object[] m_Args;
PrivilegedAction( Object instance, Method method, Object[] args)
{
m_Instance = instance;
m_Args = args;
m_Method = method;
}
public Object run()
{
return m_Method.invoke( m_Instance, m_Args );
}
}
And then we would need a new SecureSecurityManager and understand the
SecureServiceable interface signature...
Believe it or not, but I have only cover ONE out THREE issues with user based
authorization, namely the Protection Mechanism.
We need to work out
1. Security Configuration, i.e. the pluggable system of components making up
the complete security system.
2. Standardized Authorization Management, i.e. standardized way to manage "Who
can do What", how to add/remove/edit/audit users, roles and rights.
Ok, that's about it for now... How do you all feel about this subject?? I hope
you are not in M$ mood ;o)
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Security Protection Mechanism in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 15 December 2003 04:52, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> Just put the security context into a thread local variable. Typically
> this is going to be a principal.
Say javax.security.auth.Subject...
> The service manager implementation can
> handle the determination if pricipal is required or not - and do the
> autentication and access contol if required.
Can it??
This is one thing I have tried to twist my head around. How does it know which
User it should execute as? AFAICT, only the caller could possibly know that,
no? Would also need a hook for the CallbackHandler somewhere as it would be
the "client code" that provides it. (Hmmm, some thoughts required here...)
> Method level access control could be moved to the proxy. I.e. no need
> to do AccessController.checkPermission - we can takie care of that
> automatically using metadata available on the container side of the
> equation.
I initially thought that too, but decided against it for one reason only;
Component Documentation!!
The Component Author will be required to add a section of Security Permission
Requirements, and IMHO it should include everything. And if part of the
requirement is hidden in the Proxy, the CA will forget to document it, and
users will be somewhat confused.
<snip content="record protection example" />
> Imoportant question - how much of this can be moved to metainfo on methods?
Yes important question. But my conclusion is that there is a definate need of
runtime computed "required permissions", such as the PrimaryKey example
shows.
> >And then we would need a new SecureSecurityManager and understand the
> >SecureServiceable interface signature...
>
> Ummm, not sure - should be able to handle this without distrupting
> interfaces or supply info to the component.
I have been digging for alternate solutions via the LifeCycle extension
mechanism, and might come up with a proposal later. Right now not sure it
complete security-agnostic Framework will cut it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Security Protection Mechanism in Merlin
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>Gang,
>Maybe this has been discussed before, but I haven't seen it for quite a while,
>so I start with a blank piece of paper.
>
>Security Protection Mechanism is about a simplified way for all components to
>protect objects, methods, resources and so on. The Protection Mechanism
>should support both "trusted system components" as well as "non-trusted
>users" and everything in between.
>
>I have been thinking a little bit about this recently, and would like to get
>it going;
>
>My very short Wish-list
>1. Codebase security a la standard Java security policies, to fulfill the
>"trusted system components" vs "untrusted system components" difference.
>
>2. Subject level security, leveraging the JAAS, for User based authorization
>at any granularity.
>
>3. Ease-of-Use for both Component Author and Component User. Very little code
>should be required by each of these groups.
>
>4. Pluggable architecture for the management of users, roles and rights, to
>allow for simple authorization systems or all the way to DB driven ones.
>Neither the component author nor the component user should need to worry
>about what authorization system that is in place.
>
>
Good wish list.
Basic stuff that is needed.
>
>I have been drawing on a piece of paper for quite a while now, and the
>"cleanest" (IMHO) way I see it happening is to introduce support for it in
>Framework. The strong argument would be that security is (or should be for
>all non-M$ apps) a very central piece of concern;
>
>public interface SecureServiceManager extends ServiceManager
>{
> Object lookup( String role, Object securityContext );
>
> // returns a securityContext, i.e. an javax.security.auth.Subject
> // instance. Not sure if it is a security risk to return the Subject
> // to the caller. Need to be investigated.
> Object login( CallbackHandler callback );
>
> void logout( Object securityContext );
>}
>
>and the corresponding
>
>public interface SecureServiceable
>{
> void service( SecureServiceManager manager );
>}
>
>BUT, one could harness the Context as well, so that the "User Code" would be
>something like;
>
>public void contextualize( Context context )
>{
> SecureServiceManager secman = (SecureServiceManager) context.get(
>"avalon.security.servicemanager" );
> // and so on...
>}
>
>It doesn't look as neat, and I suggest we keep that debate separately. Below
>is showacse of the use with the introduction of SecureServiceManager.
>
#*&!$* spit!
Just put the security context into a thread local variable. Typically
this is going to be a principal. The service manager implementation can
handle the determination if pricipal is required or not - and do the
autentication and access contol if required.
>
>
>Let's look at "use-case" part;
>
>The service that contains the protected operations should be fairly simple to
>write.
>
>public interface MyService
>{
> void doSomeOperation();
>}
>
>public class MyComponent extends AbstractLogEnabled
> implements MyProtectedService
>{
> private Permission m_RequiredPermission;
>
> public MyComponent()
> {
> m_RequiredPermission = new WhatEverPermission( "ForInstanceAName" );
> }
>
> public void doSomeOperation()
> {
> AccessController.checkPermission( m_RequiredPermission );
> // :
> // :
> }
>}
>
Method level access control could be moved to the proxy. I.e. no need
to do AccessController.checkPermission - we can takie care of that
automatically using metadata available on the container side of the
equation.
<snip>
>IMHO, the above use-case is "really clean" :o)
>
But could be cleaner!
But thatr's what your hinting at below isn't it?
>Minimal amount of work for both the component author and the component user.
>
Which could be reduced to zero.
>
>The above scenario is nice, BUT doesn't it only covers part of the problem,
>i.e. protecting a particular method?
>What about I need to protect individual objects or resources, based on users??
>
>The establishment of the AccessControlContext in Merlin, will provide full
>protection to everything, so by creating sophisticated Permission classes, I
>can practically protect according to any strategy, for instance;
>
>Let's say I want to protected a persisted database object.
>
>public class MyValueObject
>{
> private String m_PrimaryKey;
> private String m_Name;
> private String m_Description;
> private Collection m_Widgets;
>
> public MyValueObject()
> {}
>
> public String getPrimaryKey()
> {
> return m_PrimaryKey;
> }
>
> public String getName()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".name", "read" );
> AccessController.checkPermission( perm );
> return m_Name;
> }
>
> public void setName( String name )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".name", "write" );
> AccessController.checkPermission( perm );
> m_Name = name;
> }
>
> public String getDescription()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".description", "read" );
> AccessController.checkPermission( perm );
> return m_Description;
> }
>
> public void setDescription( String descr )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".description", "write" );
> AccessController.checkPermission( perm );
> m_Description = descr;
> }
>
> public Collection getWidgets()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "read" );
> AccessController.checkPermission( perm );
> ArrayList clone = new ArrayList( m_Widgets );
> return clone;
> }
>
> public void addWidget( Widget widget )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "add" );
> AccessController.checkPermission( perm );
> m_Widgets.add( widget );
> }
>
> public void removeWidget( Widget widget )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "remove" );
> AccessController.checkPermission( perm );
> m_Widgets.remove( widget );
> }
>}
>
>
Imoportant question - how much of this can be moved to metainfo on methods?
>
>But then you would need to create some fairly fancy DatabasePermission class,
>which understand how permissions granted would imply access or not according
>to the permissions required. This is bringing us over to the Authorization
>Management, which is outside the scope of this RT (see below). However, it is
>important to notice that the DatabasePermission above, is therefor NOT a good
>solution, since it ties the compont to tightly to a particular Authorization
>Management system (DB).
>
>
>Now, back to Merlin and how to implement this;
>
>Each lookup in the SecureServiceManager, needs to make sure that the security
>context is the same, otherwise instantiate a new Proxy (!), but not
>necessarily a new component.
>
>The ApplianceInvocationHandler would need to wrap the whole call with
>something like this (Exception handling left out);
>
>public Object invoke( final Object proxy,
> final Method method,
> final Object[] args )
> throws Throwable
>{
> MyAction action = new MyAction( m_Instance, method, args );
> return Subject.doAs( m_Subject, action );
>}
>
>private class MyAction
> implements PrivilegedAction
>{
> private Method m_Method;
> private Object m_Instance;
> private Object[] m_Args;
>
> PrivilegedAction( Object instance, Method method, Object[] args)
> {
> m_Instance = instance;
> m_Args = args;
> m_Method = method;
> }
>
> public Object run()
> {
> return m_Method.invoke( m_Instance, m_Args );
> }
>}
>
>
>And then we would need a new SecureSecurityManager and understand the
>SecureServiceable interface signature...
>
Ummm, not sure - should be able to handle this without distrupting
interfaces or supply info to the component.
>
>Believe it or not, but I have only cover ONE out THREE issues with user based
>authorization, namely the Protection Mechanism.
>
>We need to work out
>1. Security Configuration, i.e. the pluggable system of components making up
>the complete security system.
>2. Standardized Authorization Management, i.e. standardized way to manage "Who
>can do What", how to add/remove/edit/audit users, roles and rights.
>
>
>Ok, that's about it for now... How do you all feel about this subject?? I hope
>you are not in M$ mood ;o)
>
>
:-)
Sounds good, corresponds to the roadmap, and fits with immediate
interests in building the plugable facilities side of things for
container profiling.
Cheers, Steve.
>Cheers,
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Security Protection Mechanism in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 15 December 2003 05:35, Shash Chatterjee wrote:
> Niclas,
>
> This sounds very close to the biggest addition to Fortress we have put
> into Keel (http://www.keelframework.org). We have the following:
Are you suggesting that we "promote" your additions into Avalon??
I'll take a look as soon as I can...
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Security Protection Mechanism in Merlin
Posted by Shash Chatterjee <sa...@badfw.org>.
Niclas,
This sounds very close to the biggest addition to Fortress we have put
into Keel (http://www.keelframework.org). We have the following:
- KeelServiceManager, extends FortressServiceManager, that provides a
lookup(String role, Context c).
- Securable lifecycle method, to set and get an AuthManager for
authorization, AuthManagers can be a global one, common to all services
that implement a Securable interface. Or, a component's configuration
can define a am=some-hint attribute, and the container will set a
specific AuthManager for the component. AuthManager is applied to the
component via Fortress' life-cycle extensions.
- We have three implementations of the AuthManager service,
configuration based, persistence-based (DB), and a null authorization
for bypassing authorization.
- We have an AuthenticationManager service that uses JAAS for
authentication. After successful authentication, an UserEnvironment
object is populated and stored in the request-context, which is then
passed to the lookup(role, context) above. We have authentication
implementations for configuration, persistence(DB)-based, NIS, LDAP and
NT-domains (again, using JAAS login modules).
If this is useful as a starting point, for Merlin or Fortress or the
next-gen container, with appropriate changes based on consensus, then it
would be nice to have a standard way for authenticating/authorizing all
Avalon Framework components.
Shash
Niclas Hedhman wrote:
> Gang,
> Maybe this has been discussed before, but I haven't seen it for quite a while,
> so I start with a blank piece of paper.
>
> Security Protection Mechanism is about a simplified way for all components to
> protect objects, methods, resources and so on. The Protection Mechanism
> should support both "trusted system components" as well as "non-trusted
> users" and everything in between.
>
> I have been thinking a little bit about this recently, and would like to get
> it going;
>
> My very short Wish-list
> 1. Codebase security a la standard Java security policies, to fulfill the
> "trusted system components" vs "untrusted system components" difference.
>
> 2. Subject level security, leveraging the JAAS, for User based authorization
> at any granularity.
>
> 3. Ease-of-Use for both Component Author and Component User. Very little code
> should be required by each of these groups.
>
> 4. Pluggable architecture for the management of users, roles and rights, to
> allow for simple authorization systems or all the way to DB driven ones.
> Neither the component author nor the component user should need to worry
> about what authorization system that is in place.
>
>
> I have been drawing on a piece of paper for quite a while now, and the
> "cleanest" (IMHO) way I see it happening is to introduce support for it in
> Framework. The strong argument would be that security is (or should be for
> all non-M$ apps) a very central piece of concern;
>
> public interface SecureServiceManager extends ServiceManager
> {
> Object lookup( String role, Object securityContext );
>
> // returns a securityContext, i.e. an javax.security.auth.Subject
> // instance. Not sure if it is a security risk to return the Subject
> // to the caller. Need to be investigated.
> Object login( CallbackHandler callback );
>
> void logout( Object securityContext );
> }
>
> and the corresponding
>
> public interface SecureServiceable
> {
> void service( SecureServiceManager manager );
> }
>
> BUT, one could harness the Context as well, so that the "User Code" would be
> something like;
>
> public void contextualize( Context context )
> {
> SecureServiceManager secman = (SecureServiceManager) context.get(
> "avalon.security.servicemanager" );
> // and so on...
> }
>
> It doesn't look as neat, and I suggest we keep that debate separately. Below
> is showacse of the use with the introduction of SecureServiceManager.
>
>
> Let's look at "use-case" part;
>
> The service that contains the protected operations should be fairly simple to
> write.
>
> public interface MyService
> {
> void doSomeOperation();
> }
>
> public class MyComponent extends AbstractLogEnabled
> implements MyProtectedService
> {
> private Permission m_RequiredPermission;
>
> public MyComponent()
> {
> m_RequiredPermission = new WhatEverPermission( "ForInstanceAName" );
> }
>
> public void doSomeOperation()
> {
> AccessController.checkPermission( m_RequiredPermission );
> // :
> // :
> }
> }
>
> Now let's say a web service component want to use the service above, BUT where
> doSomeOperation() is granted only to some people.
> First of all we need to provide some authentication, and secondly the
> authorization and interceptor for the above component.
>
>
> public interface MyWebService
> {
> Object login( CallbackHandler callback );
>
> void logout( Object securityContext );
>
> void serveTheRequest();
> }
>
>
> public class MyComponent extends AbstractLogEnabled
> implements SecureServiceable
> {
> private SecureServiceManager m_Manager;
>
> public void service( SecureServiceManager man )
> {
> m_Manager = man;
> }
>
> // The CallbackHandler is from javax.security.auth.callback
> public Object login( CallbackHandler callback )
> {
> // Returns, if successful, a security context to be used
> // in protected calls.
> return m_Manager.login( callback );
> }
>
> public void logout( Object securityContext )
> {
> m_Manager.logout( securityContext );
> }
>
> void someWebRequest( Object securityContext )
> {
> MySecureService mss = m_Manager.lookup( MySecureService.ROLE,
> securityContext );
>
> mss.serveTheRequest();
> m_Manager.release(); // Not going to argue if this is required now...
> }
> }
>
>
> IMHO, the above use-case is "really clean" :o)
> Minimal amount of work for both the component author and the component user.
>
> The above scenario is nice, BUT doesn't it only covers part of the problem,
> i.e. protecting a particular method?
> What about I need to protect individual objects or resources, based on users??
>
> The establishment of the AccessControlContext in Merlin, will provide full
> protection to everything, so by creating sophisticated Permission classes, I
> can practically protect according to any strategy, for instance;
>
> Let's say I want to protected a persisted database object.
>
> public class MyValueObject
> {
> private String m_PrimaryKey;
> private String m_Name;
> private String m_Description;
> private Collection m_Widgets;
>
> public MyValueObject()
> {}
>
> public String getPrimaryKey()
> {
> return m_PrimaryKey;
> }
>
> public String getName()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".name", "read" );
> AccessController.checkPermission( perm );
> return m_Name;
> }
>
> public void setName( String name )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".name", "write" );
> AccessController.checkPermission( perm );
> m_Name = name;
> }
>
> public String getDescription()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".description", "read" );
> AccessController.checkPermission( perm );
> return m_Description;
> }
>
> public void setDescription( String descr )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".description", "write" );
> AccessController.checkPermission( perm );
> m_Description = descr;
> }
>
> public Collection getWidgets()
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "read" );
> AccessController.checkPermission( perm );
> ArrayList clone = new ArrayList( m_Widgets );
> return clone;
> }
>
> public void addWidget( Widget widget )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "add" );
> AccessController.checkPermission( perm );
> m_Widgets.add( widget );
> }
>
> public void removeWidget( Widget widget )
> {
> DatabasePermission perm =
> new DatabasePermission( m_PrimaryKey + ".widgets", "remove" );
> AccessController.checkPermission( perm );
> m_Widgets.remove( widget );
> }
> }
>
>
> But then you would need to create some fairly fancy DatabasePermission class,
> which understand how permissions granted would imply access or not according
> to the permissions required. This is bringing us over to the Authorization
> Management, which is outside the scope of this RT (see below). However, it is
> important to notice that the DatabasePermission above, is therefor NOT a good
> solution, since it ties the compont to tightly to a particular Authorization
> Management system (DB).
>
>
> Now, back to Merlin and how to implement this;
>
> Each lookup in the SecureServiceManager, needs to make sure that the security
> context is the same, otherwise instantiate a new Proxy (!), but not
> necessarily a new component.
>
> The ApplianceInvocationHandler would need to wrap the whole call with
> something like this (Exception handling left out);
>
> public Object invoke( final Object proxy,
> final Method method,
> final Object[] args )
> throws Throwable
> {
> MyAction action = new MyAction( m_Instance, method, args );
> return Subject.doAs( m_Subject, action );
> }
>
> private class MyAction
> implements PrivilegedAction
> {
> private Method m_Method;
> private Object m_Instance;
> private Object[] m_Args;
>
> PrivilegedAction( Object instance, Method method, Object[] args)
> {
> m_Instance = instance;
> m_Args = args;
> m_Method = method;
> }
>
> public Object run()
> {
> return m_Method.invoke( m_Instance, m_Args );
> }
> }
>
>
> And then we would need a new SecureSecurityManager and understand the
> SecureServiceable interface signature...
>
> Believe it or not, but I have only cover ONE out THREE issues with user based
> authorization, namely the Protection Mechanism.
>
> We need to work out
> 1. Security Configuration, i.e. the pluggable system of components making up
> the complete security system.
> 2. Standardized Authorization Management, i.e. standardized way to manage "Who
> can do What", how to add/remove/edit/audit users, roles and rights.
>
>
> Ok, that's about it for now... How do you all feel about this subject?? I hope
> you are not in M$ mood ;o)
>
> Cheers,
> Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org