Re: security constraints in tomcat 4.1.30

2005-06-05 Thread Jo
Hi Angela,

Not sure why it works fine with Tomcat 5 but followings is my view to the
problem with the login page.

1. The security constraint for the images and CSS tells that the GET and
HEAD methods to these resources ARE protected.
2. When you go to the login page, as it tries to get the protected images
and stylesheet, Tomcat has to redirect the request back to the login page
again.

rgds,
Jo.-

- Original Message - 
From: Angela Stempfel [EMAIL PROTECTED]
To: tomcat-user@jakarta.apache.org
Sent: Friday, June 03, 2005 4:53 PM
Subject: security constraints in tomcat 4.1.30


 Hello all

 I have a problem concerning Tomcat 4.1.30. In web.xml i defined several
 security constraint. First of all I protected the whole application and
 then I excluded the directories with images and css files. Furthermore I
 defined some roles.

 pre
 security-constraint
 display-nameTCE GUI/display-name
 web-resource-collection
 web-resource-nameWEBGui Area/web-resource-name
 !-- Define the context-relative URL(s) to be protected --
 url-pattern/*/url-pattern
 /web-resource-collection
 auth-constraint
 !-- Anyone with one of the listed roles may access this area --
 role-name*/role-name
 /auth-constraint
 /security-constraint

 security-constraint
 web-resource-collection
 web-resource-nameImages and CSS Not Protected/web-resource-name
 url-pattern/images/*/url-pattern
 url-pattern/css/*/url-pattern
 http-methodGET/http-method
 http-methodHEAD/http-method
 /web-resource-collection
 /security-constraint

 security-constraint
 display-nameDSLAM Configuration/display-name
 web-resource-collection
 web-resource-name
 Access to DSLAM Configuration
 /web-resource-name
 url-pattern/DslamConfig/*/url-pattern
 /web-resource-collection
 auth-constraint
 role-namedslamConfig/role-name
 /auth-constraint
 /security-constraint
 login-config
 auth-methodFORM/auth-method
 form-login-config
 form-login-page/login.jsp/form-login-page
 form-error-page/login-error.jsp/form-error-page
 /form-login-config
 /login-config

 security-role
 role-namedslamConfig/role-name
 /security-role
 /pre

 So my problem is that this works fine with Tomcat 5.0 but not with
 Tomcat 4.1.30. If I go to the login page, the stylesheet and images are
 not found when running the Application with version 4.1.30. Also the
 Security Constraints are not working correctly, this means that a user
 that hasn't the role dslamConfig is able to enter the following URL:
 /DslamConfig/*

 Has anyone some ideas?

 Thanks a lot
 Angela

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 !DSPAM:429fffc716436437214267!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: security constraints in tomcat 4.1.30

2005-06-03 Thread Mark Thomas

Angela Stempfel wrote:

Hello all

I have a problem concerning Tomcat 4.1.30. In web.xml i defined several 
security constraint. First of all I protected the whole application and 
then I excluded the directories with images and css files. Furthermore I 
defined some roles.


snip

So my problem is that this works fine with Tomcat 5.0 but not with 
Tomcat 4.1.30. If I go to the login page, the stylesheet and images are 
not found when running the Application with version 4.1.30. Also the 
Security Constraints are not working correctly, this means that a user 
that hasn't the role dslamConfig is able to enter the following URL: 
/DslamConfig/*


Has anyone some ideas?


You need to read section SRV.12.8 of both the servlet 2.3 spec and the 
servlet 2.4 spec. The way constraints are handled has changed. For example,

spec-quote version=2.3
If the authorization constraint defines no roles, no user is allowed 
access to the portion of the web application defined by the security

constraint.
/spec-quote

compared to

spec-quote version=2.4
If no authorization constraint applies to a request, the container must 
accept the request without requiring user authentication.

/spec-quote

There is a fair amount of ambiguity in this area of the 2.3 spec, which 
is why it changed so much in 2.4


You should also be aware of 
http://issues.apache.org/bugzilla/show_bug.cgi?id=15570


Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: security constraints in tomcat 4.1.30

2005-06-03 Thread Bill Barker
Along with what Mark said, you should know that TC 4.1.30 stops checking 
after the *first* matching constraint (so in your case, the '/*' always 
wins).  Try reversing the order of your constraints in web.xml.

As Mark mentioned, this has changed in TC 5.x, and your web.xml should work 
as written.

Angela Stempfel [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Hello all

 I have a problem concerning Tomcat 4.1.30. In web.xml i defined several 
 security constraint. First of all I protected the whole application and 
 then I excluded the directories with images and css files. Furthermore I 
 defined some roles.

 pre
 security-constraint
 display-nameTCE GUI/display-name
 web-resource-collection
 web-resource-nameWEBGui Area/web-resource-name
 !-- Define the context-relative URL(s) to be protected --
 url-pattern/*/url-pattern
 /web-resource-collection
 auth-constraint
 !-- Anyone with one of the listed roles may access this area --
 role-name*/role-name
 /auth-constraint
 /security-constraint

 security-constraint
 web-resource-collection
 web-resource-nameImages and CSS Not Protected/web-resource-name
 url-pattern/images/*/url-pattern
 url-pattern/css/*/url-pattern
 http-methodGET/http-method
 http-methodHEAD/http-method
 /web-resource-collection
 /security-constraint

 security-constraint
 display-nameDSLAM Configuration/display-name
 web-resource-collection
 web-resource-name
 Access to DSLAM Configuration
 /web-resource-name
 url-pattern/DslamConfig/*/url-pattern
 /web-resource-collection
 auth-constraint
 role-namedslamConfig/role-name
 /auth-constraint
 /security-constraint
 login-config
 auth-methodFORM/auth-method
 form-login-config
 form-login-page/login.jsp/form-login-page
 form-error-page/login-error.jsp/form-error-page
 /form-login-config
 /login-config

 security-role
 role-namedslamConfig/role-name
 /security-role
 /pre

 So my problem is that this works fine with Tomcat 5.0 but not with Tomcat 
 4.1.30. If I go to the login page, the stylesheet and images are not found 
 when running the Application with version 4.1.30. Also the Security 
 Constraints are not working correctly, this means that a user that hasn't 
 the role dslamConfig is able to enter the following URL: /DslamConfig/*

 Has anyone some ideas?

 Thanks a lot
 Angela 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Security constraints for different contexts

2004-07-05 Thread Rahman Syed
Just wanted to ask this question again...does anyone have any ideas??  I'm 
really stuck here, any good tutorials or resources about security 
constraints would be helpful.  All of the ones I've seen online only handle 
one constraint at a time, I've never seen how they work in terms of best 
match first or otherwise.

Thanks,
Rahman
At 7/2/2004 11:47 AM, you wrote:
Hello,
I'm using Tomcat 5.0.25 and I'd like to use container-based security to 
restrict access to one specific page.  The problem is that this page 
exists in different contexts, but using the same docbase.  You can get a 
better idea by looking at the first snippet included below.

You can see that the application itself is installed by default at context 
/wiki, and there will be additional copies at /wiki/wikione and so 
on.  My goal is to restrict /wiki/Edit.jsp to one role, 
/wiki/wikione/Edit.jsp to another role, etc.  The web.xml I'm using right 
now doesn't even prompt for authentication at all; the only time I can get 
it to authorize anything is when I only have one security constraint, for 
url-pattern /Edit.jsp.

Is there an easy to way to achieve this?  Thanks...
Rahman
Server.xml snippet:
 Context path=/wiki/wikione docBase=wiki debug=0
  Parameter name=jspwiki.propertyfile 
value=C:\tomcat\webapps\wiki\WEB-INF\wikione.properties
 override=false/
 /Context


The application's web.xml snippet:
   security-constraint
   web-resource-collection
   web-resource-nameProtected Area/web-resource-name
   url-pattern/wiki/Edit.jsp/url-pattern
   http-methodDELETE/http-method
   http-methodGET/http-method
   http-methodPOST/http-method
   http-methodPUT/http-method
   /web-resource-collection
   auth-constraint
   role-namewikiadmin/role-name
   /auth-constraint
   /security-constraint
   security-constraint
   web-resource-collection
   web-resource-nameProtected Area/web-resource-name
   url-pattern/wiki/wikione/Edit.jsp/url-pattern
   http-methodDELETE/http-method
   http-methodGET/http-method
   http-methodPOST/http-method
   http-methodPUT/http-method
   /web-resource-collection
   auth-constraint
   role-namewikioneadmin/role-name
   /auth-constraint
   /security-constraint
   login-config
  auth-methodBASIC/auth-method
  realm-nameJSPWiki Editor/realm-name
   /login-config

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Security-constraints - how to forbid all except ...

2003-09-10 Thread Tim Funk
One workaround is to map EVERYTHING to a set of servlets. Then set your 
Security constraints against the servlets instead of the URL pattern.

-Tim

Chris Rolfe wrote:
Hi,

Does anyone have a way to set security constraints to forbid access to
everything (as the by default) *except* specified files + dirs?
The web.xml snippet below comes very close to doing what I want although it
relies on the order of constraints (ie, it's container-dependent).
The problem with my solution is that incomplete URI's don't have a chance to
be redirected to the welcome file. For example, mydomain.com/myservlet
hit's the SecurityConstraint[Forbidden] before being redirected to
index.jsp. 

So to rephrase the question: Is there a way to set security constraints to
forbid access to everything *except* specified files + dirs WITHOUT breaking
the site-root welcome-file redirect? Any workaround to exempt the '/'
redirect (maybe a servlet-mapping??).
Thanks,

Chris 

Tomcat 404 web.xml snippet
---
security-constraint
web-resource-collection
web-resource-namePublic/web-resource-name
url-pattern/index.jsp/url-pattern
url-pattern/public/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
web-resource-collection
web-resource-nameForbidden/web-resource-name
descriptionEverything else./description
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
http-methodDELETE/http-method
/web-resource-collection
auth-constraint
role-namenone/role-name !-- This role doesn't exist --
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
---


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: security-constraints

2002-06-11 Thread Craig R. McClanahan



On Tue, 11 Jun 2002, Dennis van den Berg wrote:

 Date: Tue, 11 Jun 2002 13:02:46 +0200
 From: Dennis van den Berg [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: security-constraints

 Hi all,

 According to the servlet 2.3 specs, the longest path-prefix is used when
 determining which servlet-mapping or which security-constraint is to be
 used.


Tomcat actually implements first matching security constraint, rather
than longest matching security constraint, so you need to swap the order
of these two in order to get what you want.

Clarifying the rules for this is under discussion for Servlet 2.4.

Craig


 However when I specify the following security-constraint's:

   security-constraint
 web-resource-collection
   web-resource-nameCollection1/web-resource-name
   url-pattern/*/url-pattern
 /web-resource-collection
 auth-constraint
   role-namerole1/role-name
 /auth-constraint
 user-data-constraint
   transport-guaranteeNONE/transport-guarantee
 /user-data-constraint
   /security-constraint
   security-constraint
 web-resource-collection
   web-resource-nameCollection2/web-resource-name
   url-pattern/view/*/url-pattern
 /web-resource-collection
 auth-constraint
   role-namerole2/role-name
 /auth-constraint
 user-data-constraint
   transport-guaranteeNONE/transport-guarantee
 /user-data-constraint
   /security-constraint

 A user which is in role2 is denied access to url's which start with /view/*, and it 
seems that the order in which I specify the security-constraint's mathers?

 Am I missing something?

 Thanks,


 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Security Constraints

2001-04-02 Thread DUDGEON

Depends on what realm you are using. Assuming you are using the default
MemoryRealm, users are defined in $TOMCAT_HOME/conf/tomcat-users.xml
If you are using JDBCRealm then it is presumably assumed that there is an
existing mechanism to manage users/passwords for your database.
If you are usign another Realm, then the chances are you have written it
yourself, so should know the answer ;-)

Tim

 -Original Message-
 From: Martin Mauri [mailto:[EMAIL PROTECTED]]
 Sent: 28 March 2001 19:52
 To: [EMAIL PROTECTED]
 Subject: Security Constraints
 
 
 Hi users!
 
 I'm trying to configure the security constraints with FORM 
 login method.
 I've defined to name the rola as "role1" but where and how do 
 I add users to
 that roles and where do I configure their passwords?
 
 regards.
 
 Martin
 
 
 Lic. Martin O. Mauri
 Profesion + Auge A.F.J.P
 Parana 666 - Cap. Federal
 TE: (011) 4373-7786/7 int: 422
 [EMAIL PROTECTED]
 www.profesi.com.ar
 


--
DISCLAIMER: This message contains proprietary
information some or all of which may be
confidential and/or legally privileged. It is for
the intended recipient only who may use and apply
the information only for the intended purpose.
Internet communications are not secure and
therefore the British Biotech group does not
accept legal responsibility for the contents of
this message. Any views or opinions presented are
only those of the author and not those of the
British Biotech group. If you are not the intended
recipient please delete this e-mail and notify the
author immediately by calling ++44 (0)1865 748747;
do not use, disclose, distribute, copy, print or
rely on this e-mail.