tomcat memory realms tomcat-users.xml

2007-08-15 Thread Matthew Kerle

Hi all

I'm developing a web service with xFire 1.2.3 / tomcat 5.5.23 / Java 
1.6.0_01, and we need to authenticate access by client applications 
coming in over SOAP. We're looking at using the tomcat-users.xml file to 
store user/pwd/role data until the customers Single Sign-On service is 
ready (which will be when pigs fly, if it keeps going as it has).


The application will be deployed internally so we don't need any SSL or 
digest authentication, we're looking at simple HTTP BASIC or SOAP 
headers  for the client to pass through their auth details. The 
complication is that we want to allow default access as well as 
authenticated access, and authenticate against the tomcat-users file.


eg - un-authenticated clients can still access the web service url, but 
get a public role, and authenticated clients get a privileged role.


I'm thinking we might be able to do part of that with the following 
tomcat-users.xml config by having an empty user declaration:


tomcat-usersc
 role rolename=privileged/
 user name=  password= roles=PUBLIC  /
 user name=priv_user1  password=tomcat roles=privileged  /
/tomcat-users

The question is how to authenticate against the tomcat-user database? 

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 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.


Am I on the right track? Or is there a much easier way than what I'm 
trying to do...


thanks!

--
* Matthew Kerle
* * IT Consultant *
* Canberra, Australia*

Mobile: +61404 096 863
Email: Matthew Kerle mailto:[EMAIL PROTECTED]
Web:  Matthew Kerle http://threebrightlights.blogspot.com/ 
http://threebrightlights.blogspot.com/



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



RE: tomcat memory realms tomcat-users.xml

2007-08-15 Thread Caldarale, Charles R
 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]



Re: tomcat memory realms tomcat-users.xml

2007-08-15 Thread Matthew Kerle

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]