spec conform role mapping?

2002-12-16 Thread Thomas Paradies
Some days ago I'd asked the dev community about the role mapping 
behaviour of TC4.1.16 which is IMO not conform to the spec. Look at 

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg37814.html

(sorry for referencing, but it's all described in that message, so I 
won't do it again)

I got only one response which wasn't really helpful in my eyes. Ok, 
it's not an big issue like minimal JSR 154 only distribution ;-) 
and this item is only a minimal part of JSR 154 but I'm sure the 
tomcat-dev is the right place to ask again for it before rashly put 
it on bugzilla. May be I'm stupid, but I think the fact is worth 
to reissue the question:

Is the role mapping for 100 percent conform to the spec?

Thomas

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




Re: Bug or feature?

2002-12-09 Thread Thomas Paradies
Sorry for answering my own mail but I lost the thread and want to clarify 
some aspects with respect to Matts message. He wrote:
---
This means that ALL roles can access this resource. When you specify *, you
don't need to specify security-role below, but if you DO specify a role or
roles, then it is necessary to define roles. At least, this is my impression
from the specs. If you want your desired behavior, change role-name to use
specialrole.
---
Principally this sounds good and I'm aware of the solution but is this the
specified 
behaviour? Again: what are security-role definitions good for? 

And again I'll refer to the spec - see below.

Thomas Paradies wrote:
 
 Hi,
 
 I'm a little bit confused about the use of the security-role tag - generally
 and especially in Tomcat. The WebApp DTD refers for auth-constraint to this
 element commented as follows:
 
 ... The role-name used here must either correspond to the role-name of one
 of the security-role elements defined for this web application

In TC the role-name in auth-constraint isn't verified against an corresponding 
security-role definition. (test: replace * by tomcat do not define a
security-role)
This is a MUST.

 , or be the
 specially reserved role-name * that is a compact syntax for indicating all
 roles in the web application.

IMO this means that * is limited for indicating all roles in THE WEB
APPLICATION 
and should not not do this for roles in other web applications even if the share 
the same realm.

 ... If no roles are defined, no user is allowed
 access to the portion of the web application described by the containing
 security-constraint...

I understand this as a MUST. And no roles are defined relates in my eyes to 
the web application. 

Comments are welcome.

 
 I've tried to do this with Tomcat (4.1.16) but it didn't work as described.
 Tested with this web.xml (test.jsp also needed):
 
 ?xml version=1.0 encoding=ISO-8859-1?
 !DOCTYPE web-app
 PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
 http://java.sun.com/dtd/web-app_2_3.dtd;
 web-app
   servlet
 servlet-nameRoleRef/servlet-name
 jsp-file/test.jsp/jsp-file
   /servlet
   servlet-mapping
 servlet-name
   RoleRef
 /servlet-name
 url-pattern
   /test
 /url-pattern
   /servlet-mapping
   security-constraint
 web-resource-collection
   web-resource-nameWebCollection/web-resource-name
   url-pattern/test/url-pattern
 /web-resource-collection
 auth-constraint
   role-name*/role-name
 /auth-constraint
   /security-constraint
   login-config
 auth-methodBASIC/auth-method
 realm-namedefault/realm-name
   /login-config
   !-- uncommenting security-role causes nothing --
   security-role
 role-namespecialrole/role-name
   /security-role
 /web-app
 
 Only specialRole should have the permission to access the resource test.jsp,
 if uncommented no user should have this permission - but in Tomcat any role
 (e.g. tomcat, from global context) has in both cases the permission ...
 
 Is this wanted behaviour or is this a bug?
 
 Regards,
 Thomas Paradies
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Regards,
Thomas Paradies

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




Bug or feature?

2002-12-06 Thread Thomas Paradies
Hi,

I'm a little bit confused about the use of the security-role tag - generally 
and especially in Tomcat. The WebApp DTD refers for auth-constraint to this 
element commented as follows:

... The role-name used here must either correspond to the role-name of one 
of the security-role elements defined for this web application, or be the 
specially reserved role-name * that is a compact syntax for indicating all 
roles in the web application. ... If no roles are defined, no user is allowed 
access to the portion of the web application described by the containing 
security-constraint...

I've tried to do this with Tomcat (4.1.16) but it didn't work as described. 
Tested with this web.xml (test.jsp also needed):

?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
  servlet
servlet-nameRoleRef/servlet-name
jsp-file/test.jsp/jsp-file
  /servlet
  servlet-mapping
servlet-name
  RoleRef
/servlet-name
url-pattern
  /test
/url-pattern
  /servlet-mapping
  security-constraint
web-resource-collection
  web-resource-nameWebCollection/web-resource-name
  url-pattern/test/url-pattern
/web-resource-collection
auth-constraint
  role-name*/role-name
/auth-constraint
  /security-constraint
  login-config
auth-methodBASIC/auth-method
realm-namedefault/realm-name
  /login-config
  !-- uncommenting security-role causes nothing --
  security-role
role-namespecialrole/role-name
  /security-role
/web-app

Only specialRole should have the permission to access the resource test.jsp, 
if uncommented no user should have this permission - but in Tomcat any role 
(e.g. tomcat, from global context) has in both cases the permission ...

Is this wanted behaviour or is this a bug?

Regards,
Thomas Paradies

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