Christopher Schultz wrote:
Louis wrote:
When trying to decide which Authentication I should use I reviewed the
source for the existing ones and realized that none of them would work.
The existing authenticators all check to see if a principal is already
in the request. If it is then the user has already been authenticated
and the authenticator never goes to the Realm to see what permissions /
roles the user has.
That's not how it's supposed to work; authentication and authorization
are separate. Without looking at the source (don't have it handy right
now), the flow ought to be:
- - Determine authentication and authorization requirements
based upon request URL
- - Check request for principal
|- if not found, check request for credentials
| - if found, load principal into request
| - if not found, display login challenge and exit
- - Use found principal for authorization (check roles)
Tomcat's built-in Principal and Request objects conspire to correctly
wire HttpServletRequest.isUserInRole to something within the Principal.
If you choose to gather your Principal information from somewhere else
(NTLM), then you need to take care to play along with Tomcat's notion of
where roles are stored.
If Tomcat does not use the HttpServletRequest.isUserInRole method to
perform its authorization, then you will need to pay attention to the
way it /does/ check for the roles.
Since the IIS connector plugs-in a Principal for the
user, this effectively short-circuited the ability of the container to
bind roles to the user.
You should be able to wrap that Principal in some other object if necessary.
My solution was to code my own TrustedPrincipalAuthorizor (extends
AuthenticatorBase). I called it an authorizor since it wasn't doing any
actual Authentication.
Is it doing any authorization, or is it just attaching roles to a
Principal and allowing Tomcat to perform the authorization?
This class checks for the existence of a
principal in the request. It then uses that principal as the key to tell
the security realm to lookup the users permissions and bind them into
the container for this request.
That seems a little time-consuming to do for every request. Since you're
working with Tomcat's internals, why not permanently attach the role
information to the Principal object one time?
Ergo the name. The last step of the
puzzle is to make 'authenticating' (ie: checking the password) optional
in your realm. I coded my LoginModule to have a flag checkPassword="false".
I know that's not the whole picture but it's the gist of it to get a
discussion going. What do people here think, am I following a logical
path or have I completely jumped the shark?
Why not work with the code that the redirector uses to set the Principal
in the first place? I think it would be a cleaner implementation to set
the roles at the time the Principal object is created.
- -chris
Thanks Chris for the detailed response.
I'll have to go back and review how the IIS isapi_redirector.dll is
hooked into Tomcat to see if changing the redirector would better suit
my needs.
The reason why I went with this style implementation: it was the first
way I've figured out of implementing my requirements and it worked. (ie:
not a good reason architecturally, it just worked). One argument in
favour of this style of implementation is that it can work with other
external redirector implementations that embed a Principal in the Request.
I'm not sure about your question re: Is it doing any authorization? My
understanding of JAAS is that the binding of Roles to the Principal was
the Authorization. Doing this does allows the security declarations in
the web.xml to work as expected. ie: The container (tomcat/jboss/etc.)
is doing the work of checking if the user is in the role.
Yes it is time consuming to do bind the roles on every request. I'm not
sure yet how the redirector binds the Principal to the Request (per
session or per request) and/or how Roles are normally bound to the
Principal.
I'll have to go back to the Tomcat source and trace what's happening in
the Realm source.
I don't have the experience or tools to be able to create an updated
redirector. I'm trying to make an implementation that isn't specific to
the IIS redirector and could be used with other types of redirectors.
Also, I'm trying to keep my implementation 'java' and I don't know what
the redirector .dll is written in.
I see where you're going with your suggestions. If the Principal from
the redirector is created once and the same one is used across requests
(in a session) then it should be trivial to mutate it (by binding the
roles in) instead of substituting it with a new one with the roles bound in.
Thanks for taking the time to write a detailed response. I'll get back
to the list with my changes when I've got them done.
Best Regards,
Louis
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
