Skip to main content

@RolesAllowed shows inconsistant behavior in session bean!

7 replies [Last post]
rycohen2000
Offline
Joined: 2008-04-23

I've got this exasperating issue:
1. In a bean named "CategoryFacade" I've two identically annotated session bean methods (@RolesAllowed( { "admin", "developer" })). One method is an 'insert' method and the other an 'update'. There are no other annotations on the method, and there is no role annotation on the session bean as a whole

2. I access the bean from my stand-alone swing client, logging in as "auser" (role=='viewer')

3. I get an access violation for the 'save' method (expected), and none for the 'update' method (totally unexpected).

4. In the case of both methods the SessionContext confirms that the user has the expected 'viewer' role (and only that role).

5. If I connect as an admin, I can call both methods with no access violation (as expected).

6. If I change the access on the update method to "@DenyAll", it has no effect - any user/role can still call it.

In short, it seems like the 'update' method's annotations are invisible to the security system. And this at the same time as identical annotations and roles work fine on other methods in the same session bean.

Any ideas on what could be causing this? - Or how to fix it?

Thanks,
Ross

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
monzillo
Offline
Joined: 2004-05-08

> I've got this exasperating issue:
> 1. In a bean named "CategoryFacade" I've two
> identically annotated session bean methods
> ([b]@RolesAllowed( { "admin", "developer" })[/b]).
> One method is an 'insert' method and the other an
> 'update'. There are no other annotations on the
> method, and there is no role annotation on the
> session bean as a whole
>
> 2. I access the bean from my stand-alone swing
> client, logging in as "auser" (role=='viewer')

how does the role "viewer" relate to the roles "admin" and developer"
>
> 3. I get an access violation for the 'save' method
> (expected), and none for the 'update' method (totally
> unexpected).
>
how does the "save" method relate to the "insert" and "update" methods

> 4. In the case of both methods the SessionContext
> confirms that the user has the expected 'viewer' role
> (and [i]only[/i] that role).
>
> 5. If I connect as an admin, I can call both methods
> with no access violation (as expected).
>
> 6. If I change the access on the update method to
> "@DenyAll", it has no effect - any user/role can
> still call it.
>
> In short, it seems like the 'update' method's
> annotations are invisible to the security system.
> And this at the same time as identical annotations
> and roles work fine on other methods in the same
> session bean.
>
> Any ideas on what could be causing this? - Or how
> to fix it?
>
take a look at your applications policy files under domains/domainx/generated/policy/app-name

the denies will be in a file called excluded.policy
the granted permissions will be in a file called granted.policy

principal-2-role mapping happends before the policy file is written, so you will see grant statements for each of the principals granted to the role.

Ron
> Thanks,
> Ross

rycohen2000
Offline
Joined: 2008-04-23

Further investigation has led me to have a look at the module's JACC policy file generated at deployment time. It is interesting in that it shows what the container deduces of the bean's permission and roles from the annotations. Mine has 4 grant blocks, one for each role (dev,admin,editor,viewer), plus a 5th grant block giving open permissions on those bean methods having no restrictions set on them. Now my open grant block has entries for some methods in my bean that are clearly annotated as restricted. Wierder still, is that I can't really seem to see any rhyme or reason as to the methods it erroneously leaves unrestricted and the ones it correctly leaves out of the open grant block.

So, what I see in the policy file matches the program's actual behavior, but it does not match the annotations. So it seems clear that the JACC provider is getting confused when it looks at my annotations.

My bean implements a remote and local interface, and the remote interface extends a 3rd business interface. As far as I can tell this is not uncommon, and I can't see any reason why it should cause confusion.

Anyways, any hints and suggestion would be welcome...

Ross

monzillo
Offline
Joined: 2004-05-08

> Further investigation has led me to have a look at
> the module's JACC policy file generated at deployment
> time. It is interesting in that it shows what the
> container deduces of the bean's permission and roles
> from the annotations. Mine has 4 grant blocks, one
> for each role (dev,admin,editor,viewer), plus a 5th
> grant block giving open permissions on those bean
> methods having no restrictions set on them. Now my
> open grant block has entries for some methods in my
> bean that are clearly annotated as restricted.
> Wierder still, is that I can't really seem to see
> any rhyme or reason as to the methods it erroneously
> leaves unrestricted and the ones it correctly leaves
> out of the open grant block.
>
> So, what I see in the policy file matches the
> program's actual behavior, but it does not match the
> annotations. So it seems clear that the JACC
> provider is getting confused when it looks at my
> annotations.

sorry I didn't see this, before mylast post.

the containers annotation processor interprets the annotations, and represents them internally as method-permissions, then it calls the jacc-spi to tell the container to provision the policy subsystem. it is unlikely that the ploicy provider is doing other that it is being directed to do. so the problem would probably be upstraem somewhere, either in the user of the annotations or their processing, before the calls to the jacc configuration interfaces

>
> My bean implements a remote and local interface, and
> the remote interface extends a 3rd business
> interface. As far as I can tell this is not
> uncommon, and I can't see any reason why it should
> cause confusion.

I think the the (ejb) annotation processor only recognizes annotations on
things that implement the ejb interfaces, could it be that you have annotations on an interface that is not being recognized as an ejb?

Ron

>
> Ross

rycohen2000
Offline
Joined: 2008-04-23

Thanks for the input Monzillo - as far as my limited knowlege allows me to see, it seems that you were correct about the problem being upstream in the annotation processor:

Investigation over the weekend indicates that the culprit seems to be the confusion caused by my bean implementing/extending a parameterized interface. My bean inheritance:

CategoryFacade -> CategoryFacadeRemote -> FacadeRemote
CategoryFacade -> CategoryFacadeLocal

FacadeRemote is an interface inherited by a several different Beans, and it allows large parts of the client architecture to use different beans without really knowing too much about them -- very useful.

It is parameterized because without this, most of the return values and method parameters were plain Objects (beans, bean ids), and it was easy to write code that compiled, but would actually crash (ie you pass in a bean as a param when you should have passed in a bean id and vice versa).

More detail:

The FacadeRemote declaration:
[b]public interface FacadeRemote {[/b]...
where 'T' is the Entity type and 'Id' is the type of the entity's id object.

CategoryFacadeRemote declaration
[b]public interface CategoryFacadeRemote extends FacadeRemote {[/b]...

and finally CategoryBean declaration:
[b]public class CategoryFacade implements CategoryFacadeLocal, CategoryFacadeRemote {[/b]...

An example method as seen in all three files:

FacadeRemote method declaration:
[b]Id save(T entity);[/b]

extended (masked, perhaps) in the CategoryFacadeRemote interface:
[b]Integer save(Category entity);[/b]

implemented in CatgoryFacade:
[b]Integer save(Category entity) { [/b] ...

I'm fairly certain the annotation processor is getting confused over the differing method signatures as seen in
a. the Parameterized FacadeRemote and
b. the CategoryFacadeRemote and CategoryFacade.

Anyways, I have so far found three ways of getting around this (none of which are very satisfying):
1. Remove the FacadeRemote from the inheritance hierarchy. I tested this and it works, but it's not really a option at this point as there is too much client code that relies on its existence.

2. De-parameterize FacadeRemote. Again, I've tested this and it works, but it eliminates the compile-time checks from which we are supposed to benefit with a strongly-typed language. It also makes the code less readable - more plain Objects, casts, etc.

3. Write out the method permissions by hand in the ejb-jar.xml. This works, and although its painful and probably more error-prone than annotations (as I would like them to work), I'm currently leaning towards it as my solution.

I guess at this point I'm wondering whether this is is a case of
1. glassfish having an insufficiently subtle annotation processor, or
2. me having abused the spec and having tried to make go in places to which it was never (or at least not yet) intended to go.

Any insights/corrections/suggestions most welcome.

Thanks,
Ross

rycohen2000
Offline
Joined: 2008-04-23

At least until someone comes up with a better solution, I've decided to use the ejb-jar.xml to manage permission. Painful, but apparently still necessary.

Ross

ksak
Offline
Joined: 2005-05-20

Hi Ross,

The EJB 3.0 spec doesn't explicitly cover the parameterized case for method-level annotation processing. Best thing would be to file an IssueTracker bug so we can first track exactly what's happening in the implementation. Thanks.

--ken

rycohen2000
Offline
Joined: 2008-04-23

I sort of suspected that the spec didn't cover it, but wasn't sure. Anyways, thanks for the info - and I will file an entry in the IssueTracker.

Ross