We have a situation where we may have several forms of login -
a password, possibly some witness password and some biometric
stuff. So our customer could configure the system so that you
have to do a fingerprint scan plus type in the password. We
are looking at JAAS, some of the app servers are addressing it
also.
>From: Jeff Schnitzer <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Is LoginServlet bad practice?
>Date: Wed, 31 Jan 2001 20:14:03 -0800
>
>So, to make form-based authentication work, I need to have one page
>which simultaneously acts as a) my root page (marked as secure), b) the
>"you need to log in first" page, and c) the login failed page. This
>page needs to figure out which of the three states it is in and display
>(at least in my case) wholly different content. Yuck.
>
>Don't get me wrong; I really like the role-based security J2EE offers,
>but the form-based login process is seriously deficient.
>Membership-based sites are a common pattern, so there is no reason we
>should have to resort to ugly hacks like the one suggested. I would
>rather manage my own authentication with a jsp and a JavaBean since the
>code is much cleaner. Also, I can automatically log in newly created
>accounts without forcing them back to the login screen (yet another
>deficiency).
>
>Yes, my "bold statement" was intended to be flippant :-)
>
>Jeff
>
> >-----Original Message-----
> >From: Bono, Chris [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, January 31, 2001 3:45 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Is LoginServlet bad practice?
> >
> >
> >>>1) Provide a login page. Every membership-oriented site on
> >>>the internet
> >>>provides a login form on their front page (e.g. www.aol.com,
> >>>www.hotmail.com). Form-based login only lets you
> >>>authenticate when you
> >>>transition to a protected page.
> >
> >You can get around this issue by having your login page
> >actually be that front page and have it initially invoked.
> >
> >>>2) Allow the user to try again on the "bad password" page. The user
> >>>must hit "back" on their browser (or click on another link that takes
> >>>them to the protected page).
> >
> >And this one by having the "bad password" page to be that same page.
> >The user won't know what is going on behind the scenes.
> >
> >
> >>>Umm, maybe because J2EE security services SUCK? :-)
> >
> >That is a bold statement considering security is one of the
> >key features of J2EE.
> >I am curious to hear others opinions on this issue.
> >
> >Chris
> >
> >>>-----Original Message-----
> >>>From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> >>>Sent: Wednesday, January 31, 2001 5:18 PM
> >>>To: [EMAIL PROTECTED]
> >>>Subject: Re: Is LoginServlet bad practice?
> >>>
> >>>
> >>>Umm, maybe because J2EE security services SUCK? :-)
> >>>
> >>>Somebody didn't really think out the specification very well.
> >>>Form-based login is a step up from boring old http
> >authentication, but
> >>>it doesn't go nearly far enough. You can't:
> >>>
> >>>1) Provide a login page. Every membership-oriented site on
> >>>the internet
> >>>provides a login form on their front page (e.g. www.aol.com,
> >>>www.hotmail.com). Form-based login only lets you
> >>>authenticate when you
> >>>transition to a protected page.
> >>>
> >>>2) Allow the user to try again on the "bad password" page. The user
> >>>must hit "back" on their browser (or click on another link that takes
> >>>them to the protected page).
> >>>
> >>>The form-based login might work ok for an e-commerce app, where
> >>>authentication is only required on the transition to the
> >>>checkout page,
> >>>but the web is a lot more than just that. This deficiency
> >in the j2ee
> >>>spec is the only reason I have any server-dependent code in my app at
> >>>all.
> >>>
> >>>Jeff
> >>>
> >>>>-----Original Message-----
> >>>>From: Dave Wolf [mailto:[EMAIL PROTECTED]]
> >>>>Sent: Wednesday, January 31, 2001 9:28 AM
> >>>>To: [EMAIL PROTECTED]
> >>>>Subject: Re: Is LoginServlet bad practice?
> >>>>
> >>>>
> >>>>But why write a line of code when J2EE security services
> >>>>provide this all to
> >>>>you.
> >>>>
> >>>>Dave Wolf
> >>>>Internet Applications Division
> >>>>Sybase
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Rahman, Zahid" <[EMAIL PROTECTED]>
> >>>>To: <[EMAIL PROTECTED]>
> >>>>Sent: Wednesday, January 31, 2001 12:03 PM
> >>>>Subject: Re: Is LoginServlet bad practice?
> >>>>
> >>>>
> >>>>> Not my opinion,
> >>>>>
> >>>>> With regard to internal staff changing the servlet ?
> >>>>>
> >>>>> For instance what you are going to do if the staff take
> >>>you physical
> >>>>machine
> >>>>> then what you going to do ?
> >>>>>
> >>>>> Interesting point though. Not much you can do when the
> >>>>servlet methods are
> >>>>> specified and common to all servlets Not much you can do ?
> >>>>>
> >>>>> The key point here is internal staff changing code ?
> >>>>>
> >>>>> Regards
> >>>>> Zahid
> >>>>> > -----Original Message-----
> >>>>> > From: Bono, Chris [SMTP:[EMAIL PROTECTED]]
> >>>>> > Sent: Wednesday, January 31, 2001 3:30 PM
> >>>>> > To: [EMAIL PROTECTED]
> >>>>> > Subject: Re: Is LoginServlet bad practice?
> >>>>> >
> >>>>> > Why not use J2EE security?
> >>>>> >
> >>>>> > -----Original Message-----
> >>>>> > From: Carlos Otero Barros
> >[mailto:[EMAIL PROTECTED]]
> >>>>> > Sent: Wednesday, January 31, 2001 8:31 AM
> >>>>> > To: [EMAIL PROTECTED]
> >>>>> > Subject: Is LoginServlet bad practice?
> >>>>> >
> >>>>> >
> >>>>> > Hi All!
> >>>>> >
> >>>>> > Recently I have been envolved in a discussion about the
> >>>>convenience of
> >>>>> > encapsulating login process in a separate servlet. Namely
> >>>>LoginServlet.
> >>>>> > My opinion is this is a bad practice from a security
> >>>point of view.
> >>>>> > Internal personel could substitute the LoginServlet with
> >>>any other
> >>>>> > simple servlet with the same methods() and take the
> >>>whole web site
> >>>>> > unsecured.
> >>>>> >
> >>>>> > Your opinion?
> >>>>> >
> >>>>> > Thanks
> >>>>> >
> >>>>> >
> >>>>===============================================================
> >>>>===========
> >>>>> > =
> >>>>> > To unsubscribe, send email to [EMAIL PROTECTED] and
> >>>>include in the
> >>>>> > body
> >>>>> > of the message "signoff EJB-INTEREST". For general help,
> >>>>send email to
> >>>>> > [EMAIL PROTECTED] and include in the body of the
> >>>>message "help".
> >>>>> >
> >>>>> >
> >>>>===============================================================
> >>>>===========
> >>>>> > =
> >>>>> > To unsubscribe, send email to [EMAIL PROTECTED] and
> >>>>include in the
> >>>>> > body
> >>>>> > of the message "signoff EJB-INTEREST". For general help,
> >>>>send email to
> >>>>> > [EMAIL PROTECTED] and include in the body of the
> >>>>message "help".
> >>>>>
> >>>>>
> >>>>===============================================================
> >>>>============
> >>>>> To unsubscribe, send email to [EMAIL PROTECTED] and
> >>>>include in the
> >>>>body
> >>>>> of the message "signoff EJB-INTEREST". For general help,
> >>>>send email to
> >>>>> [EMAIL PROTECTED] and include in the body of the
> >>>message "help".
> >>>>>
> >>>>>
> >>>>
> >>>>===============================================================
> >>>>============
> >>>>To unsubscribe, send email to [EMAIL PROTECTED] and
> >>>>include in the body
> >>>>of the message "signoff EJB-INTEREST". For general help,
> >>>send email to
> >>>>[EMAIL PROTECTED] and include in the body of the message "help".
> >>>>
> >>>>
> >>>
> >>>==============================================================
> >>>=============
> >>>To unsubscribe, send email to [EMAIL PROTECTED] and
> >>>include in the body
> >>>of the message "signoff EJB-INTEREST". For general help,
> >>>send email to
> >>>[EMAIL PROTECTED] and include in the body of the message "help".
> >>>
> >
> >===============================================================
> >============
> >To unsubscribe, send email to [EMAIL PROTECTED] and
> >include in the body
> >of the message "signoff EJB-INTEREST". For general help, send email to
> >[EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".