Same question : JAAS, how did you get hold of the user's session? It's the last think I can't do.

Carl


Adam Hardy wrote:


Jackie, auth-constraint lists the roles that are allowed access. If you
have no roles, that means you need just one role for all. And you must
enter it there. Having no roles listed means no-one has permission. Or
you could try "*" for all roles (haven't tried it myself).

Re: JAAS, how did you get hold of the user's session? I don't see any way of obtaining access to it from the LoginModule.

Adam

On 02/24/2004 02:00 AM Jacqueline Gomes wrote:

That sounds like a good idea!  However, I don't have any 'roles',
they are just users that need to authenticate, and I wanted to secure
<blah>/do/admin/*.  I couldn't implement the web.xml security either
- this didn't work:

<security-constraint> <web-resource-collection> <web-resource-name>BN_ONLINE Administration</web-resource-name> <description>Security constraint for resources in the admin
directory</description> <url-pattern>/do/admin/*</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> </web-resource-collection> <auth-constraint/> </security-constraint>


Can you please send me any links to OSUser API - I've not heard of
it.

-----Original Message----- From: Nick Faiz
[mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 February 2004 8:53 AM To: 'Struts Users Mailing List' Subject: RE: How to create a "No
Action" ActionForward



Guys, I'm at this point, myself, with an application sitting on the back-burner. I've thought about an approach, which is slightly
different to yours.


I agree that declarative security in J2EE, for Servlets and JSP.s, does not really seem to go far enough, at first glance.

On the other hand, it has considerable benefits (the mappings of roles, relying upon app. server controlled ACLs, etc.).

Why not allow declarative security to do its work, then build the user information in the session, based upon whether or not the user
is in the correct role, etc.? This is what I plan to do - I'm using
the OSUser API. I'll build its information, partly, by querying roles
using the request, and relying upon WebLogic's internal LDAP server.



Declarative security is passive; it actively doesn't `do' stuff but only waits for someone to pass through something it secures. Users
make requests to post, which can be mapped to an Action class. I
don't see how they are at odds.


Nick Faiz.



-----Original Message----- From: Jacqueline Gomes
[mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 February 2004 11:38
AM To: Struts Users Mailing List Subject: RE: How to create a "No
Action" ActionForward

Neither can I. There was no way with j_security_check that I could
post to an Action class. So I implemented JAAS and in the module I
interact with a Domain Facade that does the check with the database
for a valid user.  I then construct a User object and put that in the
session. Each of my jsp's has a check (done using an include) for the
user object and if it does not exist then it redirects to the login
page.

If anyone wants any code, let me know!!

Jackie.

-----Original Message----- From: Carl [mailto:[EMAIL PROTECTED] Sent: Monday, 23 February 2004 5:01 PM To: Struts Users Mailing List Subject: Re: How to create a "No Action" ActionForward


By integarting with struts, I mean to have a loginAction witch fill the session with data about the logged user.

I can't see how to manage that with classic j_security_check.

regards,

Carl

Adam Hardy wrote:


Not having any roles effectively means from the container managed security point of view that you have only one role.

What problems did you have 'integrating' the container security? As
far as your app is concerned, j_security_check is not something
that is relevant. The whole login should be transparent to your
app. As long as you map the security constraints correctly, the
user will never see a protected page unless they login.

Adam

On 02/23/2004 08:54 AM Carl wrote:


I've faced the same issue too. (using tomcat) To solve it I've
found 2 options : - implement a filter witch intercept each
request an redirect if needed to the struts login action. It
allow a good interaction with struts but no securty by container.
- use the container : I do that by adding a CUSTOM login scheme
along BASIC & FORM in
org.apache.catalina.startup.Authenticators.properties. It's like
the filter solution but use roles and the security is managed by
the security constrains defined in web.xml. For now my CUSTUM
login is similar to the FORM login, so it's not intergrated with
struts, but I've planned to modify it soon. This second solution
need too to define a Realm in <Context> : <Realm
className="org.apache.catalina.realm.JAASRealm" appName="catalogue" userClassNames="com.asserina.atypone.catalogue.impl.ClientImpl" roleClassNames="com.asserina.atypone.catalogue.Role" />


(I'm using JAAS)

To conclude I would say that the second option is far more
powerfull and addaptable to specific needs however you have too
look close to : JAAS, custom Realm, Authenticators.properties and
is tide to your container (for me Tomcat)

Let me know if you find quiker or simpler solutions,

Regards,

Carl



Jacqueline Gomes wrote:


Hi James,

I was also trying to do the same thing, however, we are using
JRun and we don't have any user 'roles'. Specifically, I wanted
the container to do the authorisation i.e if a user tried to
access any pages after <blah blah>/admin/* then they would be
redirected to the login page if they have not logged in.
However, the application does not have any 'roles' as such. The
user is authenticated by calling a stored procedure in the
dbase.

I tried to implement the j_security_check also but was having a
tough time integrating it with the actionform etc. Do you have
any ideas as to how I would do this given that I don't have any
user roles in the application? I was going to add a 'user' object in the session and check on each page if it exists. If
it doesn't then redirect the user back to the login page. I
have set the session.setMaxInactiveInterval(72000);


Any help would be appreciated.

Thanks, Jackie.

-----Original Message----- From: James Adams
[mailto:[EMAIL PROTECTED] Sent: Monday, 23 February 2004
4:43 AM To: Struts Mailing List Subject: Re: How to create a
"No Action" ActionForward


I think Srikanth has hit the nail on the head, in that I am not fully utilizing what is already available with vanilla J2EE, namely security roles, authorization constraints, and error pages, all of which I can declare in the deployment descriptor of my web app. But I still want to use a Struts component for the authentication instead of a more traditional form-based authentication scheme.

Let me outline below what is, I think, a much better approach
and kindly ask for comments, as I'm not certain that this will
work or if it's actually the smartest way to go.

I would like to use a Struts Action class to handle my login
form, instead of vanilla form-based authentication, i.e.
"j_security_check", for two reasons: 1) form-based
authentication is not very secure since it passes the user name
and password across the network in clear text, and 2) I want to
use a LDAP server (within my login Action class) to do the authentication, and this would not be possible using plain
form-based authentication.


So the plan is to have a form in my Login.jsp with the form's
action being the login Action class. The login Action class
will connect to the LDAP server and try to authenticate using
the username and password supplied as form inputs. If the
authentication succeeds then the user's session is set with the
user's role (also retrieved from the LDAP server), and then
the control is forwarded to the first "logged in" welcome page.
If the authentication fails then the appropriate error message
("Login failed - try again") will be added to the ActionErrors
and control is forwarded back to the login page, which will
display the ActionError message via a <html:errors> tag, and allow the user to try again.


In order to accomplish session authorization of a session for
each *.jsp of the application I will declare a security
constraint in the web.xml, like so:

<security-constraint> <web-resource-collection> <web-resource-name> Restricted Pages </web-resource-name> <url-pattern>*.jsp</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> <role-name>customer</role-name> </auth-constraint> </security-constraint>


With the above I will get automatic checking of the user's role by the container at each access of any *.jsp, and anyone accessing a *.jsp without an appropriate role set in their session will not be allowed to access the page. If the user is not in the appropriate role then I can forward to an error page by declaring an <error-page> in the deployment descriptor.

The above authorization strategy takes care of what I was
trying to accomplish with my SessionValidator Action class idea
from before, which was to check for a "loggedIn" session
attribute before allowing a user to continue with page
processing.  In fact it is even better, in that it allows the
flexibility of allowing different roles and authorization of
pages based on roles and not just on a single "loggedIn" flag.
I am not sure how I will programmatically set the user's role
in the login Action class execute() method.  Is it as simple as
just setting a session attribute named "role" ?

Thanks in advance for your insight.


-James



--------------------------------------------------------------------- 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]



Reply via email to