Hi Kirk,
Since posting that original note back in May I have found out a few things.
But firstly I should stress that I have not found anything to fail at all
- it was just that I didn't know how to do things.
So, a few pieces of information that may be of use:
- With BASIC authentication you can specify the security realm to use.
With FORM you cannot. I believe this to be a J2EE feature, not an Orion
shortcoming.
- With BASIC authentication the browser KNOWS that the application has
requested authentication (it is the browser that pops up the window). This
is important, because if another BASIC authentication request arrives from
the SAME security realm, then the browser will re-send the user/password
automatically. Thus, if you write several applications or web-applications
that all use BASIC authentication and the SAME security realm, then the
user himself will have to log-in only once to use any or all of these
applications.
- With FORM authentication, the browser does NOT know that authentication
has been requested - it simply serves the login form like any other. That
means that it cannot re-send the login information for you. It is also my
belief that the session information (in which the authentication
information is stored on the server side) cannot be shared between
different apps /web-apps. (The "shared" option refers to sharing session
information between sites that serve the SAME web-app.) This means that
users will have to log-on to every app individually.
- There is no explicit log-out mechanism built into the J2EE platform. If
you are using FORM based authentication, you can call session.invalidate()
to destroy the session (and thus the authentication information), and this
has the desired result. However, this is ineffective when using BASIC
authentication because the browser will simply resend the information when
the next request arrives. I do not know if this browser behaviour can be
prevented - except by shutting down (all) the browser window(s).
- With FORM authentication you are required to write a simple page (could
be in plain html) with a form containing a text input field for j_username,
a password input field for j_password, a submit button (of course!) and an
action for the form of action="j_security_check". What happens is that
when you request a secure resource, the J2EE container (1) remembers what
you were asking for, (2) presents your login form (as specified by the
<form-login-page> tag in web.xml), and, assuming success, (3) presents the
page that you originally requested. If the login fails then it presents
your <form-error-page> instead. (Note that you CANNOT log-in by simply
displaying your login form; you MUST trigger the J2EE container to display
it by requesting a protected page.)
- Remember that simply supplying a valid usename/password (as specified in
principals.xml) does not mean that you will be granted access to a
protected page. The page is protected by specifying the security roles
that are allowed to access it, and if the user you specify is not in one of
the required security roles, then access will still be denied. This can be
a bit confusing, because the response the user gets appears to be
indistinguishable from that she gets if the username/password is completely
invalid. The user could well think that she's simply mis-typed the password.
- Also note that usernames and passwords do not HAVE to be supplied in the
principals.xml file. The Orion team has supplied methods to obtain them
from a database or from some other system via entity beans. Check the
different user managers for these features.
I hope this helps. Since it may be of interest to others I have copied it
to a few other groups. Hope you don't mind.
Nick Newman, SCIENTECH Inc.
At 10:18 AM 6/29/00 -0400, you wrote:
>Nick:
>
>I saw a post on orion-interest on this subject matter. I'm currently
>working with the FORM authentication. What exactly happens during this
>process? What cause it to fail besides userid password in principals.xml?
>
>
>see http://www.mail-archive.com/[email protected]/msg01569.html
>
>Kirk S. Kalvar, Software Engineer
>
>DRS Electronic Systems Group
>email [EMAIL PROTECTED]
>phone 301-921-8176
