> -----Original Message----- > From: Donald Ball [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 4:58 PM > To: [EMAIL PROTECTED] > Subject: Re: getting list of usernames > > > On Tue, 2002-07-09 at 15:19, Arved Sandstrom wrote: > > > > we're writing a webapp which requires access control for various > > > operations. we wish to rely on the servlet container to handle > > > authenticating users, but we need to internally associate > > > usernames with > > > sets of permissions. to make things easy on the superuser, we > > > would like > > > to acquire a list of usernames in a given role instead of > > > requiring her > > > to enter each username manually. i can find no way in the > servlet spec > > > to do this. does anyone have any suggestions? > > > > > > - donald > > > > Have you considered rethinking the architecture of your web > application? The > > existing mechanism is suitable for doing what you want to do, if you > > consider that each of the "operations" to be authorized is > actually a web > > resource. What you're doing at the moment is completely > bypassing this > > available mechanism, and recreating an EJB-style > authorization mechanism. > > > > Just a thought. > > and potentially a good one, but i don't think it works in this case. i > think you are suggesting that we design a nice urlspace for our > application, e.g.: > > /admin/[category]/add/... > /admin/[category]/edit/... > > and limit access to these protected urls either by listing the allowed > users for each url in the deployment descriptor or by defining a role > for each url and associating the allowed users with their roles using > whatever mechanism the servlet container provides. is this > more or less > what you suggest? > > there are two problems with that approach: > > 1. the burden for managing user's permissions is shifted from a > superuser using the webapp to the servlet container's administrator > > 2. categories can be added at run-time; they're not all known at > deployment-time. your suggestion would, i think, require > someone to edit > the deployment descriptor and possibly create a new role or > set of roles > every time a new category was added. none of those things can > be done by > the webapp itself; they would require manual intervention. > > given this, it seemed more appropriate to us to simply require that a > user be in a single role (e.g. mywebapp_user) to use the > webapp, and to > augment the username with webapp-specific permissions inside > the webapp > itself. > > i welcome any additional thoughts on this matter; we're by no means > entirely satisfied our solution, especially since we can't > seem to get a > list of users in a role without manually querying the data source the > servlet container is using.
You've correctly summarized what I was getting at, and you've also correctly identified the drawbacks. It's useful to have that alternative on the table. And if the drawbacks are unacceptable then your proposal is justified. Just out of curiosity, why do you need the list of users in the given role? After all, the authorization decisions will be made on a per-request basis depending on the currently authenticated user, based on the role of that user, and the servlet API will certainly furnish that information. The programmatic security in the servlet API exemplified by isUserInRole() is the fallback to declarative security, after all, designed for the situation that you find yourself in. Am I missing something? Regards, Arved ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
