----- Original Message ----
From: Tim Wood <timwood0@(protected)>
To: Jerry Osmeña <jcosmena@(protected)>
Sent: Friday, December 30, 2005 5:32:32 PM
Subject: Re: Role based Access


At 02:12 PM 12/30/05, Jerry Osmeña wrote:
>><sec:hasPermissions permissions = "<comma-separated list of roles>">
>><... your button, link, tiles coded here>
>></sec:hasPermissions>
>
>>Does this technique prevent the user from hand-crafting and submitting the URLs that have been filtered by the hasPermissions tag? If so, the security is illusory unless the functions behind the URLs also check. If the functions do check, then filtering at the page level just adds some obscurity which may not be worth the complexity.
>
>You see, this is Java Custom Tag. At the end of generation of the page, the url or the link won't be in the page if the role of the user does not meet the criteria of the permission tag. In fact, the user won't even know the url if he has not allowed to access it.
>The absence of a link does not prevent a user from visiting the URL the link would reference if the link was >there. The URL may have a dynamic, unguessable component, which would make it infeasible for the user to >guess it. If the URLs are fixed strings, though, then you're relying on obscurity to say "the user won't even know >[it]".
Regardless of URL being dynamic or not, as long as you have security in place for authentication, that issue will be handle by the application properly. To elaborate, one strategy being used in this type of security is using web filters as front controller. All pages or links that should be secured must go to this filter and the filter authenticate the user trying to access the page. If it passed authentication, then it delegate its control to the application framework (either Struts, Spring, Tapestry, etc). Authorization is another part of security and I believe this is what Kalra is asking.

Authorization can be manage is so many ways. One of it is to only show to the user a part or section of the page he has control(e.g. Admin can be allow to add, edit and view user but a normal user is only allowed to view its profile). In this case, some part or button in the same page its using might not be available for the normal user when he reach on that page. The same is true to some links that might be accessible to particular user of the application. Based on its role, they may or not be allowed to access the links. In this kind of situation, the strategy I discussed above is applicable since it uses the role of the user which is retrieve after authentication to know whether the user has access or not. Also, doing it using custom tag, makes the pages and code cleaner and readable to the developer.

>Since it is a java custom tag, just want to mention that the developer will be coding on how to fetch the role of the user (normally, this is stored in session) and compare it to the list of roles passed in the tag as parameters.
>Unless the application code (or an aspect layer in front of it) checks the roles in the session against those >required for the function or URLs are dynamic & unguessably random, the markup-filter approach can be >bypassed by guessing the URL to the protected function.

>TW

The markup-filter will never be bypassed by this approached since this works hand in hand with that. Markup-filter approach, correct me if i'm wrong, will be used to authenticate the user while this approach supplement it by authorizing the user after it has been authenticated.
I hope I was able to convey this clearly.

Jerry

===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".