Hi Jonathan,
Snip from....
http://java.sun.com/j2ee/blueprints/packaging_deployment/descriptors/index.h
tml#1035772
....
'Form-based authentication is the preferred mechanism for authenticating
application users in the J2EE platform....The security-constraint element
specifies that the URL /control/placeorder is a protected resource. The
login-config element specifies that the URL formbasedloginscreen will be
displayed when an unauthenticated user tries to access /control/placeorder.
This page contains an HTML form that prompts for a user name and password.'
The HTML form must have an action='j_security_check' and j_password and
j_username input fields. The container will then take care of logging the
user in...No Java code required...
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureBit0</web-resource-name>
<description>no description</description>
<url-pattern>/control/placeorder</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>no description</description>
<role-name>gold_customer</role-name>
<role-name>customer</role-name>
</auth-constraint>
<user-data-constraint>
<description>no description</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>default</realm-name>
<form-login-config>
<form-login-page>formbasedloginscreen</form-login-page>
<form-error-page>formbasedloginerrorscreen
</form-error-page>
</form-login-config>
</login-config>
-----Original Message-----
From: Jonathan Asbell [mailto:[EMAIL PROTECTED]]
Sent: 13 June 2001 13:42
To: [EMAIL PROTECTED]
Subject: Re: Form-based Authentication
Hi Jon. i was reading about this form based auth, and I wondered if you
could explain some things to me. Is form based auth just a combination of
an element declared by the web.xml and a line or two in the java code?
----- Original Message -----
From: "Jon.Ridgway" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 4:51 AM
Subject: RE: Form-based Authentication
> Hi All,
>
> Form based auth is something that I have just been looking at, so I
thought
> I'd add my two pennies worth.
>
> My login form is using struts html, bean and template tags (no html:form)
> and all appears ok. My template has an adapted version of the checkLogin
tag
> provided with the struts-example. My adapted version just checks that a
user
> attribute is in the session and creates one if it is not using the
> j_username and j_password to look the users' details up in my db.
>
> Question: can I be sure that *all* containers will put a j_username and
> j_password attribute in the session, like tomcat does?
>
> Jon.
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 13 June 2001 02:05
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Form-based Authentication
>
>
>
> On Tue, 12 Jun 2001, Abraham Kang wrote:
>
> > Hi Craig,
> >
> > Thanks for the clarification.
> >
> > I was wondering if you knew of any other way to do pre-processing
> > before being authenticated and post-processing after authentication
> > when using the form based authentication.
> >
> > Would filters work here?
> >
>
> Maybe.
>
> The reason that the spec is so specific about "j_security_check" is to
> provide containers lots of leeway in *how* they implement form based login
> -- as long as they conform to the requirements that are listed, they can
> do what they want. For example, Tomcat 4 recognizes the
> "j_security_check" as the clue it needs to replay the *original* request,
> so that the "j_security_check" request itself never goes through the
> filter chain.
>
> You'd be a lot better off in a servlet 2.3 environment by using
> application event listeners to notice session creations, so that you can
> (for example) mark the session as needing some special handling on the
> next incoming request -- that, of course, being the only time you know
> who the authenticated user really is. Of course, in a nice MVC framework
> (like Struts :-), the actual processing to be performed can be easily
> delegated to the controller servlet.
>
> > Sincerely,
> > Abraham
> >
>
> Craig McClanahan
>
>
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, June 12, 2001 4:59 PM
> > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > Subject: RE: Form-based Authentication
> > >
> > >
> > >
> > >
> > > On Tue, 12 Jun 2001, Abraham Kang wrote:
> > >
> > > > RE: Form-based AuthenticationHi Jason,
> > > >
> > > > I should have been clearer.
> > > >
> > > > The only time that you do not want the login-form to specify
> > > > "j_security_check" as its action is when you want to do some special
> > > > preprocessing before the user is authenticated. By forwarding
> > > to a servlet
> > > > (I haven't tried this with an Action but it should work) you can do
> your
> > > > preprocessing in the servlet and then do a
> > > requestDispatcher.forward( ) to
> > > > j_security_check. This will allow you to do pre-processing and take
> > > > advantage of the containers authentication realm.
> > > >
> > >
> > > WARNING: Although it might be supported by some containers, you are
> *not*
> > > guaranteed by the servlet spec that you can portably play that sort of
a
> > > game. The spec clearly states that the form login page *must* have an
> > > action of "j_security_check". (I haven't tried it, but I'm pretty
sure
> > > your technique would not work on Tomcat.)
> > >
> > > > My guess is you are currently doing authentication against
> > > a database
> > > > table. If you are using WebLogic you can use the DBMSRealm. This
> will
> > > > probably mean you will need to add some tables to support the roles
in
> > > > WebLogic but now you don't need the authentication code in your
> actions.
> > > > The container manages access to protected resources. You don't
> > > have to have
> > > > any scriptlets at the top of your pages as long as the regular
> > > expression in
> > > > the <url-pattern> of the <security-constraint> element of your
web.xml
> > > > matches all of your protected resources.
> > > >
> > >
> > > Tomcat supports a similar mechanism -- you can configure lookup of
users
> > > in a flatfile, in a database, or in a directory server. Each
container
> > > will provide it's own mechanisms for defining how and where users and
> > > roles can be stored.
> > >
> > > > --Abraham
> > >
> > > Craig McClanahan
> > >
> > >
> >
> >
>
