[OT] Re: ACL (access control list) tutorial or example

[Pid <p...@pidster.com>]

David Kerber wrote:
> Pid wrote:
> 
>> David Kerber wrote:
>>
>>>
>>> ...
>>>
>>>> There isn't a standard way of doing programmatical security of this 
>>>> nature - the nature of it is such that you have to write it yourself.
>>>
>>>
>>> That is essentially what I'm trying to do, using various built-in 
>>> tools , such as java.security.acl.*, sun.security.acl.AclImpl, 
>>> sun.security.acl.AclEntryImpl, sun.security.acl.PermissionImpl, etc.  
>>> I'm just having trouble figuring out how these tools are intended to 
>>> be used
>>
>>
>> I wouldn't start there when securing a web application, but other list 
>> members might.  Sounds like the long route to a solution.
>>
>> The spec defines role based access control; the majority of your 
>> problem can be resolved by configuring a Realm and your app so that 
>> restrictions can be applied on a URL by URL basis.
> 
> In addition to the response I just posted, this app only has about 5 
> different url's (.jsp's), only one of which is restricted to admin 
> users. 

You can secure any path, including a file URL.
Are you submitting forms to servlets or JSPs?

If you're submitting to servlets (ie separating your logic from your 
views) then it makes it easier to write specific checks for specific users.

> The permissions are to specify which site's information they are 
> able to view on the site information .jsp, and whether or not they can 
> modify that information, not what .jsp they can get to in the first place.

How are you currently determining which data to display, a URL parameter 
that specifies the userid/username?

p




> Dave
> 
> 
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 

Re: [OT] Re: ACL (access control list) tutorial or example

[David Kerber <dc...@verizon.net>]

Pid wrote:

>>>> ...
>>>>
>>>>> There isn't a standard way of doing programmatical security of 
>>>>> this nature - the nature of it is such that you have to write it 
>>>>> yourself.
>>>>
>>>>
>>>>
>>>> That is essentially what I'm trying to do, using various built-in 
>>>> tools , such as java.security.acl.*, sun.security.acl.AclImpl, 
>>>> sun.security.acl.AclEntryImpl, sun.security.acl.PermissionImpl, 
>>>> etc.  I'm just having trouble figuring out how these tools are 
>>>> intended to be used
>>>
>>>
>>>
>>> I wouldn't start there when securing a web application, but other 
>>> list members might.  Sounds like the long route to a solution.
>>>
>>> The spec defines role based access control; the majority of your 
>>> problem can be resolved by configuring a Realm and your app so that 
>>> restrictions can be applied on a URL by URL basis.
>>
>>
>> In addition to the response I just posted, this app only has about 5 
>> different url's (.jsp's), only one of which is restricted to admin 
>> users. 
>
>
> You can secure any path, including a file URL.
> Are you submitting forms to servlets or JSPs?

servlets.

>
> If you're submitting to servlets (ie separating your logic from your 
> views) then it makes it easier to write specific checks for specific 
> users.

That's good to know.

>
>> The permissions are to specify which site's information they are able 
>> to view on the site information .jsp, and whether or not they can 
>> modify that information, not what .jsp they can get to in the first 
>> place.
>
>
> How are you currently determining which data to display, a URL 
> parameter that specifies the userid/username?

No, the user ID information is set in session attributes, and then they 
go to a .jsp that allows them to select from a list of sites to which 
they have access, then one which allows them to specify the date they 
want to see, and then they finally get to the data display form.  The 
fields on this page are either editable or not, depending on what their 
permission level is for the site they are looking at.  The information 
is all carried along in the session object. as they went from screen to 
screen..

Dave



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org