-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Louis,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkdt67EACgkQ9CaO5/Lv0PCxWgCfTrpnpbtbocP5XFna6akX9hNM UIIAoJwGgxGIL/wkVscAeh47g2rjk2RQ =simi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
