I have not used it before either but
am expected to on my current project. Any and all information would
be appreciated, the more detailed the better.
-Jason
"Scott P. Smith"
<ssmith@scott-smith.com>
03/16/2004 12:54 PM
Please respond to
ajug-members@ajug.org
To
ajug-members@ajug.org
cc
Subject
Re: [ajug-members]: User
authentication in web app
Rob & Chandra,
That's great information. Thanks.
At my last job, we had pages where different parts of the page had
different permissions associated with them. So two different people
with different roles would see different options on the page. Some
roles could just view certain data while other roles could edit. We
chose to use entirely custom logon/authentication with our own custom
tag library that would hide or show portions of the page based on the
user's role. Of course, the back end (we used struts) would also
check
the user's permissions against the action he was trying to perform.
Can container managed security handle this kind of sub-page level access
control?
I can image that struts could display a different page, based on the
user's role, but I don't think it could do that back when I was using it
(3 years ago).
I have never used container managed security so I'm picking your brains,
while I have the chance.
Thanks,
Scott
On Tue, 2004-03-16 at 12:35, Chandra Polaku wrote:
> There is an excellent article on form based
> authenticaton that explains how to integrate the
> existing password persistence store to the form based
> authentication
>
> http://www.onjava.com/pub/a/onjava/2002/06/12/form.html
>
> -Chandra
> --- Rob Kischuk <rkischuk@gttx.org> wrote:
> > That isn't the case at all. Look at
> > http://java.sun.com/dtd/web-app_2_3.dtd
> >
> > We have a snippet from our web.xml:
> >
> > <login-config>
> > <auth-method>FORM</auth-method>
> > <realm-name>SSORealm</realm-name>
> > <form-login-config>
> > <form-login-page>/login.do
> > </form-login-page>
> > <form-error-page>/loginFail.do
> > </form-error-page>
> > </form-login-config>
> > </login-config>
> >
> > This code directs any authentication against
> > SSORealm to use form based
> > authentication, and allows configuration of the
> > login and login failure
> > screens. In our case, we use struts actions that
> > forward to tiles
> > templates that completely match the look and feel of
> > our web
> > applications. There are 4 options for auth-method -
> > BASIC (clear-text
> > dialog box), DIGEST (encrypted dialog box, limited
> > portability), FORM
> > (described above), and CLIENT-CERT (uses client
> > verisign-type
> > certificate for auth). With the exception of
> > DIGEST, these approaches
> > are all completely portable.
> >
> > -Rob
> >
> > Scott P. Smith wrote:
> >
> > >I can't help but join in with a question:
> > >
> > >Can custom form based authentication be integrated
> > with container
> > >managed security? I guess the answer varies by
> > container, which
> > >translates into non-portable code. I can't stand
> > the standard
> > >browser-supplied pop ups asking for user/pw. I
> > think it looks
> > >unprofessional.
> > >
> > >Scott
> > >
> > >On Tue, 2004-03-16 at 11:03, Rob Kischuk wrote:
> > >
> > >
> > >>What I'm saying is that if you use J2EE's built-in
> > security, you don't
> > >>need to do much of anything other than configure
> > how you log in and what
> > >>your login page looks like. Everything else is
> > set up in deployment
> > >>descriptors, and the code that the vendor has
> > written is called to do
> > >>the dirty work. For session timeout, you should
> > set a value for that
> > >>and allow the web container to expire the session
> > for you. The default
> > >>behavior if the password changes or you revoke
> > their permissions is that
> > >>they remain logged in until their session ends.
> > If you want different
> > >>behavior, it's not hard to get a list of sessions
> > from the servlet
> > >>context and manipulate their session, but
> > generally this isn't a common
> > >>or critical scenario.
> > >>
> > >>The challenge here is to stop thinking about the
> > whole thing as code
> > >>you're going to write. There is a great deal of
> > this functionality
> > >>built into the J2EE app servers, and you can
> > harness a ton of code
> > >>that's already been written, and then add minor
> > extensions to meet your
> > >>needs. Less is more here.
> > >>
> > >>-Rob
> > >>
> > >>Christopher Fowler wrote:
> > >>
> > >>
> > >>
> > >>>So you are saying that I need to authenticate the
> > user against the
> > >>>database once and the session id is the cookie.
> > I can then invalidate the
> > >>>cookie after 30minutes. What happens if I change
> > the users password
> > >>>before the cookie times out? Or revoke the
users
> > permissions?
> > >>>
> > >>>Chris
> > >>>On Tue, Mar 16, 2004 at 09:24:39AM -0500, Rob
> > Kischuk wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>It will check the session. Once the user
has
> > authenticated, it loads
> > >>>>the authenticated identity and privileges into
> > the session on the server
> > >>>>side, and gives the user a cookie (or it can
> > rewrite the URL) as a
> > >>>>session identifier for the user. For the
rest
> > of the session, it trusts
> > >>>>the information in the session (this is safe
to
> > do). Some app servers
> > >>>>may allow you to re-verify security on each
> > request, but generally the
> > >>>>user is authenticated once at the beginning of
> > the session, and that's
> > >>>>it - this is all that's usually necessary, and
> > avoids the performance
> > >>>>penalty of checking for each request - this
> > wouldn't scale well on a
> > >>>>high-traffic site. If you need the ability
to
> > kick a user out the
> > >>>>moment their privileges are revoked, it would
be
> > simple to add code to
> > >>>>invalidate any sessions belonging to a user that
> > you are removing as a
> > >>>>part of your user management pages, but usually
> > this isn't a huge concern.
> > >>>>
> > >>>>-Rob
> > >>>>
> > >>>>Chris Fowler wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>So what you are saying is that the security
> > container will check the
> > >>>>>user database for each access. The
select
> > statement was just an
> > >>>>>example. I would not have used it without
> > checking username first.
> > >>>>>
> > >>>>>
> > >>>>>On Tue, 2004-03-16 at 08:58, Rob Kischuk
wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>I would recommend using J2EE Container
Managed
> > Security. While there
> > >>>>>>are certain circumstances where it is
> > inadequate, it is usually useful
> > >>>>>>to at least authenticate your users.
Most
> > J2EE app servers are moving
> > >>>>>>toward using JAAS to fulfill the
> > authentication needs, meaning you can
> > >>>>>>flexibly switch between using a flat
file for
> > your username/password to
> > >>>>>>a database to LDAP without ever rewriting
your
> > code. Parameters can
> > >>>>>>usually be set to add encryption to your
> > passwords. This security
> > >>>>>>approach also lets you switch authentication
> > methods easily - from
> > >>>>>>dialog boes to web based forms. A
very light
> > overview can be found
> > >>>>>>here:
> >
> >>>>>>http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security4.html#67530.
> > If
> > >>>>>>someone has a link to a better resource,
it
> > would be excellent.
> > >>>>>>
> > >>>>>>The security is declarative, meaning
that you
> > tell the servlet container
> > >>>>>>which pages should be secure, and what
"roles"
> > should have access to
> > >>>>>>them. In your case, it sounds like
you have
> > really only one role that
> > >>>>>>you want to enforce, so you could simply
> > configure your entire web app
> > >>>>>>to be restricted to users in the role
"user".
> > Then, in your security
> > >>>>>>database, just make sure each user is
assigned
> > this role (the structure
> > >>>>>>of the database will vary based on your
needs
> > and app server
> > >>>>>>requirements. For some app servers,
you could
> > probably configure the
> > >>>>>>role query as "select 'user' from
dual" and
> > dispense with the need for a
> >
> === message truncated ===
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
>
>