Hi Bill,
I totally agree with you, this security model is going to be a pain
somewhere to correctly configure access rights...
As of my "solution", the real interest is that (as far as I can see) it
doesn't change at all any API : the only thing that changes is the body of
the method
SecurityConstraint[] findSecurityConstraints(HttpRequest request, Context
context) in org.apache.catalina.realm.RealmBase (starting at line 438), I
only changed the body so that it calls the new MergedConstraintBuilder
class.
In any case, the signature remains the same.
Today :
1- AuthenticatorBase gets all possible Constraints mathing the request, by
calling
SecurityConstraint [] constraints = realm.findSecurityConstraints(hrequest,
this.context); (AuthenticatorBase , l. 502)
2- RealmBase handles that request, returning an array of all the Constraints
matching the URI and the HTTP method of the request
3- AuthenticatorBase retrieves all these Constraints, cast the Request and
Response into HttpServletRequest and HttpServletResponse (l 515-525)
4- For each Constraint of the array, AuthenticatorBase asks RealmBase if the
UserDataPermission is OK
5- For each Constraint of the array, AuthenticatorBase asks RealmBase if the
AuthConstraint is OK
All that I change is what is happening in step 2 :
- RealmBase asks the new Class to retrieve an Array of matching
Constraints
- The new Class builds a fake Constraint representing all possible
AuthConstraints and UserDataConstraints for this (URI, HTTPMethod)
- It returns an array of SecurityConstraints, just like before.
The only difference is that now this array has only one (or zero) element,
but neither RealmBase neither AuthenticatorBase are aware of that.
All the remaining methods calls are just the same, they will just be faster
because there is only one Constraint in the array (and I think that if the
10 lines of code needed to cache the fake Constraints are added in this new
Class, it may really be faster and compute-time saving) .
I used that for a custom authorization framework I'm working on and it's OK
for me.
Thanks for having replied quickly (It's difficult to work seriously while
you're looking at your mail-box every minute to see if a response wasn't
posted ;-)
----- Original Message -----
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 6:00 AM
Subject: Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
> Yes, this looks like it changed between pfd3 to fr :(.
Security-constraints
> now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4
> security model all but useless.
> <whine>
> It would be natural to configure something like:
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Client Area</web-resource-name>
> <url-pattern>/clients/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <!-- Any authenticated user -->
> <role-name>*</role-name>
> </auth-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Product1 Client Area</web-resource-name>
> <url-pattern>/clients/product1/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <!-- Any product1 user -->
> <role-name>product1</role-name>
> </auth-constraint>
> </security-constraint>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Product2 Client Area</web-resource-name>
> <url-pattern>/clients/product2/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <!-- Any product2 user -->
> <role-name>product2</role-name>
> </auth-constraint>
> </security-constraint>
>
> The way the 2.4 spec is written, all authenticated users have access to
> everything under /myapp/clients/. To get what I want is now a
configuration
> nightmare :(.
> </whine>
>
> Now back to fixing things. I sort of like the idea of changing the Realm
> interface so that 'hasUserDataPermissions' and 'hasResourcePermissions'
take
> a SecurityConstraint []. However, after a GA release, this may be a bit
> much. Philippe's solution looks a bit over-kill to me, but I'm not going
to
> object if someone wants to commit it. I'm thinking of moving the
> header-setting stuff out of RealmBase and into AuthenticatorBase. It may
> cause some custom realms to stop working, but there shouldn't be that many
> for TC 5 yet :).
>
> Of course, I'm volunteering for the code-monkey (© Pier) part of
this.
> Since anyway we go is a pretty big change, I just wanted to get a
consensus
> first.
>
> Opinions, Comments, Flames?
>
> ----- Original Message -----
> From: "philippe.leothaud" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 08, 2003 6:43 PM
> Subject: Tomcat authorization handling seems not to function according to
> Servlet 2.4 Spec
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
