On Mon, 18 Feb 2002, Mark R. Diggory wrote:
> Date: Mon, 18 Feb 2002 20:20:43 -0500
> From: Mark R. Diggory <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Realms and User Sessions.
>
> >
> >
> >
> >I assume you are talking about Tomcat 4, right?
> >
> Yes.
>
> >
> >If so, there is no way for the Realm itself to reference the user's
> >session -- all a Realm knows how to do is answer the "is this user
> >authorized" and "does this user have the right role" type questions.
> >
> >If you want to modify the state of the current request or session, you
> >should really be looking at subclassing one of the existing Authenticator
> >classes, instead of trying to do that in the Realm. The Authenticator has
> >complete access to the current request, so you can get the session via:
> >
> > HttpSession session =
> > ((HttpRequest) request.getRequest()).getSession();
> >
> >Don't forget to put the classes for the objects you might create into
> >common/lib so that they are visible to both Catalina and your webapp.
> >
> >
> >Craig
> >
> Well, I learn something new every day....
>
> So, let me see if I have this correct.
>
> 1.) I define a <valve> pointing to my custom authentication class in my
> server.xml (in my webapps context).
>
> <Context path="/VDC" docBase="VDC" debug="0" reloadable="true">
> <Valve className="edu.harvard.hmdc.authenticator.VdcAuthenticator"
> debug="0"/>
> </Context>
>
> 2.) Dump my files into tomcat/common to support that valve.
> 3.) Then define any security constraints required by my webapp in its
> web.xml file.
>
> <security-constraint>
> <display-name>Administration Pages</display-name>
> <web-resource-collection>
> <web-resource-name>Protected Area</web-resource-name>
> <!-- Define the context-relative URL(s) to be protected -->
> <url-pattern>/Administration/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <!-- Anyone with one of the listed roles may access this
> area -->
> <role-name>administrators</role-name>
> <role-name>curators</role-name>
> </auth-constraint>
> </security-constraint>
> <!-- Default login configuration uses form-based authentication -->
> <login-config>
> <auth-method>FORM</auth-method>
> <realm-name>Example Form-Based Authentication Area</realm-name>
> <form-login-config>
> <form-login-page>/Authority/login.jsp</form-login-page>
> <form-error-page>/Authority/error.jsp</form-error-page>
> </form-login-config>
> </login-config>
>
>
> After this any security constraints should activate the
> Valve/Authenticator and not a Realm for authentication? How does Tomcat
> know which Authenticator to use?
>
The Authenticator is chosen based on which <login-method> you select. One
of the four Authenticator valves will be selected automatically, based on
the mapping in the Authenticator.properties file in the
o.a.c.authenticators package.
> Just make sure, does this still in any way require the use of a Realm class?
There still needs to be a Realm that actually looks up users in a
database, but the choice of Realm is orthagonal to the choice of
Authenticator -- any combination of the two is valid. As with a standard
Tomcat install, the Realm can be either directly associated with a
Context, or inherited from the owning Host or Engine.
>
> -Mark
>
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
