Hi,
I would like to clear my position because from this letter I understand
that you are focused in wrong way.
1. In the current specification and realization the roles are static
defined in EJB classes as annotations or/and XML declaration, which is
OK and I don't want to change that.
This is perfect.
2.
The problems are:
2.1. It is not possible dynamically to change the groups which are
related to the current user;
2.2. It is not possible dynamically to change the groups which are
related to the current user depending from the current EnterpiseBean. I
mean that the bean can be the same, for example CompanyBean, but
depending on exact value(s) in the bean the groups to be different. So,
when you are selected company "Sun" you will have "observer" role which
comes from "anonymous" group and when you are selected company "Cosmos"
you will have "admin" roles, because your group will be "administrator";
2.3. From the source code I see that the roles in one group are
statically inserted using some kind of collection. This is not so
useful in one real and dynamic applications. When you change some roles
in some groups you MUST to restart the application server which is not
possible anytime.
Regards,
Miroslav Nachev
glassfish@javadesktop.org wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net