Security Roles On EJB3 Remote Interface Only

[adogg]

I'd like to impose security restrictions on my EJB3, but only in the Remote interface. If called via the Local interface, I want no restrictions.

Can I add @RolesAllowed annotations to the method declarations in my remote interface without adding them to the implementation class? Seems to me that that would secure calls made via the Remote interface only.

I've been trying to test it out, but I'm having a hard time compiling and want to know if I'm wasting my time.

[j2ee_junkie]

adogg,

I do not know for sure, but I would think that what you want is not possible. You could for example configure certain methods of your EJB to require certain roles. However, by securing the bean(even if only securing one method) means that any user must be authenticated before access.

However, you may consider using the run-as role mechanism. Assign run-as roles to any local bean accessing your EJB locally. Then secure your local interface mehtods to that run-as role.

let us know how solve this, cgriffith

[adogg]

Good call on the RunAs annotation, but I want to hit my EJB from an MBean, and as far as I can tell (and I've tried), I can't use RunAs on an MBean. Couple of things I was thinking about:

1. Make backdoor methods in my Local interface (not in my Remote) that don't have any security, and then callers using the local interface will have to be sure to use those unsecured methods.

2. Throw in an EJB (with only a local interface) that will proxy calls from using RunAs

[j2ee_junkie]

adogg,

Option 1, is what I mentioned before. If at least one method of a bean is secured, then the whole bean must be covered by a security domain. As such, access to any method, will require a caller to be authenticated. Note this does not mean the caller has to be authorized, just athenticated. So your MBean must authenticate as a caller.

Option 2, makes the most sense to me. I have used this method before.

As an aside, I solved a similar problem. I had a login module that needed to access a secured bean as part of the authentication/authorization process. However, the question remained how to A/A the login module. I developed a custom login module, and a package visible token object. A caller of my secured EJB had to be a member of the package in order to set the thread local token. That value was then sent to authentication layer as the password. Inside the custom login module (which was also a member of the package) the token was checked against the passed in password. Thus only a member of that package, and only the instance of that caller that set the token in that thread could have possibly been the one being authenticated.

let me know if you need more details and good luck, cgriffith

[adogg]

Believe it or not, #1 seems to be working for me. I have a SecurityDomain annotation in one of my EJBs and one of its methods has no RolesAllowed annotation, and I can call that method in the EJB without authentication. Just a regular NamingContext lookup.

Maybe the AOP joinpoints don't get applied to methods that don't have the RolesAllowed annotation, and so the SecurityDomain is never considered, and so no creds are necessary.

[adogg]

Yeah, I tried stripping everything down and I couldn't find a way to secure the remote interface only. Perhaps I'm doing something wrong, but the method in this class, for example:

@Remote
@SecurityDomain("mydomain")
public interface RemoteTestEJB3InterfaceSecured extends TestEJB3InterfaceSecured {

@RolesAllowed("admin")
void doSecure();
}


can be called by remote callers without having to authenticate, unless security is also placed on the implementation bean.

I couldn't find a section of the spec that mentions this, either.

Kind of disappointing that I can't place security restrictions on remote callers exclusively.

[j2ee_junkie]

adogg,

I am sure you can not add security role restrictions on a non-EJB3 class. Since the interface is not either a stateless/statefull session bean or a message driven bean, it is not a true EJB3 object. As such you can not add security restrictions.

I would suggest you place the restrictions on methods of the bean class. Provide two implementations of the method (or call one from the other with run-as) then place a restriction on one method. Finally, put the restricted version in remote interface, and the non-restricted in local interface.

cgriffith

[adogg]

Thanks. Yep. That's what I had to do. Less than elegant...