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]

Reply via email to