Re: Struts/Container-Managed Authentication Question

[Eddie Bush]

Craig R. McClanahan wrote:

>On Sun, 28 Jul 2002, Eddie Bush wrote:
>
>>Set up a page specifically with a security-constraint.  Obviously the
>>user in the above scenario will have to be led to the login by a link -
>>this scenario would be no different.  Your link would be dynamic and
>>snag the request parameters out of the URL -- and tack one additional
>>one on:  the url you wish to redirect to once you authenticate.  Now,
>>your "let the user login" page would cause authentication to occur.
>> Then they get to see the page/action/watever you pointed them to that
>>caused the login to begin iwth.  From THIS page/action/whatever you
>>could get the parameter of where to send the user, and send them
>>wherever you please - done deal.
>>
>If you are using form based login, the thing to remember is that the
>container is going to replay the *original* request (complete with any
>request parameters it included).  So including the parameters on the
>original hyperlink (to the protected page) is probably the way to go --
>that parameter can tell the redirect page where to go next.
>
That would include POST parameters too, right?

>Sample scenario -- assume the following:
>
>* index.jsp is the home page of your portal, with a "Log On" hyperlink
>  (you would display this only if the user isn't logged on yet).
>
>* The destination of the "Log On" link would be something like:
>
>/protected/logon.do?return=/index.jsp
>
>* This assumes you have a security constraint on "/protected/*".
>
>* The logon.do action would do nothing but grab the "return" parameter
>  and create an ActionForward to return to it.
>
>Now, when the user presses the "Log On" link, the container will show them
>the logon page and collect the username and password.  When the logon
>action is executed, it will return control to the index page with the
>now-logged-on user information available.
>
>The same principle can get extended to have a "Log On" link on any other
>page you want as well.  For example, on mainmenu.jsp the link would be:
>
>  /protected/logon.do?return=/mainmenu.jsp
>
>instead.
>
>Note that, under *no* circumstances, do you ever create a link to
>"j_security_check" itself.  That's a magic incantation reserved for the
>container, and only for use on the login page itself -- it's not for us.
>
Right.

As always - thanks for your input, Craig :-)

Regards,

Eddie


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

Re: Struts/Container-Managed Authentication Question

[Craig R. McClanahan]

On Sun, 28 Jul 2002, Eddie Bush wrote:

> Date: Sun, 28 Jul 2002 01:11:16 -0500
> From: Eddie Bush <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Struts/Container-Managed Authentication Question
>
> Here's something that comes to mind.  It's certainly less than idea,
> however it would provide a fair work-around:
>
> Create a directory and place a security-constraint on it.  This
> directory would contain pages that did nothing but redirects.  You would
> sit down and plan out from where your users could login, and where they
> should be sent to when they login from that page/url.  Set your
> JSP/whatever pages up to redirect accordingly.  You'd have a
> proliferation of files though - OR - how is this:
>
> Set up a page specifically with a security-constraint.  Obviously the
> user in the above scenario will have to be led to the login by a link -
> this scenario would be no different.  Your link would be dynamic and
> snag the request parameters out of the URL -- and tack one additional
> one on:  the url you wish to redirect to once you authenticate.  Now,
> your "let the user login" page would cause authentication to occur.
>  Then they get to see the page/action/watever you pointed them to that
> caused the login to begin iwth.  From THIS page/action/whatever you
> could get the parameter of where to send the user, and send them
> wherever you please - done deal.
>
> Why would this not work, Craig?  (After following this for several days
> and mulling it over rather heavily, I see no reason it would not work,
> but, knowing you are far more knowledgable on this topic than am I, I
> expect there to be a reason :-)
>
> HTH someone - and is a viable option!
>

If you are using form based login, the thing to remember is that the
container is going to replay the *original* request (complete with any
request parameters it included).  So including the parameters on the
original hyperlink (to the protected page) is probably the way to go --
that parameter can tell the redirect page where to go next.

Sample scenario -- assume the following:

* index.jsp is the home page of your portal, with a "Log On" hyperlink
  (you would display this only if the user isn't logged on yet).

* The destination of the "Log On" link would be something like:

/protected/logon.do?return=/index.jsp

* This assumes you have a security constraint on "/protected/*".

* The logon.do action would do nothing but grab the "return" parameter
  and create an ActionForward to return to it.

Now, when the user presses the "Log On" link, the container will show them
the logon page and collect the username and password.  When the logon
action is executed, it will return control to the index page with the
now-logged-on user information available.

The same principle can get extended to have a "Log On" link on any other
page you want as well.  For example, on mainmenu.jsp the link would be:

  /protected/logon.do?return=/mainmenu.jsp

instead.

Note that, under *no* circumstances, do you ever create a link to
"j_security_check" itself.  That's a magic incantation reserved for the
container, and only for use on the login page itself -- it's not for us.

> Regards,
>
> Eddie
>
> P.S. - It would be portable too, I think!
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Eddie Bush]

Here's something that comes to mind.  It's certainly less than idea, 
however it would provide a fair work-around:

Create a directory and place a security-constraint on it.  This 
directory would contain pages that did nothing but redirects.  You would 
sit down and plan out from where your users could login, and where they 
should be sent to when they login from that page/url.  Set your 
JSP/whatever pages up to redirect accordingly.  You'd have a 
proliferation of files though - OR - how is this:

Set up a page specifically with a security-constraint.  Obviously the 
user in the above scenario will have to be led to the login by a link - 
this scenario would be no different.  Your link would be dynamic and 
snag the request parameters out of the URL -- and tack one additional 
one on:  the url you wish to redirect to once you authenticate.  Now, 
your "let the user login" page would cause authentication to occur. 
 Then they get to see the page/action/watever you pointed them to that 
caused the login to begin iwth.  From THIS page/action/whatever you 
could get the parameter of where to send the user, and send them 
wherever you please - done deal.

Why would this not work, Craig?  (After following this for several days 
and mulling it over rather heavily, I see no reason it would not work, 
but, knowing you are far more knowledgable on this topic than am I, I 
expect there to be a reason :-)

HTH someone - and is a viable option!

Regards,

Eddie

P.S. - It would be portable too, I think!



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

Re: Struts/Container-Managed Authentication Question

[Max Cooper]

Torgeir,

Definitely. I'll be working on it next week (vacation, woo hoo! ;-) and hope
to have a release version ready by the beginning of August. I'll post a link
when it is ready.

I plan to release the source code, and I'd also like to provide a binary
version that you can easily drop into an app to replace container-manager
security (just move your security constraints out of web.xml and into a new
file, and provide a very simple realm implementation). A nice feature of
this approach is that you can deploy your whole app, including the realm
implementation (which often depends on other parts of your code), as a
single war file with no external dependencies. This packaging consideration
is what drove the development intitially.

-Max

- Original Message -
From: "Struts Newsgroup" <@[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 19, 2002 1:40 AM
Subject: Re: Struts/Container-Managed Authentication Question


> Subject: Re: Struts/Container-Managed Authentication Question
> From: Torgeir Veimo <[EMAIL PROTECTED]>
>  ===
> Max Cooper wrote:
>
> > If you can live with a short-term compromise of having a login link on
every
> > page rather than a login form, the first design I sent out should work
for
> > that. I have written a security filter that allows you to submit a login
> > form without having been forced to the form. You then just configure the
> > filter with a URL to dump users to after they authenticate themselves.
> > Perhaps I should allow you to optionally configure the filter to
remember
> > where you submitted the form from and return you there upon successful
> > authentication (a task for version 1.1). Anyway, I am in the process of
> > preparing it for release (i.e. it works and I'm cleaning it up).
>
> Will you post the source (or a link) in this forum to that filter?
>
> --
> -Torgeir
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[@Basebeans.com]

Subject: Re: Struts/Container-Managed Authentication Question
From: Torgeir Veimo <[EMAIL PROTECTED]>
 ===
Max Cooper wrote:

> If you can live with a short-term compromise of having a login link on every
> page rather than a login form, the first design I sent out should work for
> that. I have written a security filter that allows you to submit a login
> form without having been forced to the form. You then just configure the
> filter with a URL to dump users to after they authenticate themselves.
> Perhaps I should allow you to optionally configure the filter to remember
> where you submitted the form from and return you there upon successful
> authentication (a task for version 1.1). Anyway, I am in the process of
> preparing it for release (i.e. it works and I'm cleaning it up).

Will you post the source (or a link) in this forum to that filter?

-- 
-Torgeir


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Max Cooper]

Hello again Mete, ;-)

I like this stuff. It's like a puzzle.

> Basically I made my welcome-page a dummy page that
> redirects the request to /login.do. I made /login.do a
> protected resource and what is ironic is that I made
> my home page the "login page" !! (in ).
> This kinda turns container-managed authentication on
> its head since the protected page becomes the login
> action while the login page becomes the homepage. But
> surprisingly it seems to work. So when the user goes
> to the page, after a redirect they arrive at the home
> page. On the home page, they can either fill in the
> login form and submit, or click on any one of the
> other links in which case the authentication process
> is dropped and the user is let go to other unprotected
> pages. While this may seem like another big mess, it
> satisfies the container since the form-based
> authentication is done normally.

That is a clever setup, but I don't think it will work quite as intended
under certain circumstances. When someone follows a link into the site and
then tries to login, they will run into trouble. For instance, say Joe sends
a link to /deep/in/site/somethingCool.do to his friend Ann. Ann follows the
link and browses around for a while, and then decides to login. She enters
her username and password and submits the login form in the page margin.
Bang! Server error. Actually, on WebLogic, she will be taken the home page
(or get a 404 error, depending on where she is in the site) without getting
authenticated. On Tomcat, she'll get a server error. The problem is that the
server received a j_security_check submittal before it sent the user to the
login page. You might take the position that everyone should enter through
the home page, but in reality this problem will pop up even for people that
bookmark the home page (/index.do, for instance) and go to the site via the
bookmark, or follow a link from a Google search results page. And the web
loses much of its value if you can't link to pages within the site, even for
intranet apps or web apps where you might want to send URLs to your
co-workers or employees via email.

You might be able to partially fix this behavior with some more trickery:
1. put something in the user's session if they visit the site home page
(/index.jsp)
2. on every page (including the home page), check for the presence of the
"home page marker" described above, if it isn't there put the current URL in
the session and redirect them to the /login.do page, which will force the
container security to jump in and redirect them to the home page (which is
configured as the login page)...
3. in the home page, set the marker as usual but also check for a URL in the
session, and if it is there remove the URL from the session and redirect
them back to that URL

The only bad effects you'll up (that I can think of) with this are:
1. there will be some delay from the redirecting when users first try to
follow a link into the site
2. they will always end up at the home page (after being redirected there
from /login.do) after logging in

You can probably fix #2 by with even more trickery if you are feeling
particularly industrious.

If you can live with a short-term compromise of having a login link on every
page rather than a login form, the first design I sent out should work for
that. I have written a security filter that allows you to submit a login
form without having been forced to the form. You then just configure the
filter with a URL to dump users to after they authenticate themselves.
Perhaps I should allow you to optionally configure the filter to remember
where you submitted the form from and return you there upon successful
authentication (a task for version 1.1). Anyway, I am in the process of
preparing it for release (i.e. it works and I'm cleaning it up).

-Max


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

Re: Struts/Container-Managed Authentication Question

[Mete Kural]

Hello Max,

> > One thing that I want to implement is providing
> the
> > login form within the home-page to make it a
> > single-step job for them, so they'll see the login
> > form on the side of the page when they first come
> in.
> > Otherwise there are two steps involved, first
> click on
> > the login link to go to the login form and then
> submit
> > the login form. How do you think I can do that?
> 
> I don't know of an easy way to do that with
> container-managed
> authentication. The reason is that the caontainer
> wants to decide when to
> show the login form. If you always show a form, it
> won't know where to send
> the user when you submit. Tomcat chokes on this
> (rightly so, considering the
> spec) and WebLogic sends the user to the context
> root or something like
> that.
> 
> I can think of a really ugly (and insecure) way to
> have the login form on
> every page with container-based security:
> 1. user submits login form from any page
> 2. server stores username/password in session and
> responds with redirect to
> protected page
> 3. browser makes request for protected page
> 4. server responds with login form that you
> configured, which is setup to
> send a redirect to
> j_security_check?username=user&password=passwd if it
> finds the username/password in the session (or
> perhaps a pre-populated form
> that will automagically submit itself)
> 5. the server accepts the login and sends you to the
> protected page, which
> may just be a redirect back to the home page
> 
> Holy crap is that a scary mess! You might be able to
> clean it up a bit by
> using HTTPS (for security), some sort of frames
> setup (to lessen the chance
> of disorienting the user as things flash by), or the
> login form could have a
> "We're processing your login request..." message
> with the username and
> password in a hidden form within the page that
> submits itself when the page
> finishes loading. That might keep the user from
> freaking out when the screen
> starts flashing and it takes a while for the login
> (lots of back-and-forth
> between browser and server). Okay, I am now of the
> mind that this just might
> work.

Wow!!! It is indeed scary.. but God bless you for
solving this interesting problem. Yes indeed that
would enable me to put a login form on every page. I
hope you didn't have brain cramps while trying to
figure this out. I kinda did earlier today while
coming up with a different solution than yours, but
less functional, although I think more secure since
the password and username need not be stored in the
session.

Basically I made my welcome-page a dummy page that
redirects the request to /login.do. I made /login.do a
protected resource and what is ironic is that I made
my home page the "login page" !! (in ).
This kinda turns container-managed authentication on
its head since the protected page becomes the login
action while the login page becomes the homepage. But
surprisingly it seems to work. So when the user goes
to the page, after a redirect they arrive at the home
page. On the home page, they can either fill in the
login form and submit, or click on any one of the
other links in which case the authentication process
is dropped and the user is let go to other unprotected
pages. While this may seem like another big mess, it
satisfies the container since the form-based
authentication is done normally.

All I can say is I wish the servlet specs provided
more methods to make it possible to log the user in
through a method interface. Or maybe all they need to
do is not requiring the login submission to
j_security_check to happen only after the user has
encountered a protected page. Simply, the user should
be allowed to log in even before encountering a
protected page. Maybe they should introduce a new
sub-element in web.xml under login-config that
declares from which pages a login to j_securiy_check
could be submitted and make the login form portable
rather than binded on a single page. That could be a
viable alternative to providing a method interface
cause again which a method interface for logging in a
user, the app developer could poke holes in the
security mechanism. So basically the key phrase is
"make the login form portable".

I'd appreciate hearing your thought on this. Perhaps I
will make make a suggestion to the JCP about it. If
you would like to help that would be great.

Thanks,
Mete

> 
> Note: You can write a filter to mimic
> container-based security that does
> allow you to specify where to send the user after a
> submit when the login
> form was not shown out of necessity. I like the idea
> of the app using the
> methods defined for container-based security
> (getRemoteUser(), etc.) because
> they are standard and you can switch between
> container-based an filter-based
> with no impact to the rest of the app. We have done
> just such a switch on a
> project that I worked on, and it worked great.
> 
> > Think about Amazon. You can either be logged-in
> and
> > not logged

Re: Struts/Container-Managed Authentication Question

[Max Cooper]

Hello Mete,

> > One thing that you cannot do with container-managed
> > security is direct the
> > users to the login form page to force them to login.
> > As an alternative, you
> > can protect a page and send users there, so the
> > container will send them
> > through the login form. For instance, if your login
> > form is /loginForm.do,
> > you could make a page (even a redirect back to your
> > home page if you want
> > users to end up there) named /protected.do and then
> > setup a security
> > constraint for that page. Your Login link would be
> >  > href="(contextPath)/protected.do">Login with
> > this setup.
>
> This alternative seems attractive to me, but I'm not
> sure I have truly grasped how it works. I'm going to
> try to paraphrase, so please correct me if I'm wrong:
> - I would provide a link on the public homepage that
> says "Login here" on it. When users click the link
> they would go to a dummy protected page that simply
> redirects the user back to the homepage. Once they
> login through that they're automatically back in the
> homepage and they're logged in!

That's it -- you've got it.

> One thing that I want to implement is providing the
> login form within the home-page to make it a
> single-step job for them, so they'll see the login
> form on the side of the page when they first come in.
> Otherwise there are two steps involved, first click on
> the login link to go to the login form and then submit
> the login form. How do you think I can do that?

I don't know of an easy way to do that with container-managed
authentication. The reason is that the caontainer wants to decide when to
show the login form. If you always show a form, it won't know where to send
the user when you submit. Tomcat chokes on this (rightly so, considering the
spec) and WebLogic sends the user to the context root or something like
that.

I can think of a really ugly (and insecure) way to have the login form on
every page with container-based security:
1. user submits login form from any page
2. server stores username/password in session and responds with redirect to
protected page
3. browser makes request for protected page
4. server responds with login form that you configured, which is setup to
send a redirect to j_security_check?username=user&password=passwd if it
finds the username/password in the session (or perhaps a pre-populated form
that will automagically submit itself)
5. the server accepts the login and sends you to the protected page, which
may just be a redirect back to the home page

Holy crap is that a scary mess! You might be able to clean it up a bit by
using HTTPS (for security), some sort of frames setup (to lessen the chance
of disorienting the user as things flash by), or the login form could have a
"We're processing your login request..." message with the username and
password in a hidden form within the page that submits itself when the page
finishes loading. That might keep the user from freaking out when the screen
starts flashing and it takes a while for the login (lots of back-and-forth
between browser and server). Okay, I am now of the mind that this just might
work.

Note: You can write a filter to mimic container-based security that does
allow you to specify where to send the user after a submit when the login
form was not shown out of necessity. I like the idea of the app using the
methods defined for container-based security (getRemoteUser(), etc.) because
they are standard and you can switch between container-based an filter-based
with no impact to the rest of the app. We have done just such a switch on a
project that I worked on, and it worked great.

> Think about Amazon. You can either be logged-in and
> not logged-in and it will still work. If you're
> logged-in the website treats you like a familiar
> customer, if not just default. That's the exact same
> functionality that I'm trying to implement here. I
> hope this gives a wider picture of what I want to do
> and perhaps you know a better way to do this than how
> I was currently planning on doing it above.

Yes, your app will work like that with this setup. The login scope is the
context, and since both of your sub-apps are in the same context, the login
state is shared between them. Just write your pages to handle both the
authenticated and non-authenticated users. request.getRemoteUser() will
return null if the user is not authenticated.

-Max



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

RE: Struts/Container-Managed Authentication Question

[Nelson, Laird]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]

(First off, I take your point, but am just stupid enough to think that an
implementation is nevertheless possible.  The following is just to spur
further thought.)

> What'a a "user" (i.e. what properties does one have)?

Exactly what it is in container-managed authentication, e.g. a Principal.
Container implementations could hold whatever the container decides they
should hold.  *That* data would *not* be portable across containers--only
the Principalness would be, and the addUser(Principal) method (or some
such).

> What's a "role"?

Exactly what it is in container-managed authentication, e.g. a String.

> How about "groups"?

Groups are roles, just as they are in container-managed authentication.

> Oh, and now I need SSL certificates.

No, not necessarily, because container-managed authentication via the
mechanisms supported out of the box does not need them.

(And so on.)

Cheers,
Laird


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

RE: Struts/Container-Managed Authentication Question

[Craig R. McClanahan]

On Thu, 18 Jul 2002, Nelson, Laird wrote:

> Date: Thu, 18 Jul 2002 13:14:49 -0400
> From: "Nelson, Laird" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Struts/Container-Managed Authentication Question
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > I do not believe there will ever be such a thing as a "generic"
> > application security solution that meets a large majority of people's
> > needs.  The problem is that the needs (well, at least their
> > wants :-) vary
> > too much, so any given "application security solution" is
> > going to have
> > its own design limits that people are going to run into.
>
> A nice middle ground that would not require boiling the ocean would be a
> simple interface that allows callers to add, update and remove users and
> roles.

What'a a "user" (i.e. what properties does one have)?  What's a "role"?
How about "groups"?  Oh, and now I need SSL certificates.  And
public/private keys.  And application-specific extension properties.  Oh,
don't forget to link into external authentication infrastructures (like
Project Liberty, or Passport in the MS world).  But I've already *got*
users defined in my database, and just want to use those.  And ...

Is that global warming I'm feeling?  :-)

>  I find that the only thing I usually need above and beyond the
> current container-managed security API is the ability to create new users
> and roles.  Every container I've worked with has the ability to make these
> calls with their own APIs--all the concepts and logical objects are the
> same--but the implementations basically suffer from name incompatibilities.
>

Answering these kinds of questions for a single server or application is
fairly easy.  Answering them globally for a portable standard is quite a
bit of work.

> Cheers,
> Laird

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Struts/Container-Managed Authentication Question

[Nelson, Laird]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> I do not believe there will ever be such a thing as a "generic"
> application security solution that meets a large majority of people's
> needs.  The problem is that the needs (well, at least their 
> wants :-) vary
> too much, so any given "application security solution" is 
> going to have
> its own design limits that people are going to run into.

A nice middle ground that would not require boiling the ocean would be a
simple interface that allows callers to add, update and remove users and
roles.  I find that the only thing I usually need above and beyond the
current container-managed security API is the ability to create new users
and roles.  Every container I've worked with has the ability to make these
calls with their own APIs--all the concepts and logical objects are the
same--but the implementations basically suffer from name incompatibilities.

Cheers,
Laird

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

RE: Struts/Container-Managed Authentication Question

[Craig R. McClanahan]

On Thu, 18 Jul 2002, Joe Celentano wrote:

> Date: Thu, 18 Jul 2002 12:02:27 -0400
> From: Joe Celentano <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Struts/Container-Managed Authentication Question
>
> Max Cooper wrote:
>
> > Another alternative is to use a filter to mimic container-managed security
> > [including wrapping the request with your implementations of
> > getRemoteUser()
> > and isUserInRole()]. This way, you could provide a programmatic
> > interface to
> > log users in with an Action, ...
>
> I have read MANY previous discussions on this list debating container vs.
> app managed security. Usually they end up suggesting that since container
> managed is limited, if you can't use it, then roll your own, similar to the
> above comment. Craig's reply also said basically the same thing.
>

Container managed security is just like any other technology -- it is
designed to meet a specific set of requirements.  If your requirements
match up with those features, great ... it's easy to use it.  If they
don't, then you can't.

My caution to you, though, is that rolling your own security makes it way
too easy to write insecure applications, because almost nobody who writes
apps is a security expert.  Plus, it's a pretty large amount of work to
get this right.  And those developer manhours are expensive.  And those
hours could have been used to work on your application instead of your
infrastructure ...

Also, if your app needs (or ever will need) EJBs, you're going to have to
use container managed security anyway.

> So is anybody aware of an Apache-like project that is attempting to
> implement a "generic" application security solution for this problem? I
> mean, with filters and the ability wrap the request, as Max mentioned, a
> pretty robust solution could be developed that could be easily extended for
> different db schemas, etc. Yet I feel like we're all reinventing the wheel
> here, each of us implementing tactical rather than strategic solutions.
>

I do not believe there will ever be such a thing as a "generic"
application security solution that meets a large majority of people's
needs.  The problem is that the needs (well, at least their wants :-) vary
too much, so any given "application security solution" is going to have
its own design limits that people are going to run into.

> Sorry if there's already been a discussion of these projects, but I looked
> and couldn't find any...
>
> Thanks,
> Joe
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Craig R. McClanahan]

On Thu, 18 Jul 2002, Mete Kural wrote:

> Date: Thu, 18 Jul 2002 08:46:46 -0700 (PDT)
> From: Mete Kural <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Struts/Container-Managed Authentication Question
>
> Hello Craig,
>
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > If you are using container-managed security, you
> > either declare a security
> > constraint (to force a login) or you don't -- there
> > is no middle ground.
> > However, if the user went to your second sub-app
> > first, and then went to
> > the first one, the fact that they have logged in is
> > visible to your
> > application, because getRemoteUser() will still
> > return the logged-in
> > user's identity.
>
> That's exactly what I want to happen. To preserve the
> loggedinness of the user even when they go out of the
> protected area into the public area.
>
> > There is no such mechanism that is portable across
> > containers.  If you
> > want to use container managed security, you should
> > architect your
> > application inside its boundaries -- otherwise, you
> > should roll your own.
>
> Hmm.. I hope the JCP will include such a mechanism in
> Servlet 2.4. It would be nice to enable pre-processing
> on the form-based login submission in a servlet and
> then submit that to the container. Perhaps this is not
> a valid use case, but it seems to me that it may be
> attractive in certain scenarios.
>

It's not going to make it for Servlet 2.4 (which is currently in public
review, so you can see the proposed changes for yourself).  Dealing with
*all* of the issues required to make some sort of authentication plugin to
containers is probably a year's worth of of Expert Group work to define an
appropriate specification.


> > Quite frankly, I'm not convinced your use case is
> > very compelling, but I
> > undoubtedly don't understand the whole picture,
> > either.
>
> Think about Amazon.com. On Amazon, you can surf
> through the shopping pages with or without being
> logged in to your Amazon account. If you're logged in,
> some special features are enabled such as personal
> book recommendations on the sides of the pages. If
> you're not logged in it just treats you like a default
> customer that it doesn't know about. In this case, it
> is necessary to provide a login mechanism to better
> serve the customer even if login is not required.
>

Nothing stops you from accomplishing exactly this functionality.  The
page you describe would *not* be protected by a security constraint -- but
the logic that produces that page can tell if a user is logged in or not
(call request.getUserPrincipal() or request.getRemoteUser()) and vary the
generated HTML based on whether this value is null or not.

> >
> > Craig
>
> Thanks,
> Mete
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Struts/Container-Managed Authentication Question

[Joe Celentano]

Max Cooper wrote:

> Another alternative is to use a filter to mimic container-managed security
> [including wrapping the request with your implementations of
> getRemoteUser()
> and isUserInRole()]. This way, you could provide a programmatic
> interface to
> log users in with an Action, ...

I have read MANY previous discussions on this list debating container vs.
app managed security. Usually they end up suggesting that since container
managed is limited, if you can't use it, then roll your own, similar to the
above comment. Craig's reply also said basically the same thing.

So is anybody aware of an Apache-like project that is attempting to
implement a "generic" application security solution for this problem? I
mean, with filters and the ability wrap the request, as Max mentioned, a
pretty robust solution could be developed that could be easily extended for
different db schemas, etc. Yet I feel like we're all reinventing the wheel
here, each of us implementing tactical rather than strategic solutions.

Sorry if there's already been a discussion of these projects, but I looked
and couldn't find any...

Thanks,
Joe


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

Re: Struts/Container-Managed Authentication Question

[Mete Kural]

Hello Max,

--- Max Cooper <[EMAIL PROTECTED]> wrote:
> One thing that you cannot do with container-managed
> security is direct the
> users to the login form page to force them to login.
> As an alternative, you
> can protect a page and send users there, so the
> container will send them
> through the login form. For instance, if your login
> form is /loginForm.do,
> you could make a page (even a redirect back to your
> home page if you want
> users to end up there) named /protected.do and then
> setup a security
> constraint for that page. Your Login link would be
>  href="(contextPath)/protected.do">Login with
> this setup.

This alternative seems attractive to me, but I'm not
sure I have truly grasped how it works. I'm going to
try to paraphrase, so please correct me if I'm wrong:
- I would provide a link on the public homepage that
says "Login here" on it. When users click the link
they would go to a dummy protected page that simply
redirects the user back to the homepage. Once they
login through that they're automatically back in the
homepage and they're logged in!

One thing that I want to implement is providing the
login form within the home-page to make it a
single-step job for them, so they'll see the login
form on the side of the page when they first come in.
Otherwise there are two steps involved, first click on
the login link to go to the login form and then submit
the login form. How do you think I can do that?

Think about Amazon. You can either be logged-in and
not logged-in and it will still work. If you're
logged-in the website treats you like a familiar
customer, if not just default. That's the exact same
functionality that I'm trying to implement here. I
hope this gives a wider picture of what I want to do
and perhaps you know a better way to do this than how
I was currently planning on doing it above.

> 
> I think you can acheive your desired functionality
> with those techniques. If
> you need more info, I'll be happy to help out.
> 
> Another alternative is to use a filter to mimic
> container-managed security
> [including wrapping the request with your
> implementations of getRemoteUser()
> and isUserInRole()]. This way, you could provide a
> programmatic interface to
> log users in with an Action, but the value of
> providing the interface is not
> clear to me. I think you can acheive your desired
> functionality without it,
> and end up with less coupling between your app and
> the authentication
> mechanism.
> 
> -Max

Thanks,
Mete

> 
> - Original Message -
> From: "Eddie Bush" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List"
> <[EMAIL PROTECTED]>
> Sent: Wednesday, July 17, 2002 6:59 PM
> Subject: Re: Struts/Container-Managed Authentication
> Question
> 
> 
> > I'd recommend putting it to the Tomcat guys, but
> I'm just about positive
> > you'd have to use j_security_check (ie FORM-based
> authentication).
> >
> > Mete Kural wrote:
> >
> > >Hi,
> > >
> > >My Struts-based webapp has two sub-apps.
> > >
> > >In the first sub-app, anybody can surf through
> without
> > >having to be logged in, but if you are logged in,
> some
> > >special features are enabled (ex: "Hello Mr.
> ..").
> > >
> > >In the second sub-app, you have to be logged in
> to
> > >access the pages therein.
> > >
> > >For the entirety of the second sub-app, obviously
> a
> > >security-constraint should be declared in
> web.xml. But
> > >the first sub-app is open to anybody, although
> login
> > >is encouraged (i.e. not required). For that
> reason, I
> > >can't put a security-constraint for the first
> sub-app
> > >in web.xml, but how am I going to authorize users
> who
> > >want to log in while they're in the first sub-app
> in a
> > >container-managed manner??
> > >
> > >Basically what I want to do is to log a user in
> with
> > >the container from a LoginAction class, rather
> than
> > >the good-old "j_security" way. Maybe this one
> should
> > >be asked to the Tomcat group, but in case some of
> you
> > >may know, Is there a way to log a user in with
> the
> > >container through a method interface inside an
> Action
> > >class instead of dispatching the request to
> > >j_security_constraint? I couldn't find such a
> method
> > >interface in the Servlet 2.3 specs.
> > >
> > >I'll appreciate any insight on this.
> > >
> > >Thanks,
> > >Mete Kural
> 
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 


__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Mete Kural]

Hello Craig,

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> If you are using container-managed security, you
> either declare a security
> constraint (to force a login) or you don't -- there
> is no middle ground.
> However, if the user went to your second sub-app
> first, and then went to
> the first one, the fact that they have logged in is
> visible to your
> application, because getRemoteUser() will still
> return the logged-in
> user's identity.

That's exactly what I want to happen. To preserve the
loggedinness of the user even when they go out of the
protected area into the public area.
 
> There is no such mechanism that is portable across
> containers.  If you
> want to use container managed security, you should
> architect your
> application inside its boundaries -- otherwise, you
> should roll your own.

Hmm.. I hope the JCP will include such a mechanism in
Servlet 2.4. It would be nice to enable pre-processing
on the form-based login submission in a servlet and
then submit that to the container. Perhaps this is not
a valid use case, but it seems to me that it may be
attractive in certain scenarios.
 
> Quite frankly, I'm not convinced your use case is
> very compelling, but I
> undoubtedly don't understand the whole picture,
> either.

Think about Amazon.com. On Amazon, you can surf
through the shopping pages with or without being
logged in to your Amazon account. If you're logged in,
some special features are enabled such as personal
book recommendations on the sides of the pages. If
you're not logged in it just treats you like a default
customer that it doesn't know about. In this case, it
is necessary to provide a login mechanism to better
serve the customer even if login is not required.

> 
> Craig

Thanks,
Mete




__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

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

Re: Struts/Container-Managed Authentication Question

[Craig R. McClanahan]

On Wed, 17 Jul 2002, Mete Kural wrote:

> Date: Wed, 17 Jul 2002 18:32:17 -0700 (PDT)
> From: Mete Kural <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Struts/Container-Managed Authentication Question
>
> Hi,
>
> My Struts-based webapp has two sub-apps.
>
> In the first sub-app, anybody can surf through without
> having to be logged in, but if you are logged in, some
> special features are enabled (ex: "Hello Mr. ..").
>
> In the second sub-app, you have to be logged in to
> access the pages therein.
>
> For the entirety of the second sub-app, obviously a
> security-constraint should be declared in web.xml. But
> the first sub-app is open to anybody, although login
> is encouraged (i.e. not required). For that reason, I
> can't put a security-constraint for the first sub-app
> in web.xml, but how am I going to authorize users who
> want to log in while they're in the first sub-app in a
> container-managed manner??
>

If you are using container-managed security, you either declare a security
constraint (to force a login) or you don't -- there is no middle ground.
However, if the user went to your second sub-app first, and then went to
the first one, the fact that they have logged in is visible to your
application, because getRemoteUser() will still return the logged-in
user's identity.

> Basically what I want to do is to log a user in with
> the container from a LoginAction class, rather than
> the good-old "j_security" way. Maybe this one should
> be asked to the Tomcat group, but in case some of you
> may know, Is there a way to log a user in with the
> container through a method interface inside an Action
> class instead of dispatching the request to
> j_security_constraint? I couldn't find such a method
> interface in the Servlet 2.3 specs.
>

There is no such mechanism that is portable across containers.  If you
want to use container managed security, you should architect your
application inside its boundaries -- otherwise, you should roll your own.

Quite frankly, I'm not convinced your use case is very compelling, but I
undoubtedly don't understand the whole picture, either.

> I'll appreciate any insight on this.
>
> Thanks,
> Mete Kural
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Max Cooper]

Mete,

With contained-managed security, you have to let the container process the
login form submittal (j_security_check). There is no method you can call to
process the login yourself. The container makes the info like the user name
and if a user is in a particular role through methods on the request
[getRemoteUser() & isUserInRole()]. I haven't played with sub-apps yet, but
I imagine they run in the same context from the server's perspective, so
container-managed security should work fine. If they don't run in the same
context, you can probably still do what you want with container-based
security and some additional setup.

One thing that you cannot do with container-managed security is direct the
users to the login form page to force them to login. As an alternative, you
can protect a page and send users there, so the container will send them
through the login form. For instance, if your login form is /loginForm.do,
you could make a page (even a redirect back to your home page if you want
users to end up there) named /protected.do and then setup a security
constraint for that page. Your Login link would be Login with this setup.

I think you can acheive your desired functionality with those techniques. If
you need more info, I'll be happy to help out.

Another alternative is to use a filter to mimic container-managed security
[including wrapping the request with your implementations of getRemoteUser()
and isUserInRole()]. This way, you could provide a programmatic interface to
log users in with an Action, but the value of providing the interface is not
clear to me. I think you can acheive your desired functionality without it,
and end up with less coupling between your app and the authentication
mechanism.

-Max

- Original Message -
From: "Eddie Bush" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 6:59 PM
Subject: Re: Struts/Container-Managed Authentication Question


> I'd recommend putting it to the Tomcat guys, but I'm just about positive
> you'd have to use j_security_check (ie FORM-based authentication).
>
> Mete Kural wrote:
>
> >Hi,
> >
> >My Struts-based webapp has two sub-apps.
> >
> >In the first sub-app, anybody can surf through without
> >having to be logged in, but if you are logged in, some
> >special features are enabled (ex: "Hello Mr. ..").
> >
> >In the second sub-app, you have to be logged in to
> >access the pages therein.
> >
> >For the entirety of the second sub-app, obviously a
> >security-constraint should be declared in web.xml. But
> >the first sub-app is open to anybody, although login
> >is encouraged (i.e. not required). For that reason, I
> >can't put a security-constraint for the first sub-app
> >in web.xml, but how am I going to authorize users who
> >want to log in while they're in the first sub-app in a
> >container-managed manner??
> >
> >Basically what I want to do is to log a user in with
> >the container from a LoginAction class, rather than
> >the good-old "j_security" way. Maybe this one should
> >be asked to the Tomcat group, but in case some of you
> >may know, Is there a way to log a user in with the
> >container through a method interface inside an Action
> >class instead of dispatching the request to
> >j_security_constraint? I couldn't find such a method
> >interface in the Servlet 2.3 specs.
> >
> >I'll appreciate any insight on this.
> >
> >Thanks,
> >Mete Kural



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Struts/Container-Managed Authentication Question

[Eddie Bush]

I'd recommend putting it to the Tomcat guys, but I'm just about positive 
you'd have to use j_security_check (ie FORM-based authentication).

Mete Kural wrote:

>Hi,
>
>My Struts-based webapp has two sub-apps. 
>
>In the first sub-app, anybody can surf through without
>having to be logged in, but if you are logged in, some
>special features are enabled (ex: "Hello Mr. .."). 
>
>In the second sub-app, you have to be logged in to
>access the pages therein.
>
>For the entirety of the second sub-app, obviously a
>security-constraint should be declared in web.xml. But
>the first sub-app is open to anybody, although login
>is encouraged (i.e. not required). For that reason, I
>can't put a security-constraint for the first sub-app
>in web.xml, but how am I going to authorize users who
>want to log in while they're in the first sub-app in a
>container-managed manner??
>
>Basically what I want to do is to log a user in with
>the container from a LoginAction class, rather than
>the good-old "j_security" way. Maybe this one should
>be asked to the Tomcat group, but in case some of you
>may know, Is there a way to log a user in with the
>container through a method interface inside an Action
>class instead of dispatching the request to
>j_security_constraint? I couldn't find such a method
>interface in the Servlet 2.3 specs.
>
>I'll appreciate any insight on this.
>
>Thanks,
>Mete Kural
>
>
>
>__
>Do You Yahoo!?
>Yahoo! Autos - Get free new car price quotes
>http://autos.yahoo.com
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>



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

Struts/Container-Managed Authentication Question

[Mete Kural]

Hi,

My Struts-based webapp has two sub-apps. 

In the first sub-app, anybody can surf through without
having to be logged in, but if you are logged in, some
special features are enabled (ex: "Hello Mr. .."). 

In the second sub-app, you have to be logged in to
access the pages therein.

For the entirety of the second sub-app, obviously a
security-constraint should be declared in web.xml. But
the first sub-app is open to anybody, although login
is encouraged (i.e. not required). For that reason, I
can't put a security-constraint for the first sub-app
in web.xml, but how am I going to authorize users who
want to log in while they're in the first sub-app in a
container-managed manner??

Basically what I want to do is to log a user in with
the container from a LoginAction class, rather than
the good-old "j_security" way. Maybe this one should
be asked to the Tomcat group, but in case some of you
may know, Is there a way to log a user in with the
container through a method interface inside an Action
class instead of dispatching the request to
j_security_constraint? I couldn't find such a method
interface in the Servlet 2.3 specs.

I'll appreciate any insight on this.

Thanks,
Mete Kural



__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

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