JSR 168 specifications does not define any particular security implementation even though you can get the authenticated user and its role.
In JBoss portal, each portlet defines its own security rules but the portal gives an easy way to implement it using the AuthorizationRealm obtained by NukesRenderRequest or NukesActionRequest.
The security mechanism works with rules, a rule consist in three elements:
The role that you want to apply the rule to
The context in which the rule will be applied
The credential given to the role in the context specified
A context is defined by the portlet developer, it is represented by an array of Strings. For example, the forum portlet is divided into sections and each sections are divided into forums. Typically a webmaster will want to grant premissions on whole sections and/or just some forums. {"CategoryName", "forumName"} could be a context for the forum called forumName of the category CAtegoryName. To define a context for a whole section, a user can use regular expression like {"CategoryName", ".*"} and it would define context on the whole category. Again this is just a matter of portlet developer choice. The meaning of a context for a particular portlet should be documented in the portlet guide.
The rights to give are the same for any portlet, we often want to add write or read access, JBoss portal defines 9 levels of privileges that are linked together. In the default configuration, a role has also the rights of roles with a lower number. For example, the level 8 has the rights of level 0 to 7.
All those levels have a name for their common usage
No restrict access to a role in a context
Can be used to give access to a summary of a story but not to the whole story
This gives reading access to a role
This gives the ability to add comments to a role if the portlet has such a feature
This should be used to add the possibility to add or remove some data entered by others
This should be used to allow a role to edit data on the portal
This should be used to allow a role to add content to the portal
Gives the right to delete content from the portal
This is the ultimate level, this gives rights to anything
As specified earlier, by default someone who has COMMENT access level also have READ, OVERVIEW and NONE acces levels. For even more flexibility, the portal allows you to change how the levels are dependant one to the other. This is done by modifying the authorization matrix in jboss.nukes.core.security.Level. You can then define which access level implies which other.
To define rules on a portlet, you need to adapt the nukes-instance.xml file. Inside a instance tag, you should add a security tag. This tag contains all the rules you want. For example, the following tags would give reading access on everything for the Users role and admin access to the Admins role. Of course you can define a finer grain by specifying the correct pattern.
<security>
<rules>
<rule role="Admins" patterns="" level="admin"/>
<rule role="Users" patterns="" level="read"/>
</rules>
</security>A portlet developer will need to make sure all the operations are correctly checked for credentials. To programatically do so, he will need to get a AuthorizationRealm from the NukesRequest then use this object to check against the user's roles.
AuthorizationRealm authorizationRealm = nukesRequest.getAuthorizationRealm();
boolean readAuthorized = authorizationRealm.isAuthorized("Users",
new String[] {"My Category", "My Forum"},
org.jboss.nukes.core.security.Level.ACCESS_READ);Getting the list of roles names is not always convenient, to simplify this task, the class org.jboss.nukes.core.portlet.PortletHelper has the following static method public static boolean isAuthorized(AuthorizationRealm authRealm, User user, String[] test, Level level), this method is even more convenient as you get the user from the NukesRequest. A call to this method will look like:
PortletHelper.isAuthorized(nukesRequest.getAuthorizationRealm(),
nukesRequest.getUser(),
new String[] {"My category", "My forum"},
Level.ACCESS_READ)