This page shows the correct usage of the security related annotations:
- javax.annotation.security.RolesAllowed
- javax.annotation.security.PermitAll
- javax.annotation.security.DenyAll
- javax.annotation.security.RunAs
- javax.annotation.security.DeclareRoles
Basic idea
- By default all methods of a business interface are accessible, logged in or not
- The annotations go on the bean class, not the business interface
- Security annotations can be applied to entire class and/or individual methods
- The names of any security roles used must be declared via @DeclareRoles
No restrictions
Allow anyone logged in or not to invoke 'svnCheckout'.
...
Code Block |
---|
@Stateless public class OpenSourceProjectBean implements Project { @PermitAll public String svnCheckout(String s) { return s; } } |
- Allow anyone logged in or not to invoke 'svnCheckout'.
Restricting a Method
Restrict the 'svnCommit' method to only individuals logged in and part of the "committer" role. Note that more than one role can be listed.
Code Block |
---|
@Stateless @DeclareRoles({"committer"}) public class OpenSourceProjectBean implements Project { @RolesAllowed({"committer"}) public String svnCommit(String s) { return s; } public String svnCheckout(String s) { return s; } } |
- Allow only logged in users in the "committer" role to invoke 'svnCommit'.
- Allow anyone logged in or not to invoke 'svnCheckout'.
DeclareRoles
You need to update the @DeclareRoles when referencing roles via isCallerInRole(roleName).
...
Code Block |
---|
@Stateless @DeclareRoles({"committer"}) @RolesAllowed({"committer"}) public class OpenSourceProjectBean implements Project { public String svnCommit(String s) { return s; } public String svnCheckout(String s) { return s; } public String submitPatch(String s) { return s; } } |
- Allow only logged in users in the "committer" role to invoke 'svnCommit', 'svnCheckout' or 'submitPatch'.
Mixing class and method level restrictions
...
Code Block |
---|
@Stateless @DeclareRoles({"committer", "contributor"}) @RolesAllowed({"committer"}) public class OpenSourceProjectBean implements Project { public String svnCommit(String s) { return s; } public String svnCheckout(String s) { return s; } @RolesAllowed({"contributor"}) public String submitPatch(String s) { return s; } } |
- Allow only logged in users in the "committer" role to invoke 'svnCommit' or 'svnCheckout'
- Allow only logged in users in the "contributor" role to invoke 'submitPatch'.
PermitAll
When annotating a bean class with @RolesAllowed, the @PermitAll annotation becomes very useful on individual methods to open them back up again.
Code Block |
---|
@Stateless @DeclareRoles({"committer", "contributor"}) @RolesAllowed({"committer"}) public class OpenSourceProjectBean implements Project { public String svnCommit(String s) { return s; } @PermitAll public String svnCheckout(String s) { return s; } @RolesAllowed({"contributor"}) public String submitPatch(String s) { return s; } } |
- Allow only logged in users in the "committer" role to invoke 'svnCommit'.
- Allow only logged in users in the "contributor" role to invoke 'submitPatch'.
- Allow anyone logged in or not to invoke 'svnCheckout'.
DenyAll
The @DenyAll annotation can be used to restrict business interface access from anyone, logged in or not. The method is still invokable from within the bean class itself.
Code Block |
---|
@Stateless @DeclareRoles({"committer", "contributor"}) @RolesAllowed({"committer"}) public class OpenSourceProjectBean implements Project { public String svnCommit(String s) { return s; } @PermitAll public String svnCheckout(String s) { return s; } @RolesAllowed({"contributor"}) public String submitPatch(String s) { return s; } @DenyAll public String deleteProject(String s) { return s; } } |
- Allow only logged in users in the "committer" role to invoke 'svnCommit'.
- Allow only logged in users in the "contributor" role to invoke 'submitPatch'.
- Allow anyone logged in or not to invoke 'svnCheckout'.
- Allow no one logged in or not to invoke 'deleteProject'.
Illegal Usage
Generally, security restrictions cannot be made on AroundInvoke methods and most callbacks.
...