Re: Fine Grained Access Control in Sturts

2003-03-21 Thread David Graham

How would this be done with jstl?


???
The logic:present tag relies on HttpServletRequest.isUserInRole()
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServletRequest.html#isUserInRole(java.lang.String)
So, in JSTL I *think* you could do

not quite as easy, and is 'user' a page scoped variable or is
something else required.
Dan
David

_
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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


RE: Fine Grained Access Control in Sturts

2003-03-21 Thread David Graham
http://jakarta.apache.org/struts/userGuide/struts-tiles.html#insert

David



From: [EMAIL PROTECTED]
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: Fine Grained Access Control in Sturts
Date: Fri, 21 Mar 2003 08:12:26 +0100
Can you have a tile require a certain Role like  mappings have?

  _

Thank You

Mick Knutson

Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _


-Original Message-
From: Mike Duffy [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 9:23 PM
To: [EMAIL PROTECTED]
Subject: Fine Grained Access Control in Sturts
Does anyone have any thoughts on fine grained access control in
Struts?
Struts enables access control based on actions (see "Struts in
Action", Husted, et. al., pp 550-553), and most application servers
can protect resources based on realms/roles.
But what about display options based on roles.  For example, if you
only wanted an "Admin" link to appear if the user was an
administrator, what would be the best way to do this?
You could make the "role" an attribute of the user object and then do
a logic test for the appropriate role.  Or it might be even better to
write a logic tag that takes the user role as an attribute.  Any
thoughts?
Thanks for your consideration.

BTW.  The Husted book is a very good book.

Mike

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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


Re: Fine Grained Access Control in Sturts

2003-03-21 Thread Max Cooper
There are a number of things you can do, but most of them involve multiple
logic tags. Here is one that doesn't:

"
/>

That will set disabled to "true" when the user does not have the "admin"
role. This assumes that you are using a security setup where
request.isUserInRole() works, which means container-managed security or a
filter-based solution like SecurityFilter. You may also choose to use
multiple logic tags, etc., as a matter of convention or in the interest of
clarity or minimizing <%= %> stuff.

This will handle the UI side of things. But it would be very easy for a user
to sidestep this "security" approach unless you also add checking to make
sure the user has the role required to change this property on the server.
If the action that handles this form after it is submitted just blindly
accepts any values or chages to values without checking for access, a user
could construct their own request to change the value, even if they don't
have the "admin" role. Don't trust the access level if it is simply a hidden
field or something, as the user can change that, too.

To really protect your app, you would need to do something like this (in the
Action):

if (request.isUserInRole("admin")) {
   myPersistentObject.setProperty1(bean.getProperty1());
} else {
   // user doesn't have access, so ignore any changes to property1
}

It can be useful to include the access information in the ActionForm if you
want to pass it down to your business logic level, thereby avoiding coupling
your business logic processing to the security framework of the web
environment. If you do this, just be sure to re-set the values you get with
the form submission to protect your app from the user changing them
maliciously. Your action might have code like this for such protection:

// The user might set this to "true" in their form submittal even if they
don't have access.
// Throw out the value from the form submittal and set it properly before
passing the
// ActionForm (bean) to the business logic processing layer
bean.setUserHasAdminAccess(request.isUserInRole("admin") ? "true" :
"false");

// the doSomething() method will call bean.getUserHasAdminAccess() to see if
the user
// should really be allowed to change property1
BusinessLogicProcessor.doSomething(bean);

Don't trust the request! Anyone can submit whatever they want to your web
app. That's one reason we do server-side validation. You obviously have to
"trust" some information, but it is all too easy to open security holes in
your app if you are too trusting. Without such server-side processing, a
user could run these commands to change things that you don't want them to
change:

curl -d "property1=haha_I_changed_it" http://server/wreakHavoc.do
curl -d "property1=haha_I_changed_it&userHasAdminRole=true"
http://server/wreakHavoc.do

You can login and use a session with curl, too, since it supports cookies.
So don't think that hurdle will protect you app. Here's an example:

curl -c cookies.txt -b cookies.txt -d
"j_username=badboy&j_password=password" http://server/j_security_check
curl -c cookies.txt -b cookies.txt -d
"property1=haha_I_changed_it&userHasAdminRole=true"
http://server/wreakHavoc.do

You can even do some of this stuff in the browser, which will maintain the
session for you. A user could type this into the address bar:

http://server/wreakHavoc.do?property1=haha_I_changed_it&userHasAdminRole=tru
e


I get a lot of "who's going to do that?" responses when I bring this stuff
up. But frankly, anyone who knows a little HTTP and HTML can do this quite
easily. It might be a disgruntled or merely mischeivious
employee/associate/customer on an intranet or extranet app. Or anyone on the
internet for an extranet or internet app. If you don't think about this
stuff from the beginning and take measures to protect your app, you can end
up in a very bad situtation where you have to go over the whole app to find
and close security holes. That can make a mess of your architecture if you
have to pile on a bunch of code where you didn't expect to need it, and
could be a very bad thing for your company or career if you have holes that
lead to lost money, destroyed data, or merely a damaged reputation.
Understanding these simple 'hacking' techniques go a long way toward toward
developing secure systems, but many web app developers are not aware of
them. Any time you create some functionality, take a moment to "think like a
hacker" and see how the new functionality might allow the user to do
something they aren't supposed to be able to do. Be careful!

-Max

- Original Message -
From: "Sebastien Cesbron" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>

RE: Fine Grained Access Control in Sturts

2003-03-21 Thread Mick . Knutson
Thank you very much for this. Quite helpful!

 
  _  

Thank You
 
Mick Knutson
 
Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _  



-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 10:17 AM
To: Struts Users Mailing List
Subject: Re: Fine Grained Access Control in Sturts


Roles are groups are essentially the same thing in the context of
Servlet-spec security.

The method request.isUserInRole("role-name") is all you get.

You can map the more complicated structure to simple roles using some scheme
like this:

groupA.read
groupA.write
groupA.admin
groupB.read
groupB.write
groupB.admin

These are all simple role names. The '.' separator is just an arbitrary
convention and has no meaning beyond the meaning you give it in this
scenario (i.e. the container will do no special processing based on the
presence of the '.').

For the userA you describe, s/he would have these roles:

groupA.read
groupA.write
groupA.admin
groupB.read

So these calls would have these values:

request.isUserInRole("groupA.read") = true
request.isUserInRole("groupA.write") = true
request.isUserInRole("groupA.admin") = true
request.isUserInRole("groupB.read") = true
request.isUserInRole("groupB.write") = false
request.isUserInRole("groupB.admin") = false

You could even write your own Realm to do special processing on the '.'
notation if you want to that would use another table to look up permissions
like "read", "write", "admin" based on the group "groupA" or "groupB". The
container will just ask your Realm implementation if a user has the
"groupA.read" role, but the realm can do whatever processing it needs to do
to get an answer to that question, including consulting a more complex
schema than the basic "user", "role", and "user_role_map" tables. That may
or may not be a useful abstraction to maintain. If you just use the basic
schema, you don't have to do any special processing.

-Max

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 12:10 AM
Subject: RE: Fine Grained Access Control in Sturts


Is there a way to actually use Roles and Groups in Control?
I.E. I have 2 groups, "groupA", and "groupB".
"userA" would have "read", "write" and "admin" role in "goupA", but have
only "read" role in "groupB"

Is this possible?


  _

Thank You

Mick Knutson

Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _



-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 9:05 AM
To: Struts Users Mailing List
Subject: Re: Fine Grained Access Control in Sturts


A given user can have many roles, so be careful not to break that concept if
you can avoid it. Even if you don't need it now, it is supported by the
standard security stuff and it would be a shame to paint yourself into a
such a corner accidentally. You might need it later.

-Max

- Original Message -
From: "Dan Allen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 9:36 PM
Subject: Re: Fine Grained Access Control in Sturts


> > I always feel bad when I ask a question that is in the existing
> > documentation.
> >
> > For others (unlike David) who do not have the documentation
> > memorized, the "logic:present" tag will take a "role" attribute:
> >
> > Checks whether the currently authenticated user (if any) has been
> > associated with any of the specified security roles. Use a
> > comma-delimited list to check for multiple roles. Example:
> >  code. 
> >
> > (RT EXPR)
>
> How would this be done with jstl?
>
> 
> ???
>
> not quite as easy, and is 'user' a page scoped variable or is
> something else required.
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <[EMAIL PROTECTED]>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-
To un

Re: Fine Grained Access Control in Sturts

2003-03-21 Thread Max Cooper
Roles are groups are essentially the same thing in the context of
Servlet-spec security.

The method request.isUserInRole("role-name") is all you get.

You can map the more complicated structure to simple roles using some scheme
like this:

groupA.read
groupA.write
groupA.admin
groupB.read
groupB.write
groupB.admin

These are all simple role names. The '.' separator is just an arbitrary
convention and has no meaning beyond the meaning you give it in this
scenario (i.e. the container will do no special processing based on the
presence of the '.').

For the userA you describe, s/he would have these roles:

groupA.read
groupA.write
groupA.admin
groupB.read

So these calls would have these values:

request.isUserInRole("groupA.read") = true
request.isUserInRole("groupA.write") = true
request.isUserInRole("groupA.admin") = true
request.isUserInRole("groupB.read") = true
request.isUserInRole("groupB.write") = false
request.isUserInRole("groupB.admin") = false

You could even write your own Realm to do special processing on the '.'
notation if you want to that would use another table to look up permissions
like "read", "write", "admin" based on the group "groupA" or "groupB". The
container will just ask your Realm implementation if a user has the
"groupA.read" role, but the realm can do whatever processing it needs to do
to get an answer to that question, including consulting a more complex
schema than the basic "user", "role", and "user_role_map" tables. That may
or may not be a useful abstraction to maintain. If you just use the basic
schema, you don't have to do any special processing.

-Max

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 12:10 AM
Subject: RE: Fine Grained Access Control in Sturts


Is there a way to actually use Roles and Groups in Control?
I.E. I have 2 groups, "groupA", and "groupB".
"userA" would have "read", "write" and "admin" role in "goupA", but have
only "read" role in "groupB"

Is this possible?


  _

Thank You

Mick Knutson

Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _



-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 9:05 AM
To: Struts Users Mailing List
Subject: Re: Fine Grained Access Control in Sturts


A given user can have many roles, so be careful not to break that concept if
you can avoid it. Even if you don't need it now, it is supported by the
standard security stuff and it would be a shame to paint yourself into a
such a corner accidentally. You might need it later.

-Max

- Original Message -
From: "Dan Allen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 9:36 PM
Subject: Re: Fine Grained Access Control in Sturts


> > I always feel bad when I ask a question that is in the existing
> > documentation.
> >
> > For others (unlike David) who do not have the documentation
> > memorized, the "logic:present" tag will take a "role" attribute:
> >
> > Checks whether the currently authenticated user (if any) has been
> > associated with any of the specified security roles. Use a
> > comma-delimited list to check for multiple roles. Example:
> >  code. 
> >
> > (RT EXPR)
>
> How would this be done with jstl?
>
> 
> ???
>
> not quite as easy, and is 'user' a page scoped variable or is
> something else required.
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <[EMAIL PROTECTED]>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> -
> 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]


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mi

Re: Fine Grained Access Control in Sturts

2003-03-21 Thread Sebastien Cesbron
And what about "read" mode for role "newbie" and "write" mode for role 
"admin".

Is there a way not to put the input field twice with two different 
logic:present tags ?

Does anybody have an idea on how to change display based on the role 
(and maybe something else) ?

Seb

Max Cooper wrote:
You can use the logic tags to do something like this:


   Admin

This assumes you are using a security mechanism where
request.isUserInRole("admin") will return true when the user is in that
role. For that to work, you must use container-managed security or a
filter-based solution like http://securityfilter.sourceforge.net/.
-Max
shamelessly plugging SecurityFilter again :)
- Original Message -
From: "Mike Duffy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 12:23 PM
Subject: Fine Grained Access Control in Sturts


Does anyone have any thoughts on fine grained access control in
Struts?
Struts enables access control based on actions (see "Struts in
Action", Husted, et. al., pp 550-553), and most application servers
can protect resources based on realms/roles.
But what about display options based on roles.  For example, if you
only wanted an "Admin" link to appear if the user was an
administrator, what would be the best way to do this?
You could make the "role" an attribute of the user object and then do
a logic test for the appropriate role.  Or it might be even better to
write a logic tag that takes the user role as an attribute.  Any
thoughts?
Thanks for your consideration.

BTW.  The Husted book is a very good book.

Mike

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
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]
_
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
Règlement : http://www.ifrance.com/_reloc/sign.sms
_
GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
(prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
Règlement : http://www.ifrance.com/_reloc/sign.sms
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Fine Grained Access Control in Sturts

2003-03-21 Thread Mick . Knutson
Is there a way to actually use Roles and Groups in Control?
I.E. I have 2 groups, "groupA", and "groupB".
"userA" would have "read", "write" and "admin" role in "goupA", but have only "read" 
role in "groupB"

Is this possible?

 
  _  

Thank You
 
Mick Knutson
 
Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _  



-Original Message-
From: Max Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 9:05 AM
To: Struts Users Mailing List
Subject: Re: Fine Grained Access Control in Sturts


A given user can have many roles, so be careful not to break that concept if
you can avoid it. Even if you don't need it now, it is supported by the
standard security stuff and it would be a shame to paint yourself into a
such a corner accidentally. You might need it later.

-Max

- Original Message -
From: "Dan Allen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 9:36 PM
Subject: Re: Fine Grained Access Control in Sturts


> > I always feel bad when I ask a question that is in the existing
> > documentation.
> >
> > For others (unlike David) who do not have the documentation
> > memorized, the "logic:present" tag will take a "role" attribute:
> >
> > Checks whether the currently authenticated user (if any) has been
> > associated with any of the specified security roles. Use a
> > comma-delimited list to check for multiple roles. Example:
> >  code. 
> >
> > (RT EXPR)
>
> How would this be done with jstl?
>
> 
> ???
>
> not quite as easy, and is 'user' a page scoped variable or is
> something else required.
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <[EMAIL PROTECTED]>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> -
> 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]


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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



Re: Fine Grained Access Control in Sturts

2003-03-21 Thread Max Cooper
A given user can have many roles, so be careful not to break that concept if
you can avoid it. Even if you don't need it now, it is supported by the
standard security stuff and it would be a shame to paint yourself into a
such a corner accidentally. You might need it later.

-Max

- Original Message -
From: "Dan Allen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 9:36 PM
Subject: Re: Fine Grained Access Control in Sturts


> > I always feel bad when I ask a question that is in the existing
> > documentation.
> >
> > For others (unlike David) who do not have the documentation
> > memorized, the "logic:present" tag will take a "role" attribute:
> >
> > Checks whether the currently authenticated user (if any) has been
> > associated with any of the specified security roles. Use a
> > comma-delimited list to check for multiple roles. Example:
> >  code. 
> >
> > (RT EXPR)
>
> How would this be done with jstl?
>
> 
> ???
>
> not quite as easy, and is 'user' a page scoped variable or is
> something else required.
>
> Dan
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Daniel Allen, <[EMAIL PROTECTED]>
> http://www.mojavelinux.com/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> "I'm old enough to know better, but still too young to care."
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> -
> 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]



RE: Fine Grained Access Control in Sturts

2003-03-20 Thread Mick . Knutson
Can you have a tile require a certain Role like  mappings have?

 
  _  

Thank You
 
Mick Knutson
 
Sr. Designer - Project Trust
aUBS AG, Financial - Zürich
Office: +41 (0)1/234.42.75
Internal: 48194
Mobile: 079.726.14.26
  _  



-Original Message-
From: Mike Duffy [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 9:23 PM
To: [EMAIL PROTECTED]
Subject: Fine Grained Access Control in Sturts


Does anyone have any thoughts on fine grained access control in
Struts?  

Struts enables access control based on actions (see "Struts in
Action", Husted, et. al., pp 550-553), and most application servers
can protect resources based on realms/roles.

But what about display options based on roles.  For example, if you
only wanted an "Admin" link to appear if the user was an
administrator, what would be the best way to do this?

You could make the "role" an attribute of the user object and then do
a logic test for the appropriate role.  Or it might be even better to
write a logic tag that takes the user role as an attribute.  Any
thoughts? 

Thanks for your consideration.

BTW.  The Husted book is a very good book.

Mike


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


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



Re: Fine Grained Access Control in Sturts

2003-03-20 Thread Dan Allen
> I always feel bad when I ask a question that is in the existing
> documentation.  
> 
> For others (unlike David) who do not have the documentation
> memorized, the "logic:present" tag will take a "role" attribute:
> 
> Checks whether the currently authenticated user (if any) has been
> associated with any of the specified security roles. Use a
> comma-delimited list to check for multiple roles. Example:
>  code. 
> 
> (RT EXPR) 

How would this be done with jstl?


???

not quite as easy, and is 'user' a page scoped variable or is
something else required.

Dan

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <[EMAIL PROTECTED]>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
"I'm old enough to know better, but still too young to care."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

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



Re: Fine Grained Access Control in Sturts

2003-03-20 Thread Dan Allen
> I always feel bad when I ask a question that is in the existing
> documentation.  
> 
> For others (unlike David) who do not have the documentation
> memorized, the "logic:present" tag will take a "role" attribute:
> 
> Checks whether the currently authenticated user (if any) has been
> associated with any of the specified security roles. Use a
> comma-delimited list to check for multiple roles. Example:
>  code. 
> 
> (RT EXPR) 

Thanks for asking this question.  Sometimes, reading other peoples
questions help you answer things you didn't even know to ask.  It
isn't even about finding the documentation, it is about knowing what
question to find the answer for in the documentation.  Basically,
questions lead to ideas.  This one led to an idea for my
application.

David, you are definitly a monster contributor to this list, and I
definitley appreciate the responses you give, even if they force me
to think a little harder, read a little more or go the extra mile.
Thanks for pushing us.

Dan

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Daniel Allen, <[EMAIL PROTECTED]>
http://www.mojavelinux.com/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
"While they're pumping, you're soaking them" 
 -- Speed Loader TV Advert
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

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



RE: Fine Grained Access Control in Sturts

2003-03-20 Thread Robert Taylor
+1 ... and if the docs don't have the answer, 
there is always the source code and DTDs.

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 3:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Fine Grained Access Control in Sturts
> 
> 
> I don't have it memorized.  I just bookmark the taglib docs and 
> can quickly 
> send a link to an explanation.  A lot of questions could be avoided by 
> simply looking in the docs first :-).
> 
> David
> 
> 
> 
> >From: Mike Duffy <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >Subject: Re: Fine Grained Access Control in Sturts
> >Date: Thu, 20 Mar 2003 12:38:14 -0800 (PST)
> >
> >Thanks David.
> >
> >I always feel bad when I ask a question that is in the existing
> >documentation.
> >
> >For others (unlike David) who do not have the documentation
> >memorized, the "logic:present" tag will take a "role" attribute:
> >
> >Checks whether the currently authenticated user (if any) has been
> >associated with any of the specified security roles. Use a
> >comma-delimited list to check for multiple roles. Example:
> > code. 
> >
> >(RT EXPR)
> >
> >Thanks again.
> >
> >Mike
> >
> >
> >--- David Graham <[EMAIL PROTECTED]> wrote:
> > >
> >http://jakarta.apache.org/struts/userGuide/struts-logic.html#present
> > >
> > > David
> > >
> > >
> > >
> > > >From: Mike Duffy <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Users Mailing List"
> > > <[EMAIL PROTECTED]>
> > > >To: [EMAIL PROTECTED]
> > > >Subject: Fine Grained Access Control in Sturts
> > > >Date: Thu, 20 Mar 2003 12:23:07 -0800 (PST)
> > > >
> > > >Does anyone have any thoughts on fine grained access control in
> > > >Struts?
> > > >
> > > >Struts enables access control based on actions (see ?Struts in
> > > >Action?, Husted, et. al., pp 550-553), and most application
> > > servers
> > > >can protect resources based on realms/roles.
> > > >
> > > >But what about display options based on roles.  For example, if
> > > you
> > > >only wanted an ?Admin? link to appear if the user was an
> > > >administrator, what would be the best way to do this?
> > > >
> > > >You could make the ?role? an attribute of the user object and then
> > > do
> > > >a logic test for the appropriate role.  Or it might be even better
> > > to
> > > >write a logic tag that takes the user role as an attribute.  Any
> > > >thoughts?
> > > >
> > > >Thanks for your consideration.
> > > >
> > > >BTW.  The Husted book is a very good book.
> > > >
> > > >Mike
> > > >
> > > >
> > > >__
> > > >Do you Yahoo!?
> > > >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your
> > > desktop!
> > > >http://platinum.yahoo.com
> > > >
> > >
> > >-
> > > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> > >
> > > _
> > > Add photos to your messages with MSN 8. Get 2 months FREE*.
> > > http://join.msn.com/?page=features/featuredemail
> > >
> > >
> > >
> >-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > >
> >
> >
> >__
> >Do you Yahoo!?
> >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> >http://platinum.yahoo.com
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> _
> Protect your PC - get McAfee.com VirusScan Online  
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> -
> 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]



Re: Fine Grained Access Control in Sturts

2003-03-20 Thread David Graham
I don't have it memorized.  I just bookmark the taglib docs and can quickly 
send a link to an explanation.  A lot of questions could be avoided by 
simply looking in the docs first :-).

David



From: Mike Duffy <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Subject: Re: Fine Grained Access Control in Sturts
Date: Thu, 20 Mar 2003 12:38:14 -0800 (PST)
Thanks David.

I always feel bad when I ask a question that is in the existing
documentation.
For others (unlike David) who do not have the documentation
memorized, the "logic:present" tag will take a "role" attribute:
Checks whether the currently authenticated user (if any) has been
associated with any of the specified security roles. Use a
comma-delimited list to check for multiple roles. Example:
 code. 
(RT EXPR)

Thanks again.

Mike

--- David Graham <[EMAIL PROTECTED]> wrote:
>
http://jakarta.apache.org/struts/userGuide/struts-logic.html#present
>
> David
>
>
>
> >From: Mike Duffy <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List"
> <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Fine Grained Access Control in Sturts
> >Date: Thu, 20 Mar 2003 12:23:07 -0800 (PST)
> >
> >Does anyone have any thoughts on fine grained access control in
> >Struts?
> >
> >Struts enables access control based on actions (see ?Struts in
> >Action?, Husted, et. al., pp 550-553), and most application
> servers
> >can protect resources based on realms/roles.
> >
> >But what about display options based on roles.  For example, if
> you
> >only wanted an ?Admin? link to appear if the user was an
> >administrator, what would be the best way to do this?
> >
> >You could make the ?role? an attribute of the user object and then
> do
> >a logic test for the appropriate role.  Or it might be even better
> to
> >write a logic tag that takes the user role as an attribute.  Any
> >thoughts?
> >
> >Thanks for your consideration.
> >
> >BTW.  The Husted book is a very good book.
> >
> >Mike
> >
> >
> >__
> >Do you Yahoo!?
> >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your
> desktop!
> >http://platinum.yahoo.com
> >
>
>-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
> _
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
>
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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


Re: Fine Grained Access Control in Sturts

2003-03-20 Thread Max Cooper
You can use the logic tags to do something like this:


   Admin


This assumes you are using a security mechanism where
request.isUserInRole("admin") will return true when the user is in that
role. For that to work, you must use container-managed security or a
filter-based solution like http://securityfilter.sourceforge.net/.

-Max
shamelessly plugging SecurityFilter again :)

- Original Message -
From: "Mike Duffy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 12:23 PM
Subject: Fine Grained Access Control in Sturts


> Does anyone have any thoughts on fine grained access control in
> Struts?
>
> Struts enables access control based on actions (see "Struts in
> Action", Husted, et. al., pp 550-553), and most application servers
> can protect resources based on realms/roles.
>
> But what about display options based on roles.  For example, if you
> only wanted an "Admin" link to appear if the user was an
> administrator, what would be the best way to do this?
>
> You could make the "role" an attribute of the user object and then do
> a logic test for the appropriate role.  Or it might be even better to
> write a logic tag that takes the user role as an attribute.  Any
> thoughts?
>
> Thanks for your consideration.
>
> BTW.  The Husted book is a very good book.
>
> Mike
>
>
> __
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>
> -
> 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]



Re: Fine Grained Access Control in Sturts

2003-03-20 Thread Mike Duffy
Thanks David.

I always feel bad when I ask a question that is in the existing
documentation.  

For others (unlike David) who do not have the documentation
memorized, the "logic:present" tag will take a "role" attribute:

Checks whether the currently authenticated user (if any) has been
associated with any of the specified security roles. Use a
comma-delimited list to check for multiple roles. Example:
 code. 

(RT EXPR) 

Thanks again.

Mike


--- David Graham <[EMAIL PROTECTED]> wrote:
>
http://jakarta.apache.org/struts/userGuide/struts-logic.html#present
> 
> David
> 
> 
> 
> >From: Mike Duffy <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List"
> <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Fine Grained Access Control in Sturts
> >Date: Thu, 20 Mar 2003 12:23:07 -0800 (PST)
> >
> >Does anyone have any thoughts on fine grained access control in
> >Struts?
> >
> >Struts enables access control based on actions (see ?Struts in
> >Action?, Husted, et. al., pp 550-553), and most application
> servers
> >can protect resources based on realms/roles.
> >
> >But what about display options based on roles.  For example, if
> you
> >only wanted an ?Admin? link to appear if the user was an
> >administrator, what would be the best way to do this?
> >
> >You could make the ?role? an attribute of the user object and then
> do
> >a logic test for the appropriate role.  Or it might be even better
> to
> >write a logic tag that takes the user role as an attribute.  Any
> >thoughts?
> >
> >Thanks for your consideration.
> >
> >BTW.  The Husted book is a very good book.
> >
> >Mike
> >
> >
> >__
> >Do you Yahoo!?
> >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your
> desktop!
> >http://platinum.yahoo.com
> >
>
>-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 
> _
> Add photos to your messages with MSN 8. Get 2 months FREE*.  
> http://join.msn.com/?page=features/featuredemail
> 
> 
>
-
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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



RE: Fine Grained Access Control in Sturts

2003-03-20 Thread Mike Jasnowski
I've used something like you describe, thought not unique to struts,
prototype similar to this:

 
   
 

 A few issues / unresolved items were that it didn't by itself provide a
good way to do granular authorization for many UI items. For example if you
had several links on a page that you wanted to protect, you had to code this
tag around each link, each one may have unique security requirements. It can
become a maintenance hassle.

 Second was that sometimes I found myself testing the same thing a couple
times on a page. This instance may have been unique to this application, but
I would have like to cache a previous check on the same page so as not to
have to make calls all the way down the wire to see if the test was true.


-Original Message-
From: Mike Duffy [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 3:23 PM
To: [EMAIL PROTECTED]
Subject: Fine Grained Access Control in Sturts


Does anyone have any thoughts on fine grained access control in
Struts?

Struts enables access control based on actions (see Struts in
Action, Husted, et. al., pp 550-553), and most application servers
can protect resources based on realms/roles.

But what about display options based on roles.  For example, if you
only wanted an Admin link to appear if the user was an
administrator, what would be the best way to do this?

You could make the role an attribute of the user object and then do
a logic test for the appropriate role.  Or it might be even better to
write a logic tag that takes the user role as an attribute.  Any
thoughts?

Thanks for your consideration.

BTW.  The Husted book is a very good book.

Mike


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

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



Re: Fine Grained Access Control in Sturts

2003-03-20 Thread David Graham
http://jakarta.apache.org/struts/userGuide/struts-logic.html#present

David



From: Mike Duffy <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Fine Grained Access Control in Sturts
Date: Thu, 20 Mar 2003 12:23:07 -0800 (PST)
Does anyone have any thoughts on fine grained access control in
Struts?
Struts enables access control based on actions (see ?Struts in
Action?, Husted, et. al., pp 550-553), and most application servers
can protect resources based on realms/roles.
But what about display options based on roles.  For example, if you
only wanted an ?Admin? link to appear if the user was an
administrator, what would be the best way to do this?
You could make the ?role? an attribute of the user object and then do
a logic test for the appropriate role.  Or it might be even better to
write a logic tag that takes the user role as an attribute.  Any
thoughts?
Thanks for your consideration.

BTW.  The Husted book is a very good book.

Mike

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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