Re: Form based authentication in tomcat with struts

[Adam Hardy]

On 03/04/2004 09:28 PM Edd Dawson wrote:
Now what i want to be able to do is have my servlet automatically log
them in as the register without the need for them to be redirected to
the login-form and re-enter their username and password.
I am presuming this is possible as i log my users out by invoking
request.getSession().invalidate(); in my logoff servlet, so my question
is how do i create their session without using the default login form?
There's nothing built-in to allow this in the servlet spec or in tomcat. 
Sorry. I've heard of it being done, but not by any nice or easy methods.

Adam
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Form-Based Authentication and Struts

[Craig R. McClanahan]

On Wed, 30 Oct 2002, [utf-8] Etienne Labonté wrote:

> Date: Wed, 30 Oct 2002 10:35:45 -0500
> From: "[utf-8] Etienne Labonté" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List (E-mail)" <[EMAIL PROTECTED]>
> Subject: Form-Based Authentication and Struts
>
> Hi,
>
> Is there any relation to be made between Tomcat Form-Based Authentication
> and Struts?

They can be used together, but there is no direct relationship other than
the ability to specify a "roles" attribute on an  element, to
limit the users that can execute a particular Action to those with one of
the listed roles.

> The Tomcat admin webapp seems to be based on Struts and uses
> Form-Based Authentication.

That is correct.  It uses the standard container-managed security
facilities provided by Tomcat (or any other servlet container).

> But it looks like it is not using Struts to
> handle the login form. On the other hand, the Struts-example webapp uses
> Struts for this task and has nothing about security defined in its web.xml
>

The reason for that is that most people, when the originally download
Struts, need a test app to see if everything works correctly.  If we used
container-managed security in the test app, we'd have to document how to
set up an appropriate user for every possible servlet container (and there
are quite a lot of them, each with their own procedures for this).

In retrospect, I sort of wish I hadn't illustrated application-managed
security like this, because I generally recommend that people use
container managed security for their webapps.  But, lots of people still
prefer to roll their own, so at least they've got a reasonable example of
that as well ...

> Etienne Labonté

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Form-based Authentication using Struts

[Matt Raible]

Yes, please see below:

  
FORM
Security

/signIn
/signInError

  

--- "Geddes, Mark (ANTS)" <[EMAIL PROTECTED]> wrote:
> Does your web.xml contain a  declaration?
> 
> 
> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]]
> Sent: 30 July 2001 12:53
> To: [EMAIL PROTECTED]
> Subject: Form-based Authentication using Struts
> 
> 
> I am implementing form-based authenication and have a couple of questions.
> 
> I have all my JSP's setup so they can be accessed with no extension.  I am
> also
> using a DefaultAction class so these JSP's can be accessed via a .do
> extension.
> 
> Can you send me ideas on how you implemented form-based authentication with
> struts and the .do extension?
> 
> Here are the my entries in web.xml:
> 
> 
>   
> action
> *.do
>   
> 
>   
>   
>   LDAPSecurity
>   LDAP-controlled Security
>   /*.do
>   GET
>   POST
>   
> 
>   
>   no description
>   Employees
>   
> 
>   
>   no description
>   NONE
>   
>
> 
> Should this work?  I can't seem to get it to.
> 
> Thanks,
> 
> Matt
> 
> __
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> 
> ***
> This email message contains confidential information for the above addressee
> only.  If you are not the intended addressee you must not disclose or use the
> information in any manner whatsoever.
> 
> Any opinion or views contained in this email message are those of the sender,
> do not represent those of the Company in any way and reliance should not be
> placed upon its contents.
> 
> Unless otherwise stated this email message is not intended to be
> contractually binding.  Where an Agreement exists between our respective
> companies and there is conflict between the contents of this email message
> and the Agreement then the terms of that Agreement shall prevail.
> 
> Abbey National Treasury Services plc. Registered in England. Registered
> Office:  Abbey House, Baker Street, London NW1 6XL.  Company Registration No:
> 2338548.  Regulated by the SFA
> ***


__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

RE: Form-based Authentication using Struts

[Geddes, Mark (ANTS)]

Does your web.xml contain a  declaration?


-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]]
Sent: 30 July 2001 12:53
To: [EMAIL PROTECTED]
Subject: Form-based Authentication using Struts


I am implementing form-based authenication and have a couple of questions.

I have all my JSP's setup so they can be accessed with no extension.  I am
also
using a DefaultAction class so these JSP's can be accessed via a .do
extension.

Can you send me ideas on how you implemented form-based authentication with
struts and the .do extension?

Here are the my entries in web.xml:


  
action
*.do
  

  

LDAPSecurity
LDAP-controlled Security
/*.do
GET
POST



no description
Employees



no description
NONE

   

Should this work?  I can't seem to get it to.

Thanks,

Matt

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


***
This email message contains confidential information for the above addressee only.  If 
you are not the intended addressee you must not disclose or use the information in any 
manner whatsoever.

Any opinion or views contained in this email message are those of the sender, do not 
represent those of the Company in any way and reliance should not be placed upon its 
contents.

Unless otherwise stated this email message is not intended to be contractually 
binding.  Where an Agreement exists between our respective companies and there is 
conflict between the contents of this email message and the Agreement then the terms 
of that Agreement shall prevail.

Abbey National Treasury Services plc. Registered in England. Registered Office:  Abbey 
House, Baker Street, London NW1 6XL.  Company Registration No: 2338548.  Regulated by 
the SFA
***

RE: Form-based Authentication

[Abraham Kang]

Hi Jon,

   I know that WebLogic gets rid of these after authentication.

--Abraham

> -Original Message-
> From: Jon.Ridgway [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 13, 2001 1:51 AM
> To: [EMAIL PROTECTED]
> 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  of the  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
> > >
> > >
> >
> >
>

RE: Form-based Authentication

[Craig R. McClanahan]

On Wed, 13 Jun 2001, Jon.Ridgway wrote:

> 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?
> 

Umm, which version of Tomcat does that?  It's certainly *not* in the
servlet spec.

The best way to understand exactly what you can expect to be portable is
to read the appropriate portion of the spec itself (it's only a page or
two in the Security chapter).  You can download it from:

  http://java.sun.com/products/servlet/download.html

You can use a JSP page (in all it's glory) as your form login page if you
want to, with no problems -- as long as the form action is
"j_security_check" and the input fields are "j_username" and
"j_password".  You can not count on anything related to session attributes
that the container itself might or might not create.

The only portable way to detect whether someone has successfully logged on
with any of the container-managed security mechanisms is to call
request.getRemoteUser() and make sure you got a non-null return.  Form
based is different from BASIC in one respect, though -- your authenticated
identity lasts only until the current session is invalidated or times
out.  With BASIC, the authenticated identity lasts until the browser is
restarted.

> Jon.
> 

Craig McClanahan

RE: Form-based Authentication

[Jon.Ridgway]

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 platformThe 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...




MySecureBit0
no description
/control/placeorder
POST
GET


no description
gold_customer
customer


no description
NONE



FORM
default

formbasedloginscreen
formbasedloginerrorscreen





-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 s

Re: Form-based Authentication

[Jonathan Asbell]

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  of the  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
> > >
> > >
> >
> >
>

RE: Form-based Authentication

[Jon.Ridgway]

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  of the  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
> >
> >
> 
> 

RE: Form-based Authentication

[Craig R. McClanahan]

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  of the  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
> >
> >
> 
> 

RE: Form-based Authentication

[Kurt Olsen]

I've used form-based auth with the JBoss server and mySql.
After passing authorization, the users url aims at a struts application.
I don't use struts, scriptlets, javascript or anything else on my login page
due to fear that a 'failure' of some kind would manage to confuse things and
possibly bypass security. I haven't had time to learn what I can get away
with
on the login page thus have played it safe.

The JBoss server/Tomcat 3.2 combination is working well as my personal
development tool and doesn't have any problems with struts that I know of.

Later,
Kurt


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 12, 2001 1: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  of the  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

RE: Form-based Authentication

[Abraham Kang]

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?

Sincerely,
Abraham

> -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  of the  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
>
>

RE: Form-based Authentication

[Craig R. McClanahan]

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  of the  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

RE: Form-based Authentication

[Abraham Kang]

Title: RE: Form-based Authentication



Hi 
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.
 
    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  
of the  element of your web.xml 
matches all of your protected resources.
 
--Abraham

  -Original Message-From: Jason Chaffee 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 12, 2001 4:20 
  PMTo: '[EMAIL PROTECTED]'Subject: RE: 
  Form-based Authentication
  Hi Matt and Abraham, 
  I would like to know why you say that you need to specify a 
  login-form that does not have j_security-check as its action?  

  I am using this as the action and using Struts action classes 
  to do the login? 
  -Original Message- From: 
  Abraham Kang [mailto:[EMAIL PROTECTED]] 
  Sent: Tuesday, June 12, 2001 4:25 PM To: [EMAIL PROTECTED] Subject: RE: 
  Form-based Authentication 
  Hi Matt, 
     I have done this successfully with WebLogic 6.0 
  and 5.1 and JRun 3.1. 
     Here is what I learned. 
     If you need to do login preprocessing you will 
  need to specify a login-form that does not have 
  j_security_check as its action.  This login form 
  will submit to non-secured servlet.  This servlet will do the 
  pre-processing and then forward the j_username and j_password 
  to j_security_check. 
     If you need post authentication routines then you 
  will have to sniff the session attribute that the 
  requested URL was stored under.  In WebLogic this is "_wl_formauth_url".  When they get to the login page you will 
  need to replace this attribute("_wl_formauth_url") 
  with the post-processing servlet URL.  At the 
  same time you will need to store the original value of session 
  attribute ("_wl_formauth_url") to some other key in the 
  session that the post-processing servlet can use to 
  redirect the user to their desired url after post 
  processing. 
  Hope This Helps, Abraham 
  > -Original Message- > 
  From: Matt Raible [mailto:[EMAIL PROTECTED]] 
  > Sent: Tuesday, June 12, 2001 3:14 PM > To: [EMAIL PROTECTED] > 
  Subject: Form-based Authentication > 
  > > Has anyone implemented 
  form-based authentication and Struts as defined by > the J2EE Blueprints? > > http://java.sun.com/j2ee/blueprints/packaging_deployment/descripto 
  > rs/index.h > 
  tml#1035772 > > If so, 
  any lessons learned from the appserver you deployed in? > > Thanks, > > Matt > > > 
  _ > Do You Yahoo!? > Get your free 
  @yahoo.com address at http://mail.yahoo.com > > 

RE: Form-based Authentication

[Jason Chaffee]

Title: RE: Form-based Authentication





Hi Matt and Abraham,


I would like to know why you say that you need to specify a login-form that does not have j_security-check as its action?  

I am using this as the action and using Struts action classes to do the login?


-Original Message-
From: Abraham Kang [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 12, 2001 4:25 PM
To: [EMAIL PROTECTED]
Subject: RE: Form-based Authentication



Hi Matt,


   I have done this successfully with WebLogic 6.0 and 5.1 and JRun 3.1.


   Here is what I learned.


   If you need to do login preprocessing you will need to specify a
login-form that does not have j_security_check as its action.  This login
form will submit to non-secured servlet.  This servlet will do the
pre-processing and then forward the j_username and j_password to
j_security_check.


   If you need post authentication routines then you will have to sniff the
session attribute that the requested URL was stored under.  In WebLogic this
is "_wl_formauth_url".  When they get to the login page you will need to
replace this attribute("_wl_formauth_url") with the post-processing servlet
URL.  At the same time you will need to store the original value of session
attribute ("_wl_formauth_url") to some other key in the session that the
post-processing servlet can use to redirect the user to their desired url
after post processing.


Hope This Helps,
Abraham


> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 3:14 PM
> To: [EMAIL PROTECTED]
> Subject: Form-based Authentication
>
>
> Has anyone implemented form-based authentication and Struts as defined by
> the J2EE Blueprints?
>
> http://java.sun.com/j2ee/blueprints/packaging_deployment/descripto
> rs/index.h
> tml#1035772
>
> If so, any lessons learned from the appserver you deployed in?
>
> Thanks,
>
> Matt
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>

RE: Form-based Authentication

[Abraham Kang]

Hi Matt,

   I have done this successfully with WebLogic 6.0 and 5.1 and JRun 3.1.

   Here is what I learned.

   If you need to do login preprocessing you will need to specify a
login-form that does not have j_security_check as its action.  This login
form will submit to non-secured servlet.  This servlet will do the
pre-processing and then forward the j_username and j_password to
j_security_check.

   If you need post authentication routines then you will have to sniff the
session attribute that the requested URL was stored under.  In WebLogic this
is "_wl_formauth_url".  When they get to the login page you will need to
replace this attribute("_wl_formauth_url") with the post-processing servlet
URL.  At the same time you will need to store the original value of session
attribute ("_wl_formauth_url") to some other key in the session that the
post-processing servlet can use to redirect the user to their desired url
after post processing.

Hope This Helps,
Abraham

> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 3:14 PM
> To: [EMAIL PROTECTED]
> Subject: Form-based Authentication
>
>
> Has anyone implemented form-based authentication and Struts as defined by
> the J2EE Blueprints?
>
> http://java.sun.com/j2ee/blueprints/packaging_deployment/descripto
> rs/index.h
> tml#1035772
>
> If so, any lessons learned from the appserver you deployed in?
>
> Thanks,
>
> Matt
>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>

RE: Form-based Authentication

[Gogineni, Pratima]

yes I did this. It works perfectly on tomcat also on resin. JRUN seems to
have some problems with this.



-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 12, 2001 3:14 PM
To: [EMAIL PROTECTED]
Subject: Form-based Authentication


Has anyone implemented form-based authentication and Struts as defined by
the J2EE Blueprints?

http://java.sun.com/j2ee/blueprints/packaging_deployment/descriptors/index.h
tml#1035772

If so, any lessons learned from the appserver you deployed in?

Thanks,

Matt


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: Form based authentication

[Craig R. McClanahan]

On Wed, 6 Jun 2001, Jon.Ridgway wrote:

> Hi,
> 
> When using form based auth the web container will under take the auth using
> the j_password & j_username supplied. So it all depends on which container
> you are using. Tomcat for example allows you to map to a database containing
> user and role info in the web.xml. You also have to specify a login and
> error page in the web.xml. 
> 
> Jon.
> 

The key issues to remember when using form-based login:

* Your login page must conform to the requirements of the servlet spec
  (i.e. must post to "j_security_check" and have fields "j_username"
  and "j_password").

* You must protect your pages with an appropriate 
  that includes an  inside.

* Don't refer to the login page itself in your application -- the
  container will simply use it automatically if the user requests
  a protected resource.

* Remember that security constraints work on the URL to which the browser
  submits (i.e. normally a "*.do").  They are not checked on a
  RequestDispatcher.forward() call.

Craig


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] 
> Sent: 06 June 2001 08:17
> To: [EMAIL PROTECTED]
> Subject: Form based authentication
> 
> 
> Hi,
> 
> Has anyone used Form based authentication? How does action
> ="j_security_check" work?
> 
> Thanks,
> Nagalli
> 
> 

RE: Form based authentication

[Jon.Ridgway]

Hi,

When using form based auth the web container will under take the auth using
the j_password & j_username supplied. So it all depends on which container
you are using. Tomcat for example allows you to map to a database containing
user and role info in the web.xml. You also have to specify a login and
error page in the web.xml. 

Jon.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] 
Sent: 06 June 2001 08:17
To: [EMAIL PROTECTED]
Subject: Form based authentication


Hi,

Has anyone used Form based authentication? How does action
="j_security_check" work?

Thanks,
Nagalli