Hi Charles, thanks for you help.
what if the memory-realm was configured in the context.xml for the
application? then it should only be available to that particular
app...? I'm currently working on a mock to see if I can get this to
work, if something as simple as defining the memoryrealm and the client
adding http auth headers will be turned into a principal by tomcat
available to my code, then it's all good. but things are never that
simple...
Does anyone know what circumstances have to be true for tomcat to run
the request against the memoryrealm and create a Principle? The access
control will all be happening inside my code (well, in database access
code more precisely), my dilemma is how to turn HTTP or SOAP headers
into role names and where to store all that...
thanks for the security filter link, I'll check it out and see if it
meets our needs.
* Matthew Kerle
* * IT Consultant *
* Canberra, Australia*
Mobile: +61404 096 863
Email: Matthew Kerle <mailto:[EMAIL PROTECTED]>
Web: Matthew Kerle <http://threebrightlights.blogspot.com/>
Caldarale, Charles R wrote:
From: Matthew Kerle [mailto:[EMAIL PROTECTED]
Subject: tomcat memory realms & tomcat-users.xml
I've read the tomcat docs on memory realm:
http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#MemoryRealm,
and I want to expose the org.apache.catalina.UserDatabase
class to the web service context via a <ResourceLink...>.
You probably don't want to do that (even if it's possible, which I
doubt), since all code in the webapps would then have access to the
credentials.
I'd like to be able to authenticate users without having
to add a <security-constraint> to my web.xml, so that
unauthenticated clients can still connect.
URL patterns in the <security-constraint> allow you to control which
portions of the webapp are accessible to unauthenticated users. If you
want something with finer granularity, a filter is probably appropriate.
Take a look at:
http://securityfilter.sourceforge.net/
for a popular one.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
