> Let me get this straight on how it works.
>
> If I wanted to give out a URL to access my site and I was using CMA then I
> could give out http://whatever.com/login.do as the URL and the container
> would see that the user is not logged in and through them to the login
page
> (specified in the web.xml for form based auth) and if that form posted to
> j_security_check, if successful auth, then they would be sent to login.do
> and in there I would just load up preferences and do whatever and in there
> forward to a personalized page etc?
As long as /login.do is protected (matches a url pattern that you must be
authenticated to view) it will do as you describe. The end of the auth
sequence would be a redirect to /login.do.
>
> But if they tried to access the site with whatever.com/somethingElse.do
(and
> not currently authenticated) then they would be asked to authenticate
> automatically at that point and then sent to somethingElse.do if auth was
> successful?
Yes, they would go through the authentication sequence and then end up at
/somethingElse.do.
This is really fantastic from a user experience standpoint. Anyone can
bookmark just about any page they want in the site and CMA will do
just-in-time authorization. People can email each other URLs, other sites
can link to pages in the site, etc. This is a great thing! But, you can't
bookmark the login form page, and your app can't do any processing upon
authentication.
However, a filter could be used to implement nearly equivalent functionality
on the processing-at-auth-time front. It would be
processing-at-next-request-after-auth in the lingo I've been using here.
Here's a simple little filter that will do this (the code is not 100%
complete, but it is quite nearly so):
public class ProfileFilter implements Filter {
public void doFilter(...) {
boolean userIsAuthenticated = (request.getUserPrincipal() != null);
boolean profileIsPresent =
(request.getSession().getAttribute(Profile.SESSION_KEY) != null);
if (userIsAuthenticated && !profileIsPresent) {
Profile profile = new Profile(request.getUserPrincipal());
request.getSession().setAttribute(Profile.SESSION_KEY, profile);
}
chain.doFilter(request, response);
}
}
Then declare it in your web.xml and provide an all-inclusive /* mapping to
it. Be sure to put its mapping after the SecurityFilter mapping so that
request.getUserPrincipal() will work if you are using this with
SecurityFilter. The order of the mappings in web.xml determines the order in
which the filters will be called when a request matches more than one
mapping. This filter will work with CMA also.
SecurityFilter addresses the login-page-bookmarkability issue, and we will
have some explicit support for the processing-at-authentication-time issue
at some point in the future (but no support is there right now). Processing
at authentication time is perhaps the most requested feature.
Someone emailed me a suggestion for how to support processing at
authentication time. Apparently the Resin container has an interface/class
that you can implement/extend and then register with the container to have
your processing method called when someone authenticates. This method is
called with a reference to the session so that you could put profile info in
there, etc. This is a cool idea. I don't know any other containers that have
such a thing. It would be great if something like this made it into the
Servlet spec.
The other alternative that I was considering is that you could register a
URI for a resource that would do the processing. SecurityFilter would
authenticate the user, and then forward to the specified resource for
additional processing. The request would be forwarded with a wrapped (or
entriely new) response that would ignore (think > /dev/null) anything that
was written or changed in the response. SecurityFilter would regain control
after the processing finishes, and it would redirect the user to the default
page or wherever it was that they were going. This is nice because we don't
have to define any new interfaces (yeah!), but the part where it ignores the
response is rather confusing (boo!).
I am leaning toward the Resin-style solution for this. If anyone has
opinions on how this should be done, I would love to hear them. Pro/con
comments about the solutions described above, or completely new ideas are
welcome.
>
> So now if you could only direct me to a reference for getting CMA to work
> with JRun and Objectivity (I've read the docs out there and I must be
> missing a small detail for implementing custom login and I have no support
> contract from JRun). The login module stuff isn't hard it is configuring
> the custom User Manager that is so poorly documented.
I wish I could help, but I am not familiar with JRun/Objectivity CMA
configuration.
-Max
>
> TIA
>
>
>
> -----Original Message-----
> From: Max Cooper [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 6:44 PM
> To: Struts Users Mailing List
> Subject: Re: CMA and LoginAction
>
> CMA does just-in-time authentication. You will only be authenticated on
the
> way to viewing a protected resource. After your authentication succeeds,
you
> will end up at the protected resource that you originally requested. This
is
> very nice because logging in doesn't take the user off the course of what
> they were trying to achieve.
>
> But, it also means that you can't have users login at will, or issue an
> "unsolicited" login request by randomly posting to j_security_check.
> Actually, you can support this a bit by having the "Login" link take you
to
> a protected resource, which will force the CMA to do the authentication
> routine along the way. Your protected resource might just redirect you
back
> to the home page or something if that is what you want. You can't have a
> login form on every page, though, because the container won't know where
to
> send them after they are logged in. This limitation also creates problems
if
> users bookmark the login form page.
>
> This is one of the reasons I started the Security Filter project. It
allows
> "unsolicited" login requests, and you can configure where users should be
> sent if they issue an "unsolicited" login request. It also supports
> just-in-time authentication like CMA, which is how it will work if
Security
> Filter initates the authentication sequence in response to a request for a
> protected resource.
> http://securityfilter.sourceforge.net/
>
> -Max
> looking for lots of securityfilter hits today ;-)
>
>
> ----- Original Message -----
> From: "Bailey, Shane C." <[EMAIL PROTECTED]>
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Sent: Friday, June 06, 2003 7:28 AM
> Subject: RE: CMA and LoginAction
>
>
> >
> > This makes me think of another question. I have put implementing my CMA
> on
> > hold but I will need to know this soon:
> >
> > If you specify where to go prior to the CMA j_security_check call (by
> > describing the login form in the web.xml) why don't you have to describe
> the
> > "success" page (most likely an action) to go to as well? So where does
a
> > successful CMA auth take you?
> >
> > I am guessing it goes to the welcome page also described in the web.xml?
> >
> > Anyway, if that is the case can you have your welcome page be
> > "userInitialize.do" ??? That would work right?
> >
> >
> > BTW, we started using Objectivity and JRun has LoginModules provided for
> > LDAP,Relational and XML storage and not oodb. I tried to write a custom
> > LoginModule (not really a problem) and a customer User manager class and
> it
> > hasn't worked. Anyone successful in such things?
> >
> >
> >
> > -----Original Message-----
> > From: Mohan Radhakrishnan [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 06, 2003 10:15 AM
> > To: 'Struts Users Mailing List'
> > Subject: CMA and LoginAction
> >
> > Hi
> >
> > I would like to use role based authentication. That is CMA. Now I
> > also want to call my Action class. The idea is to use
> >
> > <logic:present role="name"/>
> >
> > My Action class sets up user profiles based on the login ID etc. Is
this
> > possible ?
> >
> > Mohan
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
