|
Replies:
27
-
Last Post:
May 25, 2009 4:50 AM
by: kumarjayanti
|
|
|
|
|
|
|
Dynamic role handling
Posted:
Sep 8, 2006 2:17 AM
|
|
|
For web based authentication to work, all the roles must be known at runtime to setup the deployment descriptor.
The problem is that my application needs to manage roles at runtime. So far that is no problem because I'm able to create them using the JdbcRealm and EJBs. But I need to update the deployment descriptor evertime a new role is is inserted because the login mechanism won't accept the new roles until I update the security section in the deployment descriptor, so that this role can access the different areas in my web application.
Is there a way around this, possibly without having to implement a custum security realm?
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 8, 2006 8:34 AM
in response to: the_burrito
|
|
|
Your container should provide the ability to take the roles defined in your DD and map those to real user's or groups. Your roles doesn't change because they're hardcoded into the application (i.e. isUserInRole("role-name")).
It sounds like your container doesn't support this so you'll have to build your own custom security realm.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 9, 2006 10:46 AM
in response to: the_burrito
|
|
|
Security Roles, as defined by the JEE spec, are the fixed part of the security mechanism. They can be seen as tags that a principal must hold in order to make some action - as calling a method - that expects that tags. There is no sense in changing or adding roles at runtime. What you probably need is to relate roles together through User Groups, which most realm implementations let you change, add and remove at runtime as you wish.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 12:50 AM
in response to: the_burrito
|
|
|
Adding and removing roles at Runtime works fine.
For now the applications has two roles, called "user" and "administrator". Users are granted access only to the user part of the web interface, and an administrator has access to everything.
If for some reason someone decides, that there should be an additional role (e.g. an administrator that can only a part of the application), the application can create this role.
But someone that is associated with this role, wants to login, he can't because the DD for the web-app only accepts the roles "user" and "administrator". So in order to integrate a new role into the application, it seems that I have to redeploy the whole application, just to grant users associated with the new role, access to the web interface. This doesn't sound like a good approach to me.
My question was, if there is any way around this.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 4:30 AM
in response to: the_burrito
|
|
|
Try this to help out your understanding of the difference between J2EE roles and application server groups.
Create a J2EE role called "roleNeededToCallTheXYZMethod". Make the XYZ method be protected by this role.
Now create a group called administrators using Glassfish's admin console (well, OK, you create a user named fred and assign him the group administrators).
Next, using sun-ejb-jar.xml, assign the group administrators to the roleNeededToCallTheXYZMethod role.
I've picked such a preposterous name for the J2EE role to emphasize that it never changes or goes away. So you'll want to think very carefully about what that role actually represents.
Hope this helps,
Laird
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 4:40 AM
in response to: ljnelson
|
|
|
The problem isn't about EJB security. It's about Web-Auhtentication. I don't want to redeploy my application everytime a new role has to be added.
But I think I just have to differentiate between application-level roles, and container-level roles.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 5:09 AM
in response to: the_burrito
|
|
|
> I don't want to redeploy my
> application everytime a new role has to be added.
But you wouldn't ever have to add a new role, or change anything about your web application at all.
Remember: your user logs in. By virtue of authenticating, he is placed into a set of groups that you define in your container's admin console (not in your web.xml or anywhere else J2EE-ish). Want to add a new group that he's part of? Just add it to the container. Want to tie that new group to an existing J2EE role? Use your container's tools.
Cheers,
Laird
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 9:15 AM
in response to: ljnelson
|
|
|
> But you wouldn't ever have to add a new role, or
> change anything about your web application at all.
>
> Remember: your user logs in. By virtue of
> authenticating, he is placed into a set of groups
> that you define in your container's admin console
> (not in your web.xml or anywhere else J2EE-ish).
> Want to add a new group that he's part of? Just add
> d it to the container. Want to tie that new group to
> an existing J2EE role? Use your container's tools.
I'm using the new JdbcRealm, so there is no way to insert users, roles or groups using the default admin interface.
The Webapp deployment descriptor uses hardcoded rolenames, to grant access to different URLs. Currently there are two areas in the application. One is for administrative users, and the other for non-administrative users. When I create a new role, through the web-interface of my application, users associated with this role cannot access the web-app, because these new roles aren't registered in the web.xml DD which grants them access to a given URL.
For example /app/* can be accessed by users and admins, while /admin/* can only be accessed by admins. When I add a new role, I must grant this new role access to one of those URLs. Is there a way of doing this, without hardcoding it in the web-app's web.xml, and then redeploying the whole application?
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 11:56 AM
in response to: the_burrito
|
|
|
> I'm using the new JdbcRealm, so there is no way to
> insert users, roles or groups using the default admin
> interface.
If there is no way in Glassfish to update the membership of a user within a group (maybe you have to do this with the asadmin tool? Not sure), then I would personally regard that as a very severe bug. I guarantee you that what you are trying to do and failing at is a result of misunderstanding the difference between a group--an appserver construct, manageable by appserver tools dynamically--and a role--a JEE construct, not manageable at all, deliberately, by any JEE tools.
> The Webapp deployment descriptor uses hardcoded
> rolenames, to grant access to different URLs.
Yes.
> Currently there are two areas in the application. One
> is for administrative users, and the other for
> non-administrative users.
Right, and from the JEE perspective you say this sentence using roles. So in your DD do as you're doing: specify two roles: "users" and "administrators".
You are now done with the JEE-specified portion of security. Leave your DD alone from this point forward.
Your next task will be to map container users and container groups to those roles you just statically defined in your DD. You will do this using container tools that themselves have nothing to do with JEE.
> When I create a new role,
> through the web-interface of my application
You cannot, as far as I know. What you are creating is most likely either a group or a user. This is the source I think of your misunderstanding.
Another way to think of it is that a JEE role is simply not under the influence of the container at all. It is deliberately a read-only entity. You can use the container to create groups, users, and--most importantly--the bindings of groups or users to particular JEE roles defined by various applications.
Another way to put this is that your JDBC realm has nothing to do with JEE at all. It has to do with putting users into groups, and then possibly (I'm not familiar with it, personally) binding those new users and/or groups to preexisting, static JEE roles defined once at deployment time by your web application.
> users
> associated with this role cannot access the web-app,
> because these new roles aren't registered in the
> web.xml DD which grants them access to a given URL.
That is incorrect. Users cannot access this information because the "role" you are talking about above is actually a group, and you haven't bound that group to a role defined by your web application. JEE speaks roles; containers speak groups. If I'm a member of a group called powerusers on my container, and you ship me a web application in a box, how do you know what my group name is? You don't. You say, by way of your DD, "I don't know what container I'm going to run in, but hey, container, I have a role that people need to 'be in' when they access this URI." The container is now responsible for translating one or more of its groups "into" one or more of your (static) roles.
> For example /app/* can be accessed by users and
> admins, while /admin/* can only be accessed by
> admins.
Let me rephrase this pedantically so it helps you out a bit more:
"For example, /app/* can be accessed by people or groups playing the JEE role of 'users' and by people or groups playing the JEE role of 'admins', while /admin/* can only be accessed by people or groups playing the JEE role of 'admins'."
> When I add a new role, I must grant this new
> role access to one of those URLs.
This statement is false.
1. First, you can't add a new role. You can add a new group (that upon creation is not bound to any JEE role defined by any JEE application).
2. You as container administrator cannot grant a role access to anything that it isn't already defined to control. That part has already been done in your DD, which as I mentioned before, you're done with. What you said there was effectively SHOULD it EVER be the case that ANYONE is EVER mapped to the users role, then people so mapped may access the URI. Now you're done with JEE, so put on your container administrator hat. Here you have not yet actually MADE it the case that anyone ACTUALLY IS mapped to the users role.
So what you want to do is create a group called, say, adminGroup (now you're in appserver land, not JEE land), and you want to BIND that adminGroup group to the JEE role of "admins" that your webapp (statically) defines. Then you want to assign particular users to that group. These operations I can practically guarantee you to be exposed in some way shape or form dynamically by the container, particularly if you're using a database to hold the group names, the users and the bindings of those groups or users to JEE role names.
Hope this helps,
Laird
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Jan 5, 2007 2:59 PM
in response to: ljnelson
|
|
|
> users, and--most importantly--the bindings of
> groups or users to particular JEE roles
> defined by various applications.
>
I apologize if somehow I missed this, but I haven't been able to figure out how to dynamically bind users and/or groups to roles in GlassFish without modifying the deployment descriptor.
In JBoss, you would use the DatabaseServerLoginModule and supply the "rolesQuery" to dynamically get the roles for the principal.
I've checked this blog, http://blogs.sun.com/swchan/entry/jdbcrealm_in_glassfish , but no mention of binding roles to groups or directly to users, except in the deployment descriptor (sun-*.xml)
Roles should be static, but surely GlassFish lets you add/modify/remove Groups without modifying the deployment descriptor and re-deploying, right? Can someone steer me in the right direction?
Thanks in advance.
Message was edited by: bhar99328
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Jan 5, 2007 4:01 PM
in response to: bhar99328
|
|
|
The point that is being talked over here is that the roles should be pretty much a FIXED aspect of the application. Adding a role would be like adding any other functionality to the application (new EJB, new Servlet, etc.).
If your roles are not of a fine enough granularity to achieve what you want, then that is a DESIGN issue with the roles chosen.
Once roles are assigned to the application, then the container maps each role to one or more groups. Users are then associated with groups, and thereby INDIRECTLY associated with roles.
The burden of flexibility and dynamic association is placed on assigning users to groups, and this is done in the directory tier of your application (either the file realm on the app server, your User/Groups tables in a JDBC realm, or your Directory server in your LDAP realm).
Now, you can argue the that app server should be the flexible entity here, vs the directory tier. But by pushing it out in to the directoy tier, you have a much more potentially flexible approach in managing complex user <-> group/role relationships. For example, some systems add a 3rd tier: user, role, priveleges within the role. But the JEE spec had to pick something, and they chose a lowest common denominator concept of simply users and roles because any other facility can be mapped on to this simple layer.
The that mapping from "arbitrary complex policies and requirements" to "JEE user/roles" is, by definition, done outside the container.
So, if you find you're doing this "a lot", rethink the roles you're using and come up with a static set that you can then map to using the technology of your choice.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Mar 27, 2007 11:10 PM
in response to: whartung
|
|
|
>>Once roles are assigned to the application, then the container maps each role to one or more groups. Users are then associated with groups, and thereby INDIRECTLY associated with roles.
Of course. But if I want to create a new GROUP with other set of existing ROLES at runtime ?
In Glassfish, I must put "role-mapping" for the new group in DD, and ONLY in DD! And redeploy app... Right?
But I need DYNAMIC "role-mapping".
In JBoss I have that possibility, because AbstractServerLoginModule and subclasses (like DatabaseServerLoginModule) have method to manipulate roles (getRoleSets()) - and it is not necessary to put mappings in DD.
HOW can I to do the same in glassfish?
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Apr 27, 2007 11:28 AM
in response to: benbou
|
|
|
Hi all, I have the same problem as "benbou".
If there is no way to do that I'd like to know if there is another approach I can use.
Actually I'm using JBossAS but I want to move to Glassfish and that question may make this moving very difficult.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 8, 2007 6:57 AM
in response to: bagrehc
|
|
|
I have the same problem also.
I need to have dynamic set of groups and roles for each user depending of
the
selected (current) object. This is similar to the real world where one
person
have different permissions (groups and roles) depending on that where is:
own
company, shop, cinema, partner company, home, etc.
When I read the rules for GlassFish AS I see that the groups are loaded
statically only at Login (authenticateUser()) procedure (method):
String[] grpList;
// populate grpList with the set of groups to which
// _username belongs in this realm, if any
return commitUserAuthentication(_username, _password, _currentRealm,
grpList);
Can you add such functionality which is not conflicting with existing one
because when the current object is NULL we have existing situation?
In my opinion the existing Realm realization is principal, but in the real
world
we need of more practical realization where one man is the "Manager" when is
in
own company and in the same time he is "Viewer" at the museum.
Any suggestions?
--
View this message in context: http://www.nabble.com/Re%3A-Dynamic-role-handling-tf3477479.html#a10376429
Sent from the java.net - glassfish users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 7:50 AM
in response to: Miroslav Nachev
|
|
|
> I need to have dynamic set of groups and roles for each user depending of
> the
> selected (current) object. This is similar to the real world where one
> person
> have different permissions (groups and roles) depending on that where is:
> own
> company, shop, cinema, partner company, home, etc.
[...]
> Any suggestions?
This is just my opinion, but I don't see the need for dynamic groups and
roles to take care of this. As an example, imagine you're using the same
server for the sites of 'cinema' and 'museum' and both apps divide
resource access into 'user' and 'manager' roles (which represent
permissions really, and not actual entities such as users).
In the server, I would create groups cinema-user, cinema-manager,
museum-user, and museum-manager. Thus, if you own the museum, you would
be in the museum-manager and possibly cinema-user groups (and the
museum-user group as well, depending on how you want to architect things).
Then you can simply map 'museum-manager' group to 'manager' role for the
museum app, 'cinema-manager' group to 'manager' for the cinema app,
etc., and there would be no need for dynamically switching groups. While
there may be good use cases for being able to dynamically switch things
around, I prefer simplicity when it comes to security in an application.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 8:12 AM
in response to: Bobby Bissett -...
|
|
|
Hi,
I am not sure that I understand your suggestion. If I am login with some
user which is with fixed groups how this groups will be changed when I
am on different objects?
Imagine that the application is looking like Windows Explorer where the
left side is one Tree, and the right side is a table. You select an
object cinema "Metropolitan" which extends Company where you are the
boss. So, in this case you must to have "cinema-manager" group and
rights. Then you select another cinema "Multiplex" where you are just
user. In this case you must to have "cinema-user" group and rights. Both
cinemas are children of parent Cinema which extends Company for example.
The same with another type of objects like museums, warehouses, etc.
How this will be realized with your suggestion?
Regards,
Miro.
Bobby Bissett - Javasoft wrote:
>> I need to have dynamic set of groups and roles for each user
>> depending of
>> the
>> selected (current) object. This is similar to the real world where one
>> person
>> have different permissions (groups and roles) depending on that where
>> is:
>> own
>> company, shop, cinema, partner company, home, etc.
> [...]
>> Any suggestions?
>
> This is just my opinion, but I don't see the need for dynamic groups
> and roles to take care of this. As an example, imagine you're using
> the same server for the sites of 'cinema' and 'museum' and both apps
> divide resource access into 'user' and 'manager' roles (which
> represent permissions really, and not actual entities such as users).
>
> In the server, I would create groups cinema-user, cinema-manager,
> museum-user, and museum-manager. Thus, if you own the museum, you
> would be in the museum-manager and possibly cinema-user groups (and
> the museum-user group as well, depending on how you want to architect
> things).
>
> Then you can simply map 'museum-manager' group to 'manager' role for
> the museum app, 'cinema-manager' group to 'manager' for the cinema
> app, etc., and there would be no need for dynamically switching
> groups. While there may be good use cases for being able to
> dynamically switch things around, I prefer simplicity when it comes to
> security in an application.
>
> Cheers,
> Bobby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 10:29 AM
in response to: Miroslav Nachev
|
|
|
>
> I am not sure that I understand your suggestion. If I am login with some
> user which is with fixed groups how this groups will be changed when I
> am on different objects?
What I'm suggesting is that you never change the groups. Instead, you
have a group for each specific situation. Now I understand that you're
talking about one application, not separate ones. So you could have a
large group users, and smaller groups cinema-manager, museum-manager, etc.
> Imagine that the application is looking like Windows Explorer where the
> left side is one Tree, and the right side is a table. You select an
> object cinema "Metropolitan" which extends Company where you are the
> boss. So, in this case you must to have "cinema-manager" group and
> rights. Then you select another cinema "Multiplex" where you are just
> user. In this case you must to have "cinema-user" group and rights. Both
> cinemas are children of parent Cinema which extends Company for example.
> The same with another type of objects like museums, warehouses, etc.
> How this will be realized with your suggestion?
Groups: users, metropolitan-manager, multiplex-manager, etc. A person
would be in the general user group and then also in whatever *-manager
group was appropriate. You can also have "higher level" groups such as
cinema-manager and the multiplex manager resources would only be able to
be accessed by users in groups multiplex-manager and cinema-manager.
With your idea of changing the group based on the user and resource
being accessed, you'd have to have some way to know which users have
access to what resource that didn't have anything to do with groups. In
my suggestion, the groups are finer grained and take care of all that
for you in the first place.
The dynamic idea scares me a little because you have to be very sure
there's not a way for a user to gain access s/he should not have. For
instance, principal P is only a user for resource R1 but is a manager
for resource R2. So, when accessing R2, if you change P to be in a
generic "manager" group, there could be some way for P to access R1 as a
manager if you're not careful. In a web application, for instance, this
would be as simple as accessing R2 and then pasting the R1 url into the
browser before doing any other action that would cause him to be removed
from the manager group. Your application sounds different, but I just
wanted to give an example of the worst case scenario.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 10:35 AM
in response to: Bobby Bissett -...
|
|
|
|
|
The static groups are not the solution for my application because I don't
know in advance how many cinemas will be entered, what will be their names,
the relation between Users and Cinemas, and etc.
Your solution is not close to the real world situations. Your solution is
private case of the common situations in the world and is not suitable for
my applications.
Maybe I have to return to JBoss where this can be realized?
Why you do private case as principals instead to implements the real world
situations which can solve private cases also?
Miro.
On 5/15/07, Bobby Bissett - Javasoft <Robert.Bissett@sun.com> wrote:
>
> >
> > I am not sure that I understand your suggestion. If I am login with some
> > user which is with fixed groups how this groups will be changed when I
> > am on different objects?
>
> What I'm suggesting is that you never change the groups. Instead, you
> have a group for each specific situation. Now I understand that you're
> talking about one application, not separate ones. So you could have a
> large group users, and smaller groups cinema-manager, museum-manager, etc.
>
> > Imagine that the application is looking like Windows Explorer where the
> > left side is one Tree, and the right side is a table. You select an
> > object cinema "Metropolitan" which extends Company where you are the
> > boss. So, in this case you must to have "cinema-manager" group and
> > rights. Then you select another cinema "Multiplex" where you are just
> > user. In this case you must to have "cinema-user" group and rights. Both
> > cinemas are children of parent Cinema which extends Company for example.
> > The same with another type of objects like museums, warehouses, etc.
> > How this will be realized with your suggestion?
>
> Groups: users, metropolitan-manager, multiplex-manager, etc. A person
> would be in the general user group and then also in whatever *-manager
> group was appropriate. You can also have "higher level" groups such as
> cinema-manager and the multiplex manager resources would only be able to
> be accessed by users in groups multiplex-manager and cinema-manager.
>
> With your idea of changing the group based on the user and resource
> being accessed, you'd have to have some way to know which users have
> access to what resource that didn't have anything to do with groups. In
> my suggestion, the groups are finer grained and take care of all that
> for you in the first place.
>
> The dynamic idea scares me a little because you have to be very sure
> there's not a way for a user to gain access s/he should not have. For
> instance, principal P is only a user for resource R1 but is a manager
> for resource R2. So, when accessing R2, if you change P to be in a
> generic "manager" group, there could be some way for P to access R1 as a
> manager if you're not careful. In a web application, for instance, this
> would be as simple as accessing R2 and then pasting the R1 url into the
> browser before doing any other action that would cause him to be removed
> from the manager group. Your application sounds different, but I just
> wanted to give an example of the worst case scenario.
>
> Cheers,
> Bobby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 10:46 AM
in response to: Miroslav Nachev
|
|
|
> The static groups are not the solution for my application because I
> don't know in advance how many cinemas will be entered, what will be
> their names, the relation between Users and Cinemas, and etc.
Ah, in that case you're right, my idea will definitely not work for you.
For your situation, I'm not sure what to tell you, so maybe someone else
can chime in. I don't know of a way in glassfish to update groups/roles
dynamically, but there may be another way to dynamically configure
permissions during runtime since all the resources are not known at startup.
> Why you do private case as principals instead to implements the real
> world situations which can solve private cases also?
Sorry, I don't think I understand the question.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 15, 2007 11:32 PM
in response to: Bobby Bissett -...
|
|
|
|
|
[att1.html]
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 16, 2007 11:56 AM
in response to: Miroslav Nachev
|
|
|
> JDBC Realm this can be realized very easy. So, my question is is it
> possible to retrieve or to receive the invoker EnterpriseBean?
> The best variant will be if in the JavaEE 5 Security this method looks:
> * getGroupNames(String username, EnterpriseBean targetObject)*
> The existing getGroupNames can be specified as follow:
> * getGroupNames(String username)
> {
> **getGroupNames(**username, null**);*
> * }
I'm not aware of anything like this, since the groups are mapped to
roles statically without other information such as beans (the mappings
are scoped to the whole application). This could be an interesting RFE
if you'd like to file it.
Asking around the security team, it was suggested that you can do what
you'd like by writing a custom policy module that modifies the required
privileges to match the resource, or that adds additional privilege
attributes to the access control context/protection domain (based on the
target resource) used in the policy evaluation.
Or you could write a server auth module that adds additional privilege
attributes based on the target resource (which would likely be simpler),
but this approach could be problematic if the same credentials are used
on a request to another resource.
I think you're already having another thread about jsr 196 (writing your
own auth module), but you can get more details from
http://jcp.org/en/jsr/detail?id=196.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 17, 2007 1:20 AM
in response to: Bobby Bissett -...
|
|
|
Hi Bobby,
> I'm not aware of anything like this, since the groups are mapped to
> roles statically without other information such as beans (the mappings
> are scoped to the whole application). This could be an interesting RFE
> if you'd like to file it.
Yes, I can try to do that. Do you have any requirements or templates how
to looks the document?
How can I submit this in jsr 196? Or where to send?
If I do some reference implementation where to send it?
At the moment the problem that I don't know how to resolve is how to
pass the invoker EnterprsieBean to the Realm in method getGroupNames?
Best Regards,
Miroslav Nachev
Bobby Bissett - Javasoft wrote:
>> JDBC Realm this can be realized very easy. So, my question is is it
>> possible to retrieve or to receive the invoker EnterpriseBean?
>> The best variant will be if in the JavaEE 5 Security this method looks:
>> * getGroupNames(String username, EnterpriseBean targetObject)*
>> The existing getGroupNames can be specified as follow:
>> * getGroupNames(String username)
>> {
>> **getGroupNames(**username, null**);*
>> * }
>
> I'm not aware of anything like this, since the groups are mapped to
> roles statically without other information such as beans (the mappings
> are scoped to the whole application). This could be an interesting RFE
> if you'd like to file it.
>
> Asking around the security team, it was suggested that you can do what
> you'd like by writing a custom policy module that modifies the
> required privileges to match the resource, or that adds additional
> privilege attributes to the access control context/protection domain
> (based on the target resource) used in the policy evaluation.
>
> Or you could write a server auth module that adds additional privilege
> attributes based on the target resource (which would likely be
> simpler), but this approach could be problematic if the same
> credentials are used on a request to another resource.
>
> I think you're already having another thread about jsr 196 (writing
> your own auth module), but you can get more details from
> http://jcp.org/en/jsr/detail?id=196.
>
> Cheers,
> Bobby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Filing RFE?
Posted:
May 17, 2007 11:39 AM
in response to: Miroslav Nachev
|
|
|
[changed subject line from "Dynamic role handling"]
>> I'm not aware of anything like this, since the groups are mapped to
>> roles statically without other information such as beans (the mappings
>> are scoped to the whole application). This could be an interesting RFE
>> if you'd like to file it.
> Yes, I can try to do that. Do you have any requirements or templates how
> to looks the document?
> How can I submit this in jsr 196? Or where to send?
> If I do some reference implementation where to send it?
I'm not sure what the official way would be. I think this would be an
RFE for the EE 6 spec. You could start by filing an enhancement request
(just choose ENHANCEMENT instead of ISSUE) at the GlassFish site, and at
least it would be tracked. There is also a comments email address at
http://jcp.org/en/jsr/detail?id=313, but someone else may have a better
suggestion.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 16, 2007 2:25 PM
in response to: Bobby Bissett -...
|
|
|
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:
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
}
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.
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
May 17, 2007 1:13 AM
in response to: whartung
|
|
|
|
|
[att1.html]
|
|
|
|
|
|
|
|
|
Re: Dynamic role handling
Posted:
Sep 11, 2006 8:28 AM
in response to: the_burrito
|
|
|
EJB security and web authorization are about the same thing in the JEE world. The only difference is that the former places security constraints on methods and the last places constraints on URLs. Other than that, they work the same way for roles.
To achieve the desired behaviour you will need at least three conceptual components: roles, groups and users. The roles are the static part - there aways must be one someplace, right? Put them on every url you wish to protect and give them names related to the url you are putting them. You will end up will as much roles as protected urls in your app. This is not a requisite, but it will give you the maximum runtime flexibility one can get if it is definitivelly a must for you.
Now you can group them in user groups and assing these to users, all of this at runtime.
|
|
|
|
|
|
|
|
|
Re: application-level roles, and container-level roles
Posted:
Sep 11, 2006 8:32 AM
in response to: charlesabreu
|
|
|
To allign understanding with spec terms, these notions can be refactored as groups and roles.
Note that the specification only define roles. Groups are implementation specific.
|
|
|
|
|
java.net RSS
