You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by bib_lucene bib <bi...@yahoo.com> on 2005/12/30 05:58:20 UTC
Struts - tomcat j_security_check
Hi All
I am trying to work with role based permissions using tomcat container based Authentication.
I am using JDBCRealm and Form Based Authentication.
Problems:
a) I did not find a good working example (like a .war file that I can readily deploy ) and see.
b) In my struts application how can I specify upon successfull login what page it should it go. As action is j_security_check I do not know how to specify the next page.
Can someone please help me on this. I am stuck on this for a long time.
Thanks
bib
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
Re: Struts - tomcat j_security_check
Posted by Martin Gainty <mg...@hotmail.com>.
Evening all / Feliz Nuevo Ano
Jetspeed 2.0 now support JAAS at least as far as
implementing core characteristics of Permission, Principal and Policy
I encourage all to check out
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/atz-jaas.html
Apologies for the slightly O/T post-
Martin-
>
>A couple of clarifications below.
>
>On 12/30/05, Alexandre Poitras <al...@gmail.com> wrote:
> >
> > I was in charge of implementing application security last year and I
> > think 2EE security model is rather weak.
> >
> > Where we work we support it but we also use JGuard because of some
> > limitations of the standard model.
> >
> > Usually, the main complains about container-based security are :
> >
> > 1) The form authenfication allows just one general error page without
> > any possibility for customization.
>
>
>You can specify a URL that is served by a JSP page, which includes
>conditional logic (perhaps around a RequestDispatcher.forward call) to
>handle different situations differently.
>
>Actually, you can't tell what the
> > actual error is and that not very user oriented,
>
>
>Which "actual error" cases are you interested in? Security best practices
>are to *not* be too specific about what you detected that was wrong -- such
>as telling someone they got the username correct but the password wrong.
>
>2) Impossible to call the login page directly or embedd it in the
> > application layout (like in a sidebar).
> >
> > 3) Depending of the container used, it can be quite hard to have some
> > pre and post authentification-treatment, wich can be quite important.
> >
> > 4) JEE security is quite static in that it doesn't allow to
> > dynamically add roles or remove users from roles.
>
>
>Depends on your container's implementation. For example, Tomcat's JDBC and
>JNDI based Realm implementations *do* recognize new users and roles
>(although they won't recognize new roles added to an existing user until
>that user is re-logged-in).
>
>5) No standard model defined for the authentification process, but at
> > least most containers use a JAAS-based approach.
>
>
>There's a JSR (196) that is focused on improving the overall contracts
>between a container and an authentication service:
>
> http://jcp.org/en/jsr/detail?id=196
>
>Interested parties should pay attention and/or participate.
>
>6) Adding an identification model (collecting user credentials), like
> > SSO, is not a standardised operation. For example, in Tomcat, I think
> > you have to define a new Authenticator..
>
>
>For Tomcat, you have to configure this, but you don't have to write the
>code
>for it ... that's already provided.
>
>7) No standard way to log off the user. Most containers just need the
> > session to be invalidated but it's quite weird since all the
> > secury-related methods are in the request object.
> > By the way, having those methods in the request can lead to some
> > problems with JSF since most of the times you will want to store the
> > values in a session-scoped bean that can't refer request-scoped
> > values.
> >
> > Well that most of it. I hope it is clear and will give you some
> > pointers because security implementation can be perilous at first in
> > the JEE world. Sorry to publish those informations on the Struts list
> > but I don't want people to find all those *surprises* during the
> > actual development like I did.
>
>
>Craig
>
>
>On 12/30/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > > Hi bib,
> > >
> > > This isn't a Struts question strictly speaking, but I think I can
> > > help... although I don't have a working example you can look at, I can
> > > answer the second part...
> > >
> > > Container-based security is an "intercept" model, meaning you make a
> > > request for a constrained resource, and doing so causes the request to
> > > be redirected to j_security_servlet. Once the user is authorized, the
> > > original request continues.
> > >
> > > So, let's say you have a welcome page defined in web.xml named
> > > index.jsp. This welcome page immediately redirects to /loadApp.do,
>the
> > > typical Struts bootstrap model. Maybe /loadApp.do maps to a forward,
>or
> > > maybe to an Action, it doesn't really matter. The point is, it is
>meant
> > > to be the *real* starting entry point of your application.
> > >
> > > Now, lets say you configure a constraint on /loadApp.do. (or just *.do
> > > maybe). What happens is that the welcome page is hit, which forwards
>to
> > > /loadApp.do, which is intercepted by the container, since it is
> > > constrained. Your defined logon page is shown, where your
> > > authentication form is. When the user submits the form, assuming the
> > > user is authorized, the container forwards to /loadApp.do, effectively
> > > continuing the original request.
> > >
> > > I think it is worth noting, because I've seen many people get it
>wrong,
> > > that this security model is based on the idea of constraining
>resources.
> > > The important point is that any resource not specifically covered by
>a
> > > constraint IS UNCONSTRAINED. Remember, a server's job is to serve,
>and
> > > you have to go out of your way to make it not do that :)
> > >
> > > You may be wondering "what if I want to constrain all resources in the
> > > app and allow the user to come in anywhere"? Well, you can certainly
>do
> > > that, and you will get your logon page like you expect, but is the
> > > original request URI valid? This is really out of the realm of
> > > security, its something you need to deal with in your application. In
> > > my shop, we have a whole security framework built on top of J2EE
> > > security for dealing with this, and numerous other, issues. We have a
> > > series of filters that looks at the request for specific values (some
> > > from session too). For instance, we can detect, by virtue of a value
>in
> > > session that is only set in that "real" entry point, that a request
>for
> > > another URI needs to be redirected to that entry point. This means
>you
> > > really can't bookmark inside our applications, which is OK for what we
> > > build 99% of the time, but we *can* be sure the user will go through
>the
> > > main entry point, even if they try and avoid it.
> > >
> > > Hope that helps!
> > >
> > > Frank
> > >
> > > bib_lucene bib wrote:
> > > > Hi All
> > > >
> > > > I am trying to work with role based permissions using tomcat
> > container based Authentication.
> > > >
> > > > I am using JDBCRealm and Form Based Authentication.
> > > >
> > > > Problems:
> > > > a) I did not find a good working example (like a .war file that I
> > can readily deploy ) and see.
> > > > b) In my struts application how can I specify upon successfull
>login
> > what page it should it go. As action is j_security_check I do not know
>how
> > to specify the next page.
> > > >
> > > >
> > > > Can someone please help me on this. I am stuck on this for a long
> > time.
> > > >
> > > > Thanks
> > > > bib
> > > >
> > > >
> > > > ---------------------------------
> > > > Yahoo! Shopping
> > > > Find Great Deals on Holiday Gifts at Yahoo! Shopping
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > > AIM: fzammetti
> > > Yahoo: fzammetti
> > > MSN: fzammetti@hotmail.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> > Alexandre Poitras
> > Québec, Canada
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts - tomcat j_security_check
Posted by Alexandre Poitras <al...@gmail.com>.
Thank for the clarifications, I know Tomcat provide a lot of
extensions wich allows you to work quite comfortably but unfortunately
it not the case with every containers. For example, we use Oracle oc4j
and it does not give you a lot of options. So I guess the decision is
about portability versus development effort.
Some comments below.
On 12/30/05, Craig McClanahan <cr...@apache.org> wrote:
> A couple of clarifications below.
>
> On 12/30/05, Alexandre Poitras <al...@gmail.com> wrote:
> >
> > I was in charge of implementing application security last year and I
> > think 2EE security model is rather weak.
> >
> > Where we work we support it but we also use JGuard because of some
> > limitations of the standard model.
> >
> > Usually, the main complains about container-based security are :
> >
> > 1) The form authenfication allows just one general error page without
> > any possibility for customization.
>
>
> You can specify a URL that is served by a JSP page, which includes
> conditional logic (perhaps around a RequestDispatcher.forward call) to
> handle different situations differently.
>
> Actually, you can't tell what the
> > actual error is and that not very user oriented,
>
>
> Which "actual error" cases are you interested in? Security best practices
> are to *not* be too specific about what you detected that was wrong -- such
> as telling someone they got the username correct but the password wrong.
Yeah but the problem, I mean it was like that with Oracle Oc4j, is the
user is redirected to the same error page when his login is incorrect
(authentification problem) or when he triesto access a unauthorized
page (authorization problem). Plus, sometimes we needed to tell the
user is login was expirated or desactivated and that he needed to
contact the support team. We had some other cases too.
What I would have liked is to be able to trap the exception and
display a message based upon its type.
> 2) Impossible to call the login page directly or embedd it in the
> > application layout (like in a sidebar).
> >
> > 3) Depending of the container used, it can be quite hard to have some
> > pre and post authentification-treatment, wich can be quite important.
> >
> > 4) JEE security is quite static in that it doesn't allow to
> > dynamically add roles or remove users from roles.
>
>
> Depends on your container's implementation. For example, Tomcat's JDBC and
> JNDI based Realm implementations *do* recognize new users and roles
> (although they won't recognize new roles added to an existing user until
> that user is re-logged-in).
>
> 5) No standard model defined for the authentification process, but at
> > least most containers use a JAAS-based approach.
>
>
> There's a JSR (196) that is focused on improving the overall contracts
> between a container and an authentication service:
>
> http://jcp.org/en/jsr/detail?id=196
>
> Interested parties should pay attention and/or participate.
I know about this JSR but it hasn't made a lot of progress in the last
3 years. At least a draft was published this summer but last year it
was looking like it was abandonned. So I wonder what the roadmap is
now.
Authenrization has progressed quite a bit with the introduction of Jacc.
>
> 6) Adding an identification model (collecting user credentials), like
> > SSO, is not a standardised operation. For example, in Tomcat, I think
> > you have to define a new Authenticator..
>
>
> For Tomcat, you have to configure this, but you don't have to write the code
> for it ... that's already provided.
>
> 7) No standard way to log off the user. Most containers just need the
> > session to be invalidated but it's quite weird since all the
> > secury-related methods are in the request object.
> > By the way, having those methods in the request can lead to some
> > problems with JSF since most of the times you will want to store the
> > values in a session-scoped bean that can't refer request-scoped
> > values.
> >
> > Well that most of it. I hope it is clear and will give you some
> > pointers because security implementation can be perilous at first in
> > the JEE world. Sorry to publish those informations on the Struts list
> > but I don't want people to find all those *surprises* during the
> > actual development like I did.
>
>
> Craig
>
>
> On 12/30/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > > Hi bib,
> > >
> > > This isn't a Struts question strictly speaking, but I think I can
> > > help... although I don't have a working example you can look at, I can
> > > answer the second part...
> > >
> > > Container-based security is an "intercept" model, meaning you make a
> > > request for a constrained resource, and doing so causes the request to
> > > be redirected to j_security_servlet. Once the user is authorized, the
> > > original request continues.
> > >
> > > So, let's say you have a welcome page defined in web.xml named
> > > index.jsp. This welcome page immediately redirects to /loadApp.do, the
> > > typical Struts bootstrap model. Maybe /loadApp.do maps to a forward, or
> > > maybe to an Action, it doesn't really matter. The point is, it is meant
> > > to be the *real* starting entry point of your application.
> > >
> > > Now, lets say you configure a constraint on /loadApp.do. (or just *.do
> > > maybe). What happens is that the welcome page is hit, which forwards to
> > > /loadApp.do, which is intercepted by the container, since it is
> > > constrained. Your defined logon page is shown, where your
> > > authentication form is. When the user submits the form, assuming the
> > > user is authorized, the container forwards to /loadApp.do, effectively
> > > continuing the original request.
> > >
> > > I think it is worth noting, because I've seen many people get it wrong,
> > > that this security model is based on the idea of constraining resources.
> > > The important point is that any resource not specifically covered by a
> > > constraint IS UNCONSTRAINED. Remember, a server's job is to serve, and
> > > you have to go out of your way to make it not do that :)
> > >
> > > You may be wondering "what if I want to constrain all resources in the
> > > app and allow the user to come in anywhere"? Well, you can certainly do
> > > that, and you will get your logon page like you expect, but is the
> > > original request URI valid? This is really out of the realm of
> > > security, its something you need to deal with in your application. In
> > > my shop, we have a whole security framework built on top of J2EE
> > > security for dealing with this, and numerous other, issues. We have a
> > > series of filters that looks at the request for specific values (some
> > > from session too). For instance, we can detect, by virtue of a value in
> > > session that is only set in that "real" entry point, that a request for
> > > another URI needs to be redirected to that entry point. This means you
> > > really can't bookmark inside our applications, which is OK for what we
> > > build 99% of the time, but we *can* be sure the user will go through the
> > > main entry point, even if they try and avoid it.
> > >
> > > Hope that helps!
> > >
> > > Frank
> > >
> > > bib_lucene bib wrote:
> > > > Hi All
> > > >
> > > > I am trying to work with role based permissions using tomcat
> > container based Authentication.
> > > >
> > > > I am using JDBCRealm and Form Based Authentication.
> > > >
> > > > Problems:
> > > > a) I did not find a good working example (like a .war file that I
> > can readily deploy ) and see.
> > > > b) In my struts application how can I specify upon successfull login
> > what page it should it go. As action is j_security_check I do not know how
> > to specify the next page.
> > > >
> > > >
> > > > Can someone please help me on this. I am stuck on this for a long
> > time.
> > > >
> > > > Thanks
> > > > bib
> > > >
> > > >
> > > > ---------------------------------
> > > > Yahoo! Shopping
> > > > Find Great Deals on Holiday Gifts at Yahoo! Shopping
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > > AIM: fzammetti
> > > Yahoo: fzammetti
> > > MSN: fzammetti@hotmail.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> > Alexandre Poitras
> > Québec, Canada
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts - tomcat j_security_check
Posted by Craig McClanahan <cr...@apache.org>.
A couple of clarifications below.
On 12/30/05, Alexandre Poitras <al...@gmail.com> wrote:
>
> I was in charge of implementing application security last year and I
> think 2EE security model is rather weak.
>
> Where we work we support it but we also use JGuard because of some
> limitations of the standard model.
>
> Usually, the main complains about container-based security are :
>
> 1) The form authenfication allows just one general error page without
> any possibility for customization.
You can specify a URL that is served by a JSP page, which includes
conditional logic (perhaps around a RequestDispatcher.forward call) to
handle different situations differently.
Actually, you can't tell what the
> actual error is and that not very user oriented,
Which "actual error" cases are you interested in? Security best practices
are to *not* be too specific about what you detected that was wrong -- such
as telling someone they got the username correct but the password wrong.
2) Impossible to call the login page directly or embedd it in the
> application layout (like in a sidebar).
>
> 3) Depending of the container used, it can be quite hard to have some
> pre and post authentification-treatment, wich can be quite important.
>
> 4) JEE security is quite static in that it doesn't allow to
> dynamically add roles or remove users from roles.
Depends on your container's implementation. For example, Tomcat's JDBC and
JNDI based Realm implementations *do* recognize new users and roles
(although they won't recognize new roles added to an existing user until
that user is re-logged-in).
5) No standard model defined for the authentification process, but at
> least most containers use a JAAS-based approach.
There's a JSR (196) that is focused on improving the overall contracts
between a container and an authentication service:
http://jcp.org/en/jsr/detail?id=196
Interested parties should pay attention and/or participate.
6) Adding an identification model (collecting user credentials), like
> SSO, is not a standardised operation. For example, in Tomcat, I think
> you have to define a new Authenticator..
For Tomcat, you have to configure this, but you don't have to write the code
for it ... that's already provided.
7) No standard way to log off the user. Most containers just need the
> session to be invalidated but it's quite weird since all the
> secury-related methods are in the request object.
> By the way, having those methods in the request can lead to some
> problems with JSF since most of the times you will want to store the
> values in a session-scoped bean that can't refer request-scoped
> values.
>
> Well that most of it. I hope it is clear and will give you some
> pointers because security implementation can be perilous at first in
> the JEE world. Sorry to publish those informations on the Struts list
> but I don't want people to find all those *surprises* during the
> actual development like I did.
Craig
On 12/30/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > Hi bib,
> >
> > This isn't a Struts question strictly speaking, but I think I can
> > help... although I don't have a working example you can look at, I can
> > answer the second part...
> >
> > Container-based security is an "intercept" model, meaning you make a
> > request for a constrained resource, and doing so causes the request to
> > be redirected to j_security_servlet. Once the user is authorized, the
> > original request continues.
> >
> > So, let's say you have a welcome page defined in web.xml named
> > index.jsp. This welcome page immediately redirects to /loadApp.do, the
> > typical Struts bootstrap model. Maybe /loadApp.do maps to a forward, or
> > maybe to an Action, it doesn't really matter. The point is, it is meant
> > to be the *real* starting entry point of your application.
> >
> > Now, lets say you configure a constraint on /loadApp.do. (or just *.do
> > maybe). What happens is that the welcome page is hit, which forwards to
> > /loadApp.do, which is intercepted by the container, since it is
> > constrained. Your defined logon page is shown, where your
> > authentication form is. When the user submits the form, assuming the
> > user is authorized, the container forwards to /loadApp.do, effectively
> > continuing the original request.
> >
> > I think it is worth noting, because I've seen many people get it wrong,
> > that this security model is based on the idea of constraining resources.
> > The important point is that any resource not specifically covered by a
> > constraint IS UNCONSTRAINED. Remember, a server's job is to serve, and
> > you have to go out of your way to make it not do that :)
> >
> > You may be wondering "what if I want to constrain all resources in the
> > app and allow the user to come in anywhere"? Well, you can certainly do
> > that, and you will get your logon page like you expect, but is the
> > original request URI valid? This is really out of the realm of
> > security, its something you need to deal with in your application. In
> > my shop, we have a whole security framework built on top of J2EE
> > security for dealing with this, and numerous other, issues. We have a
> > series of filters that looks at the request for specific values (some
> > from session too). For instance, we can detect, by virtue of a value in
> > session that is only set in that "real" entry point, that a request for
> > another URI needs to be redirected to that entry point. This means you
> > really can't bookmark inside our applications, which is OK for what we
> > build 99% of the time, but we *can* be sure the user will go through the
> > main entry point, even if they try and avoid it.
> >
> > Hope that helps!
> >
> > Frank
> >
> > bib_lucene bib wrote:
> > > Hi All
> > >
> > > I am trying to work with role based permissions using tomcat
> container based Authentication.
> > >
> > > I am using JDBCRealm and Form Based Authentication.
> > >
> > > Problems:
> > > a) I did not find a good working example (like a .war file that I
> can readily deploy ) and see.
> > > b) In my struts application how can I specify upon successfull login
> what page it should it go. As action is j_security_check I do not know how
> to specify the next page.
> > >
> > >
> > > Can someone please help me on this. I am stuck on this for a long
> time.
> > >
> > > Thanks
> > > bib
> > >
> > >
> > > ---------------------------------
> > > Yahoo! Shopping
> > > Find Great Deals on Holiday Gifts at Yahoo! Shopping
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> > AIM: fzammetti
> > Yahoo: fzammetti
> > MSN: fzammetti@hotmail.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Struts - tomcat j_security_check
Posted by Alexandre Poitras <al...@gmail.com>.
I was in charge of implementing application security last year and I
think 2EE security model is rather weak.
Where we work we support it but we also use JGuard because of some
limitations of the standard model.
Usually, the main complains about container-based security are :
1) The form authenfication allows just one general error page without
any possibility for customization. Actually, you can't tell what the
actual error is and that not very user oriented,
2) Impossible to call the login page directly or embedd it in the
application layout (like in a sidebar).
3) Depending of the container used, it can be quite hard to have some
pre and post authentification-treatment, wich can be quite important.
4) JEE security is quite static in that it doesn't allow to
dynamically add roles or remove users from roles.
5) No standard model defined for the authentification process, but at
least most containers use a JAAS-based approach.
6) Adding an identification model (collecting user credentials), like
SSO, is not a standardised operation. For example, in Tomcat, I think
you have to define a new Authenticator..
7) No standard way to log off the user. Most containers just need the
session to be invalidated but it's quite weird since all the
secury-related methods are in the request object.
By the way, having those methods in the request can lead to some
problems with JSF since most of the times you will want to store the
values in a session-scoped bean that can't refer request-scoped
values.
Well that most of it. I hope it is clear and will give you some
pointers because security implementation can be perilous at first in
the JEE world. Sorry to publish those informations on the Struts list
but I don't want people to find all those *surprises* during the
actual development like I did.
On 12/30/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Hi bib,
>
> This isn't a Struts question strictly speaking, but I think I can
> help... although I don't have a working example you can look at, I can
> answer the second part...
>
> Container-based security is an "intercept" model, meaning you make a
> request for a constrained resource, and doing so causes the request to
> be redirected to j_security_servlet. Once the user is authorized, the
> original request continues.
>
> So, let's say you have a welcome page defined in web.xml named
> index.jsp. This welcome page immediately redirects to /loadApp.do, the
> typical Struts bootstrap model. Maybe /loadApp.do maps to a forward, or
> maybe to an Action, it doesn't really matter. The point is, it is meant
> to be the *real* starting entry point of your application.
>
> Now, lets say you configure a constraint on /loadApp.do. (or just *.do
> maybe). What happens is that the welcome page is hit, which forwards to
> /loadApp.do, which is intercepted by the container, since it is
> constrained. Your defined logon page is shown, where your
> authentication form is. When the user submits the form, assuming the
> user is authorized, the container forwards to /loadApp.do, effectively
> continuing the original request.
>
> I think it is worth noting, because I've seen many people get it wrong,
> that this security model is based on the idea of constraining resources.
> The important point is that any resource not specifically covered by a
> constraint IS UNCONSTRAINED. Remember, a server's job is to serve, and
> you have to go out of your way to make it not do that :)
>
> You may be wondering "what if I want to constrain all resources in the
> app and allow the user to come in anywhere"? Well, you can certainly do
> that, and you will get your logon page like you expect, but is the
> original request URI valid? This is really out of the realm of
> security, its something you need to deal with in your application. In
> my shop, we have a whole security framework built on top of J2EE
> security for dealing with this, and numerous other, issues. We have a
> series of filters that looks at the request for specific values (some
> from session too). For instance, we can detect, by virtue of a value in
> session that is only set in that "real" entry point, that a request for
> another URI needs to be redirected to that entry point. This means you
> really can't bookmark inside our applications, which is OK for what we
> build 99% of the time, but we *can* be sure the user will go through the
> main entry point, even if they try and avoid it.
>
> Hope that helps!
>
> Frank
>
> bib_lucene bib wrote:
> > Hi All
> >
> > I am trying to work with role based permissions using tomcat container based Authentication.
> >
> > I am using JDBCRealm and Form Based Authentication.
> >
> > Problems:
> > a) I did not find a good working example (like a .war file that I can readily deploy ) and see.
> > b) In my struts application how can I specify upon successfull login what page it should it go. As action is j_security_check I do not know how to specify the next page.
> >
> >
> > Can someone please help me on this. I am stuck on this for a long time.
> >
> > Thanks
> > bib
> >
> >
> > ---------------------------------
> > Yahoo! Shopping
> > Find Great Deals on Holiday Gifts at Yahoo! Shopping
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts - tomcat j_security_check
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi bib,
This isn't a Struts question strictly speaking, but I think I can
help... although I don't have a working example you can look at, I can
answer the second part...
Container-based security is an "intercept" model, meaning you make a
request for a constrained resource, and doing so causes the request to
be redirected to j_security_servlet. Once the user is authorized, the
original request continues.
So, let's say you have a welcome page defined in web.xml named
index.jsp. This welcome page immediately redirects to /loadApp.do, the
typical Struts bootstrap model. Maybe /loadApp.do maps to a forward, or
maybe to an Action, it doesn't really matter. The point is, it is meant
to be the *real* starting entry point of your application.
Now, lets say you configure a constraint on /loadApp.do. (or just *.do
maybe). What happens is that the welcome page is hit, which forwards to
/loadApp.do, which is intercepted by the container, since it is
constrained. Your defined logon page is shown, where your
authentication form is. When the user submits the form, assuming the
user is authorized, the container forwards to /loadApp.do, effectively
continuing the original request.
I think it is worth noting, because I've seen many people get it wrong,
that this security model is based on the idea of constraining resources.
The important point is that any resource not specifically covered by a
constraint IS UNCONSTRAINED. Remember, a server's job is to serve, and
you have to go out of your way to make it not do that :)
You may be wondering "what if I want to constrain all resources in the
app and allow the user to come in anywhere"? Well, you can certainly do
that, and you will get your logon page like you expect, but is the
original request URI valid? This is really out of the realm of
security, its something you need to deal with in your application. In
my shop, we have a whole security framework built on top of J2EE
security for dealing with this, and numerous other, issues. We have a
series of filters that looks at the request for specific values (some
from session too). For instance, we can detect, by virtue of a value in
session that is only set in that "real" entry point, that a request for
another URI needs to be redirected to that entry point. This means you
really can't bookmark inside our applications, which is OK for what we
build 99% of the time, but we *can* be sure the user will go through the
main entry point, even if they try and avoid it.
Hope that helps!
Frank
bib_lucene bib wrote:
> Hi All
>
> I am trying to work with role based permissions using tomcat container based Authentication.
>
> I am using JDBCRealm and Form Based Authentication.
>
> Problems:
> a) I did not find a good working example (like a .war file that I can readily deploy ) and see.
> b) In my struts application how can I specify upon successfull login what page it should it go. As action is j_security_check I do not know how to specify the next page.
>
>
> Can someone please help me on this. I am stuck on this for a long time.
>
> Thanks
> bib
>
>
> ---------------------------------
> Yahoo! Shopping
> Find Great Deals on Holiday Gifts at Yahoo! Shopping
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org