Re: Role based security ?

Nader,

Thanks for the input.
Do you have any code that does this "byte code weaving" for the purposes 
discussed (security) ?

Thanks a lot.

Cheers,
--Ravi


At 11:27 PM 9/1/2004 +0200, you wrote:
>I forgot to mention some important steps:
>
>10. Make sure that the current user run in its security context
>
>         //logon the user and create a JAAS Subject
>         java.security.auth.Subject subject = MyAuthentication.login();
>
>    Subject.doAsPrivileged(subject, new PrivilegedAction()
>    {
>     public Object run()
>     {
>          ServiceA serviceA = ServiceA.getInstance();
>          return null;
>     }
>
>    }, null);
>
>
>In the above, a Subject contains the various Roles that the user has
>
>
>11. Threading issues
>You have to make sure that any threads the current user is involved,
>inherits the correct security context.   Here, I am kind of uncertain what
>the best strategy would be.  Last time I did this, my Swing thread had some
>problems probably because of some other things.  Hopefully, it is not an
>issue if things are done in proper way.
>
>
>
>
>Best Regards
>
>--
>Nader Aeinehchi
>Aasenhagen 66 E
>2020 Skedsmokorset
>NORWAY
>Direct and Mobile +47 41 44 29 57
>Tel (private): +47 64 83 09 08
>Fax +47 64 83 08 07
>www.aeinehchi.com
>
>----- Original Message -----
>From: "Nader Aeinehchi" <[email protected]>
>To: "Avalon framework users" <[email protected]>
>Sent: Wednesday, September 01, 2004 11:10 PM
>Subject: Re: Role based security ?
>
>
> > Hello Ravi
> >
> > To my knowledge, such security has not yet been implemented in Merlin.
> > However, it is fairly easy to implement.  Here is a schematic solution.
>If
> > you need specific code, please contact me:
> >
> > 1. Create a class, MySecurityManager that extends
>java.lang.SecurityManager
> > 2. Override the method checkPermission()
> >
> > public void checkPermission(Permission perm){
> >
> >     if (perm instanceof MyMethodPermission){
> >          if(! isMethodAuthorized()){
> >             throw new SecurityException();
> >             }
> >     }
> > }
> >
> > 3. Create a method isMethodAuthorized in MySecurityManager.  This method
> > finds the caller class and method name based on the stack trace
> > private boolean isMethodAuthorized(){
> >
> >     //find the class name and method name of the caller class
> >     //check whether the user/role has an appropriate permission
> > }
> >
> > 4. Change the system wide security manager to your custom security
>manager:
> >
> > System.setSecurityManager(new MySecurityManager)
> >
> > 5. Find the mothods that you want to enforce security upon.  Say ServiceA
> > has a method called, getInstance(), that gives the instance of the
>service.
> > You would probably want that whenever this method is called, ServiceA
>calls
> > security manager and checks whether the current user/role has the proper
> > permission.  This is very simple to achieve (see the AOP notes below):
> >
> > public class ServiceA{
> >
> >     public void getInstance(){
> >
> >         if (System.getSecurityManager != null){
> >                 try{
> >                     // Or use AccessController directly
> >                     System.getSecurityManager().checkPermission(new
> > MyMethodPermission());
> >                 }catch(SecurityException e){
> >                     // do some logging....
> >                     return;  //do not proceed with the rest of the method,
> > do something interesting.....
> >                 }
> >         }
> >
> >         //else, security manager has been happy, proceed with the rest of
> > the method.
> >
> >     }
> >
> > }
> >
> > 6. Create a custom method permission, MyMethodPermission that extends
> > Permission
> >
> > public class MyMethodPermission extends java.security.Permission{
> >
> >     Permission(){}
> >     Permission(String className, String methodName){
> >
> >     }
> >
> >
> > }
> >
> > 7. You need to add some entries in your policy file
> > grant codeBase "somecodebase"
> >     principal xxx.yyy.MyRoleImplementationClass  "Superuser" {
> >    permission xxx.yyy.MyMethodPermission "ServiceA", "getInstance";
> >    permission xxx.yyy.MyMethodPermission "ServiceB", "antotherMethod";
> >
> >
> > 8. Start your application with security manager by providing JVM arguments
> >
> >
> > 9.   Step 5 can be automized, meaning the developers even do not need to
> > know about such code.  You may use different techniques( code
> > generation.....).  A simple but effective way is to use Aspect Oriented
> > Programming, AOP, to add such code later (byte code weaving).  Personally,
>I
> > would never ask/let developers to touch security code.  Security is an
> > aspect that should be handled by people with some insight.  I believe,
> > AOP/Code Generation techniques should be adopted.
> >
> > Hope that this helps.
> >
> >
> > Best Regards
> >
> > --
> > Nader Aeinehchi
> > Aasenhagen 66 E
> > 2020 Skedsmokorset
> > NORWAY
> > Direct and Mobile +47 41 44 29 57
> > Tel (private): +47 64 83 09 08
> > Fax +47 64 83 08 07
> > www.aeinehchi.com
> >
> > ----- Original Message -----
> > From: "Ravi Nudurumati" <[email protected]>
> > To: "Avalon framework users" <[email protected]>
> > Sent: Wednesday, September 01, 2004 7:57 PM
> > Subject: Role based security ?
> >
> >
> > > Hello,
> > >
> > > Is there some way to enforce "role-based" security on different
> > > services/components deployed in Merlin ?
> > >
> > > Ex:
> > > I want user X to have access to services A, B and C
> > > user Y to have access to services C and D only
> > >
> > > Please let me know if this is possible currently and if yes, how and if
> > not
> > > what is the best way to achieve this.
> > >
> > > Thanks,
> > > --Ravi
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]