RE: Security Realm Limitations (More on protecting PDF documents. )

["Turner, John" <JT...@AAS.com>]

This is probably off-topic, but why would you want to do this on the
application server level?  How will you handle changes to the server.xml or
web.xml file?  What if there is an error/typo in that file after a change?
Will you have to stop/start tomcat for the changes to take effect?

Seems to me the better long-term solution would be to handle access control
programmatically in your application.  Keep track of users, groups, and
group memberships in a database...that way changes are instantly live and
you can easily restrict or delegate permissions for managing user accounts
and permissions to non-admin, non-root users.

John Turner
jturner@NOSPAM.aas.com
http://www.aas.com


-----Original Message-----
From: Brad Rhoads [mailto:brhoads@zethcon.com]
Sent: Friday, June 28, 2002 4:07 PM
To: 'Tomcat Users List'
Subject: Security Realm Limitations (More on protecting PDF documents.)



I've determined that I can use security realms to protect PDF documents.
(See http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html if you
happen to be getting started on this problem).

I need to be able to give access to one set of pdfs to one group of users,
and to different sets for other groups of users. It looks like I can
accomplish this much by creating separate directories for each group and
setting up a role for each group. But I have two related problems left:

1. The same PDF may be available to multiple groups. It seems that I would
have to maintain duplicate copies of the PDFs, one for each group.

2. This group level security provides the base list of available PDFs. I
need to be able to take away access to documents from certain users within a
group.

Suggestions? Or better yet examples?




--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Security Realm Limitations (More on protecting PDF documents.

[br...@zethcon.com]

> 
> This is probably off-topic, but why would you want to do this on the
> application server level?  How will you handle changes to the
> server.xml or web.xml file?  What if there is an error/typo in that
> file after a change? Will you have to stop/start tomcat for the changes
> to take effect?
> 
> Seems to me the better long-term solution would be to handle access
> control programmatically in your application.  Keep track of users,
> groups, and group memberships in a database...that way changes are
> instantly live and you can easily restrict or delegate permissions for
> managing user accounts and permissions to non-admin, non-root users.
> 


I want to do it programmaticlly! In fact I am in my JSPs - just check for 
a session var & redirect to the logon page if it's not there. But how do I 
protect non-jsp pages, like PDFs without using the security realm?

> John Turner
> jturner@NOSPAM.aas.com
> http://www.aas.com
> 
> 
> -----Original Message-----
> From: Brad Rhoads [mailto:brhoads@zethcon.com]
> Sent: Friday, June 28, 2002 4:07 PM
> To: 'Tomcat Users List'
> Subject: Security Realm Limitations (More on protecting PDF documents.)
> 
> 
> 
> I've determined that I can use security realms to protect PDF
> documents. (See
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html if you
> happen to be getting started on this problem).
> 
> I need to be able to give access to one set of pdfs to one group of
> users, and to different sets for other groups of users. It looks like I
> can accomplish this much by creating separate directories for each
> group and setting up a role for each group. But I have two related
> problems left:
> 
> 1. The same PDF may be available to multiple groups. It seems that I
> would have to maintain duplicate copies of the PDFs, one for each
> group.
> 
> 2. This group level security provides the base list of available PDFs.
> I need to be able to take away access to documents from certain users
> within a group.
> 
> Suggestions? Or better yet examples?
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>