Well, part of the problem that's not clear here is simply that with most JEE applications, the actual resources tend to be static.
For example, web pages. These are nominally static resources. In the JEE model, if you wish to add security, you have a static list of web pages and roles associate with those pages. The only (standard) way to add a new web page to a JEE system is to update the WAR and redeploy the application, so the requirement to redeploy the application in order to update the security is not spectacularly arduous in this model.
In EJB, the resources are most certainly static -- as they're basically method calls, and there's most certainly no standard way of adding methods dynamically to an EJB. So, these having a static role mapping is most certainly not up for debate. And, in fact, this has been improved with the JEE 5 annotations.
Where the model breaks down, however, is when the resources being served are dynamic. For example, even though a URL may appear static (
http://host.com/webapp/resource.html), there's nothing stopping a developer from having that routed through a servlet and being completely dynamic. "resource.html" could easily be stored in a database, or simply generated on the fly.
In this case, the JEE model pretty much fails outright. As has been noticed, there's simply no way to add JEE Roles (much less mapping them to groups) on the fly in the JEE spec.
For example, "
http://host.com/webapp/cinema69/ticket_revenues.html" (very RESTy).
You'd only want someone affiliated with "Cinema 69" to be able to see the ticket revenues. And it would be nice to be able to do:
[code]
String cinemaName = getCinemaId(request).toUpperCase(); // cinema69 in this case
String role = "MGR_" + cinemanName; // role == "MGR_CINEMA69"
if (request.isUserInRole(role)) {
// render ticket revenues
} else {
// 403 error --- bad user
}
[/code]
With all of the being essentially dynamic, the JEE model as specified in the standard, falls flat. While JBoss may well have extended this capability, that extension is simply outside the specification.
At this point the developer is effectively on their own. You essentially have to write your own Role based authorization system.
However, you can still leverage the container for AUTHENTICATION, while implementation your own AUTHORIZATION, based upon the principal returned by the authentication system.
But yea, for a more dynamic system, you're pretty much stuck. Those parts of the security system simply aren't well exposed in GF, mostly because they're not well exposed in the JEE spec.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=217496