RE: security framework!!! (Addendum to my previous post)

[as as]

Hi,
Has anyone tried filters framework ( tag in web.xml) in struts for role based 
access to webpages in a enterprise wide application...deployed in weblogic...we tried 
this and seems each sub-application needs a differenet, its own web.xml and  a single 
integrated web.xml..
Any workarounds...
Thanks,
Sam.
(Basically, in our lare web app, we want to allow different users (admin, user, etc) 
access to different pages (password reset, etc) based on his privileges
 
Thanks!
 
( I am quoting below.
http://info.borland.com/techpubs/jbuilder/jbuilder8/webapps/webapp_dd_editor.html#filters
that i did find some related info, though)


as as <[EMAIL PROTECTED]> wrote:InteresTing discussion.Is there more website links on 
the same

Thanks!

"Craig R. McClanahan" wrote:
(Jumping in late, and trying to catch up on several hundred email messages in my
STRUTS-USER folder, but better late than never ...)

Quoting David Friedman :

> Adam,
> 
> With my structure, I might have to become a particular reseller, then flip
> into a customer of his/hers, then become one of their client accounts to
> look into a reported problem. I worry about login identities for the
> following reasons:
> 
> Using a JAAS login, my principal would be fixed (set in stone) for my
> session. Then, I couldn't be able to use the 'roles' settings inside
> Struts, Tiles, and JSPs to control content.
> 
> Without using a JAAS login, I also become unable to use 'roles' in Tiles and
> JSPs to control content.
> 
> Without having any theories on how to successfully (and without much
> alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at
> a loss how to change my identity/roles
> 
> If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
> object then added my own push/pop/depth methods, I see how I could use roles
> in all of those places.
> 
> Knowing all of the above gory details, do you (or anyone) have any
> suggestions on how to make things cleaner while using roles in all of those
> places with the various levels of control I need to exert (albeit probably
> rarely switching roles) ?
> 

David,

If I understand what you're after correctly, the design you have proposed is
pretty troubling from a security perspective. In particular, consider what
happens if your system is also logging who made what changes (so you can go
audit things later). If users are allowed to impersonate each other, you have
no accountability at all. From a security perspective, it is much better that
each user have a unique individual identity, and that all actions taken by that
individual are associated with that identity.

Going back to your problem, then, have you considered that an individual user
can have more than one role? For example, if you have "manager" and "employee"
roles, you (as a manager) can have *both* of them assigned to your
UserPrincipal, and therefore you can do anything that either a "manager" or an
"employee" can do, while employees cannot execute manager functions. This is
the way roles are typically used in J2EE applications, and it maps just as well
to your five-level hierarchy as it does a two-level one.

> Thanks (to all) for any constructive suggestions,
> David

Craig McCanahan



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

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

RE: security framework!!!

[as as]

InteresTing discussion.Is there more website links on the same
 
Thanks!

"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
(Jumping in late, and trying to catch up on several hundred email messages in my
STRUTS-USER folder, but better late than never ...)

Quoting David Friedman :

> Adam,
> 
> With my structure, I might have to become a particular reseller, then flip
> into a customer of his/hers, then become one of their client accounts to
> look into a reported problem. I worry about login identities for the
> following reasons:
> 
> Using a JAAS login, my principal would be fixed (set in stone) for my
> session. Then, I couldn't be able to use the 'roles' settings inside
> Struts, Tiles, and JSPs to control content.
> 
> Without using a JAAS login, I also become unable to use 'roles' in Tiles and
> JSPs to control content.
> 
> Without having any theories on how to successfully (and without much
> alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at
> a loss how to change my identity/roles
> 
> If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
> object then added my own push/pop/depth methods, I see how I could use roles
> in all of those places.
> 
> Knowing all of the above gory details, do you (or anyone) have any
> suggestions on how to make things cleaner while using roles in all of those
> places with the various levels of control I need to exert (albeit probably
> rarely switching roles) ?
> 

David,

If I understand what you're after correctly, the design you have proposed is
pretty troubling from a security perspective. In particular, consider what
happens if your system is also logging who made what changes (so you can go
audit things later). If users are allowed to impersonate each other, you have
no accountability at all. From a security perspective, it is much better that
each user have a unique individual identity, and that all actions taken by that
individual are associated with that identity.

Going back to your problem, then, have you considered that an individual user
can have more than one role? For example, if you have "manager" and "employee"
roles, you (as a manager) can have *both* of them assigned to your
UserPrincipal, and therefore you can do anything that either a "manager" or an
"employee" can do, while employees cannot execute manager functions. This is
the way roles are typically used in J2EE applications, and it maps just as well
to your five-level hierarchy as it does a two-level one.

> Thanks (to all) for any constructive suggestions,
> David

Craig McCanahan



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

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

RE: security framework!!!

[Craig R. McClanahan]

(Jumping in late, and trying to catch up on several hundred email messages in my
STRUTS-USER folder, but better late than never ...)

Quoting David Friedman <[EMAIL PROTECTED]>:

> Adam,
> 
> With my structure, I might have to become a particular reseller, then flip
> into a customer of his/hers, then become one of their client accounts to
> look into a reported problem.  I worry about login identities for the
> following reasons:
> 
> Using a JAAS login, my principal would be fixed (set in stone) for my
> session.  Then, I couldn't be able to use the 'roles' settings inside
> Struts, Tiles, and JSPs to control content.
> 
> Without using a JAAS login, I also become unable to use 'roles' in Tiles and
> JSPs to control content.
> 
> Without having any theories on how to successfully (and without much
> alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at
> a loss how to change my identity/roles
> 
> If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
> object then added my own push/pop/depth methods, I see how I could use roles
> in all of those places.
> 
> Knowing all of the above gory details, do you (or anyone) have any
> suggestions on how to make things cleaner while using roles in all of those
> places with the various levels of control I need to exert (albeit probably
> rarely switching roles) ?
> 

David,

If I understand what you're after correctly, the design you have proposed is
pretty troubling from a security perspective.  In particular, consider what
happens if your system is also logging who made what changes (so you can go
audit things later).  If users are allowed to impersonate each other, you have
no accountability at all.  From a security perspective, it is much better that
each user have a unique individual identity, and that all actions taken by that
individual are associated with that identity.

Going back to your problem, then, have you considered that an individual user
can have more than one role?  For example, if you have "manager" and "employee"
roles, you (as a manager) can have *both* of them assigned to your
UserPrincipal, and therefore you can do anything that either a "manager" or an
"employee" can do, while employees cannot execute manager functions.  This is
the way roles are typically used in J2EE applications, and it maps just as well
to your five-level hierarchy as it does a two-level one.

> Thanks (to all) for any constructive suggestions,
> David

Craig McCanahan



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

Re: security framework!!!

[as as]

r your User_Role join table and
> use a standard realm. Be aware that you might end up wasting a lot of memory
> if each user ends up with a ton of roles and your realm loads them all into
> memory during authentication.
> 
> I have not done anything with JAAS, so perhaps there is a better solution
> available using JAAS technology. It would be great to hear from someone that
> knows of a good JAAS-based solution. David's problem of entity-based (rather
> than system-wide) responsibilities is a very common one.
> 
> -Max
> 
> - Original Message - 
> From: "David Friedman" 
> To: "Struts Users Mailing List" 
> Sent: Wednesday, March 17, 2004 5:48 PM
> Subject: RE: security framework!!!
> 
> 
> 
>>Adam,
>>
>>With my structure, I might have to become a particular reseller, then flip
>>into a customer of his/hers, then become one of their client accounts to
>>look into a reported problem. I worry about login identities for the
>>following reasons:
>>
>>Using a JAAS login, my principal would be fixed (set in stone) for my
>>session. Then, I couldn't be able to use the 'roles' settings inside
>>Struts, Tiles, and JSPs to control content.
>>
>>Without using a JAAS login, I also become unable to use 'roles' in Tiles
> 
> and
> 
>>JSPs to control content.
>>
>>Without having any theories on how to successfully (and without much
>>alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm
> 
> at
> 
>>a loss how to change my identity/roles
>>
>>If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
>>object then added my own push/pop/depth methods, I see how I could use
> 
> roles
> 
>>in all of those places.
>>
>>Knowing all of the above gory details, do you (or anyone) have any
>>suggestions on how to make things cleaner while using roles in all of
> 
> those
> 
>>places with the various levels of control I need to exert (albeit probably
>>rarely switching roles) ?
>>
>>Thanks (to all) for any constructive suggestions,
>>David
>>
>>-Original Message-
>>From: Adam Hardy [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, March 17, 2004 6:51 PM
>>To: Struts Users Mailing List
>>Subject: Re: security framework!!!
>>
>>
>>I don't see your requirement for replacing the principal when the admin
>>wants to 'become' someone else. What are you envisaging that such a
>>technique would bring? How are you planning for the administrator to get
>>his/her original user back?
>>
>>I'm pretty confident you can accomplish this through the judicious use
>>of roles. OK, you'll need quite a few admittedly.
>>
>>Unless I've missed a point somewhere.
>>
>>On 03/17/2004 11:54 PM David Friedman wrote:
>>
>>>Andy,
>>>
>>>My personal project will have 5 distinct levels (a business of my
>>>own, someday). The lowest level has individual powers, nothing
>>>shared. It makes that particular level analogous to a shopping cart
>>>user: his/her 'stuff' only. The groups/levels are in order from
>>>highest ability to lowest (the individual user). They can only
>>>become or manipulate the level below them directly, unless they
>>>assume the identity of an account they manage to review/fix/look into
>>> something. The descriptions of the levels follow:
>>>
>>>Senior Group level "administrators". For all intent and purposes,
>>>that is me and my team. We can add/edit/remove/become/lock-down any
>>>reseller account (only upon request, of course).
>>>
>>>Junior Group level - "reseller company". A reseller company has a
>>>group of accounts (one or more) who can
>>>add/edit/remove/become/lock-down any of their own customer accounts
>>>(hopefully only upon request).
>>>
>>>Sophomore Group level - "customer company". A customer company is a
>>> business sold to by a "reseller". This group can add
>>>add/edit/remove/become/lock-down any of their own "clients" (again,
>>>hopefully only upon request).
>>>
>>>Freshman Group level - "client". A "client" is a corporate entity
>>>receiving services from their particular vendor, an above-mentioned
>>>"customer company". This group of accounts can add/edit/remove their
>>> own list of employees (i.e. "end users"). They have some features
>>>specific

Re: security framework!!!

[Adam Hardy]

knows of a good JAAS-based solution. David's problem of entity-based (rather
than system-wide) responsibilities is a very common one.
-Max

- Original Message - 
From: "David Friedman" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 5:48 PM
Subject: RE: security framework!!!



Adam,

With my structure, I might have to become a particular reseller, then flip
into a customer of his/hers, then become one of their client accounts to
look into a reported problem.  I worry about login identities for the
following reasons:
Using a JAAS login, my principal would be fixed (set in stone) for my
session.  Then, I couldn't be able to use the 'roles' settings inside
Struts, Tiles, and JSPs to control content.
Without using a JAAS login, I also become unable to use 'roles' in Tiles
and

JSPs to control content.

Without having any theories on how to successfully (and without much
alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm
at

a loss how to change my identity/roles

If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
object then added my own push/pop/depth methods, I see how I could use
roles

in all of those places.

Knowing all of the above gory details, do you (or anyone) have any
suggestions on how to make things cleaner while using roles in all of
those

places with the various levels of control I need to exert (albeit probably
rarely switching roles) ?
Thanks (to all) for any constructive suggestions,
David
-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 6:51 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!
I don't see your requirement for replacing the principal when the admin
wants to 'become' someone else. What are you envisaging that such a
technique would bring? How are you planning for the administrator to get
his/her original user back?
I'm pretty confident you can accomplish this through the judicious use
of roles. OK, you'll need quite a few admittedly.
Unless I've missed a point somewhere.

On 03/17/2004 11:54 PM David Friedman wrote:

Andy,

My personal project will have 5 distinct levels (a business of my
own, someday).  The lowest level has individual powers, nothing
shared.  It makes that particular level analogous to a shopping cart
user: his/her 'stuff' only.  The groups/levels are in order from
highest ability to lowest (the individual user).  They can only
become or manipulate the level below them directly, unless they
assume the identity of an account they manage to review/fix/look into
something.  The descriptions of the levels follow:
Senior Group level "administrators".  For all intent and purposes,
that is me and my team.  We can add/edit/remove/become/lock-down any
reseller account (only upon request, of course).
Junior Group level - "reseller company".  A reseller company has a
group of accounts (one or more) who can
add/edit/remove/become/lock-down any of their own customer accounts
(hopefully only upon request).
Sophomore Group level - "customer company".  A customer company is a
business sold to by a "reseller".  This group can add
add/edit/remove/become/lock-down any of their own "clients" (again,
hopefully only upon request).
Freshman Group level - "client".  A "client" is a corporate entity
receiving services from their particular vendor, an above-mentioned
"customer company".  This group of accounts can add/edit/remove their
own list of employees (i.e. "end users").  They have some features
specific to them as well as being able to enter information similar
to their individual employees.
(Lowest) User level - "employee".  An "employee" is an individual
account under a corporate entity (in a "client").  They have
individual duties and can enter data.  Some of their activities may
end up going to a manager (at the "client" level) for approval,
depending on the activity.  Essentially, all of the work they do can
be seen by no one else (though a manager might need to approve
certain types of request).
Regards, David

-Original Message- From: Adam Hardy
[mailto:[EMAIL PROTECTED] Sent: Monday, March 15,
2004 10:28 AM To: Struts Users Mailing List Subject: Re: security
framework!!!
On 03/15/2004 03:00 PM David Friedman wrote:


I should have explained this a bit better.  Each level is like a
company or organization.  It has it's own group of parties to
maintain but can be managed by one or more managers.  The managers
share group responsibility. Only the user at the very bottom rung
has an interface which only that user can use.


What do you mean by that last sentence? Why can't a manager use that
interface too? Surely it depends on roles?

Everyone above

Re: security framework!!!

[Max Cooper]

David,

I think it is unusual to design the security system such that you must
switch identities to meet your requirements. It may be worth rethinking your
security system design so that a user will remain who they are, but be
allowed to access resources that fall under their responsibility.

As a generic example, it is customary for a user who is a system
administrator to be able to change the password for any user in the system.
The administrator does not actually switch their identity in the process,
but rather they are granted access to do the password change by virtue of
having some kind of "sysadmin" role.

I realize that your business domain is more complex than that, but I think
it would be useful to think about it in terms of a user having access to
things without having to switch their identity. Since you can't use simple
system-wide roles like "admin" due to the structure of responsibilities
dictated by your business domain (client can add and edit their employees,
but not the employees of another client), you have to do something special.

One option is to map (flatten) the complex domain to a flat set of roles.
For example, client "Bob" has role "client1234.client", where "client1234"
is the client that Bob is a "client" for. You might also have roles like
"admin", "reseller33", "customer128", "client1234.employee", etc. The
numbers in in the role names are the "id" of the entity they represent. This
requires programmatic security in a sense, since you will need to determine
what role to check for at runtime. But you will still be able to use the
J2EE standard request.isUserInRole() call to determine membership for the
currently authenticated user.

Another option is to do thoroughly programmatic security, where you still
use container-managed security for authentication (is this Bob?) and write
code to do the authorization (Bob wants to edit a user account in the
context of the client with id = 1234, is Bob allowed to do that?) without
mapping it to a role name. Perhaps your realm could create Principal objects
such that the application code can "ask" the Principal if they can do
something.

Bob will very likely have other responsibilties (the same stuff the
employees do) that you might wish to control with a single role
"client1234.employee". In that case, Bob would have both the
"client1234.client" and "client1234.employee" roles. Alternately, you could
identify a set of roles that would allow a user to do that stuff:
"client1234.employee", "client1234.client", "customer128", "reseller33",
etc. where client1234 is under the customer128 account, which in turn is
under the reseller33 account. If Bob had any of those roles, he would be
allowed to do "employee" stuff in the context of client1234.

A single user can have an unlimited number of roles, and you can write your
own security realm to read that information from a variety of tables in the
database. Or write a view in the database for your User_Role join table and
use a standard realm. Be aware that you might end up wasting a lot of memory
if each user ends up with a ton of roles and your realm loads them all into
memory during authentication.

I have not done anything with JAAS, so perhaps there is a better solution
available using JAAS technology. It would be great to hear from someone that
knows of a good JAAS-based solution. David's problem of entity-based (rather
than system-wide) responsibilities is a very common one.

-Max

- Original Message - 
From: "David Friedman" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 5:48 PM
Subject: RE: security framework!!!


> Adam,
>
> With my structure, I might have to become a particular reseller, then flip
> into a customer of his/hers, then become one of their client accounts to
> look into a reported problem.  I worry about login identities for the
> following reasons:
>
> Using a JAAS login, my principal would be fixed (set in stone) for my
> session.  Then, I couldn't be able to use the 'roles' settings inside
> Struts, Tiles, and JSPs to control content.
>
> Without using a JAAS login, I also become unable to use 'roles' in Tiles
and
> JSPs to control content.
>
> Without having any theories on how to successfully (and without much
> alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm
at
> a loss how to change my identity/roles
>
> If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
> object then added my own push/pop/depth methods, I see how I could use
roles
> in all of those places.
>
> Knowing all of the above gory details, do you (or any

RE: security framework!!!

[David Friedman]

Adam,

With my structure, I might have to become a particular reseller, then flip
into a customer of his/hers, then become one of their client accounts to
look into a reported problem.  I worry about login identities for the
following reasons:

Using a JAAS login, my principal would be fixed (set in stone) for my
session.  Then, I couldn't be able to use the 'roles' settings inside
Struts, Tiles, and JSPs to control content.

Without using a JAAS login, I also become unable to use 'roles' in Tiles and
JSPs to control content.

Without having any theories on how to successfully (and without much
alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at
a loss how to change my identity/roles

If I made a filter to wrapper the Request with a HTTPServletRequestWrapper
object then added my own push/pop/depth methods, I see how I could use roles
in all of those places.

Knowing all of the above gory details, do you (or anyone) have any
suggestions on how to make things cleaner while using roles in all of those
places with the various levels of control I need to exert (albeit probably
rarely switching roles) ?

Thanks (to all) for any constructive suggestions,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 6:51 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!


I don't see your requirement for replacing the principal when the admin
wants to 'become' someone else. What are you envisaging that such a
technique would bring? How are you planning for the administrator to get
his/her original user back?

I'm pretty confident you can accomplish this through the judicious use
of roles. OK, you'll need quite a few admittedly.

Unless I've missed a point somewhere.

On 03/17/2004 11:54 PM David Friedman wrote:
> Andy,
>
> My personal project will have 5 distinct levels (a business of my
> own, someday).  The lowest level has individual powers, nothing
> shared.  It makes that particular level analogous to a shopping cart
> user: his/her 'stuff' only.  The groups/levels are in order from
> highest ability to lowest (the individual user).  They can only
> become or manipulate the level below them directly, unless they
> assume the identity of an account they manage to review/fix/look into
>  something.  The descriptions of the levels follow:
>
> Senior Group level "administrators".  For all intent and purposes,
> that is me and my team.  We can add/edit/remove/become/lock-down any
> reseller account (only upon request, of course).
>
> Junior Group level - "reseller company".  A reseller company has a
> group of accounts (one or more) who can
> add/edit/remove/become/lock-down any of their own customer accounts
> (hopefully only upon request).
>
> Sophomore Group level - "customer company".  A customer company is a
>  business sold to by a "reseller".  This group can add
> add/edit/remove/become/lock-down any of their own "clients" (again,
> hopefully only upon request).
>
> Freshman Group level - "client".  A "client" is a corporate entity
> receiving services from their particular vendor, an above-mentioned
> "customer company".  This group of accounts can add/edit/remove their
>  own list of employees (i.e. "end users").  They have some features
> specific to them as well as being able to enter information similar
> to their individual employees.
>
> (Lowest) User level - "employee".  An "employee" is an individual
> account under a corporate entity (in a "client").  They have
> individual duties and can enter data.  Some of their activities may
> end up going to a manager (at the "client" level) for approval,
> depending on the activity.  Essentially, all of the work they do can
> be seen by no one else (though a manager might need to approve
> certain types of request).
>
> Regards, David
>
> -Original Message- From: Adam Hardy
> [mailto:[EMAIL PROTECTED] Sent: Monday, March 15,
> 2004 10:28 AM To: Struts Users Mailing List Subject: Re: security
> framework!!!
>
>
> On 03/15/2004 03:00 PM David Friedman wrote:
>
>> I should have explained this a bit better.  Each level is like a
>> company or organization.  It has it's own group of parties to
>> maintain but can be managed by one or more managers.  The managers
>>  share group responsibility. Only the user at the very bottom rung
>>  has an interface which only that user can use.
>
>
> What do you mean by that last sentence? Why can't a manager use that
>  interface too? Surely it depends on roles?
>
>> Everyone above it is some sort of manager for mainta

Re: security framework!!!

[Adam Hardy]

I don't see your requirement for replacing the principal when the admin
wants to 'become' someone else. What are you envisaging that such a
technique would bring? How are you planning for the administrator to get
his/her original user back?
I'm pretty confident you can accomplish this through the judicious use
of roles. OK, you'll need quite a few admittedly.
Unless I've missed a point somewhere.

On 03/17/2004 11:54 PM David Friedman wrote:
Andy,

My personal project will have 5 distinct levels (a business of my 
own, someday).  The lowest level has individual powers, nothing 
shared.  It makes that particular level analogous to a shopping cart 
user: his/her 'stuff' only.  The groups/levels are in order from 
highest ability to lowest (the individual user).  They can only 
become or manipulate the level below them directly, unless they 
assume the identity of an account they manage to review/fix/look into
 something.  The descriptions of the levels follow:

Senior Group level "administrators".  For all intent and purposes, 
that is me and my team.  We can add/edit/remove/become/lock-down any 
reseller account (only upon request, of course).

Junior Group level - "reseller company".  A reseller company has a 
group of accounts (one or more) who can 
add/edit/remove/become/lock-down any of their own customer accounts 
(hopefully only upon request).

Sophomore Group level - "customer company".  A customer company is a
 business sold to by a "reseller".  This group can add 
add/edit/remove/become/lock-down any of their own "clients" (again, 
hopefully only upon request).

Freshman Group level - "client".  A "client" is a corporate entity 
receiving services from their particular vendor, an above-mentioned 
"customer company".  This group of accounts can add/edit/remove their
 own list of employees (i.e. "end users").  They have some features 
specific to them as well as being able to enter information similar 
to their individual employees.

(Lowest) User level - "employee".  An "employee" is an individual 
account under a corporate entity (in a "client").  They have 
individual duties and can enter data.  Some of their activities may 
end up going to a manager (at the "client" level) for approval, 
depending on the activity.  Essentially, all of the work they do can 
be seen by no one else (though a manager might need to approve 
certain types of request).

Regards, David

-----Original Message- From: Adam Hardy 
[mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 
2004 10:28 AM To: Struts Users Mailing List Subject: Re: security 
framework!!!

On 03/15/2004 03:00 PM David Friedman wrote:

I should have explained this a bit better.  Each level is like a 
company or organization.  It has it's own group of parties to 
maintain but can be managed by one or more managers.  The managers
 share group responsibility. Only the user at the very bottom rung
 has an interface which only that user can use.


What do you mean by that last sentence? Why can't a manager use that
 interface too? Surely it depends on roles?
Everyone above it is some sort of manager for maintaining there 
shared group (separate from other resellers, or separate from 
other).

admin--- reseller1 (admin1, admin2, admin3) -- customer1 customer2
 customer3 reseller2 (admin4) - customer4 customer5 reseller3 
(admin5, admin6) - customer6 reseller7 (admin7, admin8, admin9) - 
customer7 customer8

In the above tree, the customer(s) have a group of their own admins
 plus individual employees (who have no shared responsibilities).
I know this sounds like I should use pow2acl but it doesn't seem to
 have anything for replacing the Principal so I could become a 
user, nor does it appear to have anything to let me hook SSLext 
into it to ensure good http/https lock-downs.

Do you have any hints/suggestions for a better methodology/way?

Regards, David

-Original Message- From: Adam Hardy 
[mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 
2004 4:25 AM To: Struts Users Mailing List Subject: Re: security 
framework!!!

Right, I get it. So you not only want the higher level user to take
 on the lower level user's role, you want them to have their 
complete ID or username etc.

Tricky!

I think alot depends on what kind of use you have for the user 
info. Is it purely roles that are important here? Or is there 
ownership too? I mean, one user can see his / her stuff, which is 
not accessible to another user of equal level?

On 03/15/2004 03:39 AM David Friedman wrote:


Jason,

They might need to go into the account underneath them to fix 
something (if they are asked) and won't know the password 
(encrypted).  The admin might need to fix something for a 
reseller's client made us look into (admin -> reseller -> client 
-> manager -> e

RE: security framework!!!

[David Friedman]

Andy,

My personal project will have 5 distinct levels (a business of my own,
someday).  The lowest level has individual powers, nothing shared.  It makes
that particular level analogous to a shopping cart user: his/her 'stuff'
only.  The groups/levels are in order from highest ability to lowest (the
individual user).  They can only become or manipulate the level below them
directly, unless they assume the identity of an account they manage to
review/fix/look into something.  The descriptions of the levels follow:

Senior Group level "administrators".  For all intent and purposes, that is
me and my team.  We can add/edit/remove/become/lock-down any reseller
account (only upon request, of course).

Junior Group level - "reseller company".  A reseller company has a group of
accounts (one or more) who can add/edit/remove/become/lock-down any of their
own customer accounts (hopefully only upon request).

Sophomore Group level - "customer company".  A customer company is a
business sold to by a "reseller".  This group can add
add/edit/remove/become/lock-down any of their own "clients" (again,
hopefully only upon request).

Freshman Group level - "client".  A "client" is a corporate entity receiving
services from their particular vendor, an above-mentioned "customer
company".  This group of accounts can add/edit/remove their own list of
employees (i.e. "end users").  They have some features specific to them as
well as being able to enter information similar to their individual
employees.

(Lowest) User level - "employee".  An "employee" is an individual account
under a corporate entity (in a "client").  They have individual duties and
can enter data.  Some of their activities may end up going to a manager (at
the "client" level) for approval, depending on the activity.  Essentially,
all of the work they do can be seen by no one else (though a manager might
need to approve certain types of request).

Regards,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 10:28 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!


On 03/15/2004 03:00 PM David Friedman wrote:
> I should have explained this a bit better.  Each level is like a company
or
> organization.  It has it's own group of parties to maintain but can be
> managed by one or more managers.  The managers share group responsibility.
> Only the user at the very bottom rung has an interface which only that
user
> can use.

What do you mean by that last sentence? Why can't a manager use that
interface too? Surely it depends on roles?

 >Everyone above it is some sort of manager for maintaining there
> shared group (separate from other resellers, or separate from other).
>
> admin--- reseller1 (admin1, admin2, admin3) -- customer1
>   customer2
>   customer3
>  reseller2 (admin4) - customer4
>   customer5
>  reseller3 (admin5, admin6) - customer6
>  reseller7 (admin7, admin8, admin9) - customer7
>   customer8
>
> In the above tree, the customer(s) have a group of their own admins plus
> individual employees (who have no shared responsibilities).
>
> I know this sounds like I should use pow2acl but it doesn't seem to have
> anything for replacing the Principal so I could become a user, nor does it
> appear to have anything to let me hook SSLext into it to ensure good
> http/https lock-downs.
>
> Do you have any hints/suggestions for a better methodology/way?
>
> Regards,
> David
>
> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 15, 2004 4:25 AM
> To: Struts Users Mailing List
> Subject: Re: security framework!!!
>
>
> Right, I get it. So you not only want the higher level user to take on
> the lower level user's role, you want them to have their complete ID or
> username etc.
>
> Tricky!
>
> I think alot depends on what kind of use you have for the user info. Is
> it purely roles that are important here? Or is there ownership too? I
> mean, one user can see his / her stuff, which is not accessible to
> another user of equal level?
>
> On 03/15/2004 03:39 AM David Friedman wrote:
>
>>Jason,
>>
>>They might need to go into the account underneath them to fix something
>
> (if
>
>>they are asked) and won't know the password (encrypted).  The admin might
>>need to fix something for a reseller's client made us look into (admin ->
>>reseller -> client -> manager -> employee).  I've had a few project

RE: security framework!!!

[Benz Lim]

Hi David,

Would this be consider a user delegation model that you are trying to built?
I came across this article
Security in Struts: User Delegation Made Possible
when doing my research not sure would it help you

Thought just let you take a look see if it help... as I myself is oso
a noob in struts...
http://www.onjava.com/pub/a/onjava/2004/02/18/strutssecurity.html


God Bless,
Benz Lim

-Original Message-
From: David Friedman [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 10:00 PM
To: Struts Users Mailing List
Subject: RE: security framework!!!


Adam,

I should have explained this a bit better.  Each level is like a company or
organization.  It has it's own group of parties to maintain but can be
managed by one or more managers.  The managers share group responsibility.
Only the user at the very bottom rung has an interface which only that user
can use.  Everyone above it is some sort of manager for maintaining there
shared group (separate from other resellers, or separate from other).

admin--- reseller1 (admin1, admin2, admin3) -- customer1
  customer2
  customer3
 reseller2 (admin4) - customer4
  customer5
 reseller3 (admin5, admin6) - customer6
 reseller7 (admin7, admin8, admin9) - customer7
  customer8

In the above tree, the customer(s) have a group of their own admins plus
individual employees (who have no shared responsibilities).

I know this sounds like I should use pow2acl but it doesn't seem to have
anything for replacing the Principal so I could become a user, nor does it
appear to have anything to let me hook SSLext into it to ensure good
http/https lock-downs.

Do you have any hints/suggestions for a better methodology/way?

Regards,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 4:25 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!


Right, I get it. So you not only want the higher level user to take on
the lower level user's role, you want them to have their complete ID or
username etc.

Tricky!

I think alot depends on what kind of use you have for the user info. Is
it purely roles that are important here? Or is there ownership too? I
mean, one user can see his / her stuff, which is not accessible to
another user of equal level?

On 03/15/2004 03:39 AM David Friedman wrote:
> Jason,
>
> They might need to go into the account underneath them to fix something
(if
> they are asked) and won't know the password (encrypted).  The admin might
> need to fix something for a reseller's client made us look into (admin ->
> reseller -> client -> manager -> employee).  I've had a few projects where
> someone 2 levels under asks for help from the level immediately above
them.
> Then it goes up one and up again back to me.  Rather than make interfaces
> for everyone for everything, I prefer the idea of "su'ing" into the
account
> to fix something.  So, I might have to 'become' the reseller (I'm the
> admin), then become a client, then become a manager then become an
employee
> to look at or fix something for them.
>
> Regards,
> David
>
> -Original Message-
> From: Jason Lea [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 14, 2004 6:49 PM
> To: Struts Users Mailing List
> Subject: Re: security framework!!!
>
>
> David Friedman wrote:
>
>
>>I've also been looking into security frameworks and the only solutions
I've
>>really found are:
>>
>>1. Standard (container) JAAS
>>2. SecurityFilter http://securityfilter.sourceforge.net
>>3. Pow2ACL http://pow2acl.sourceforge.net/
>>
>>I was hoping, at some point, to use an SSL switching feature such as
>
> SSLext.
>
>>>From my research, Pow2ACL and SecurityFilter won't work that way.
>>SecurityFilter has a note that certain 'elements' could be used for it but
>>the current code makes no use of them in that manner.  As for Pow2ACL, I
>>didn't find anything suggesting how to use it in that way either.
>>
>>My bigger problem is my scenario, which no one supports.  I'd like to
allow
>>manager accounts to become one of if it's sub-accounts.  My system would
>>support at least 5 levels where 4 could 'drill down' and back up again:
>>admin, reseller, client, manager, employee (bottom feeder, no managerial
>>tools and no popping into their accounts).  Since there is no easily way
to
>>
>>
>
> Trying to figure out what you are asking here can you give an example?
>
> If you have the following:
> 1. User Manfred is a manager
> 2. User Emil

Re: security framework!!!

[Adam Hardy]

On 03/15/2004 03:00 PM David Friedman wrote:
I should have explained this a bit better.  Each level is like a company or
organization.  It has it's own group of parties to maintain but can be
managed by one or more managers.  The managers share group responsibility.
Only the user at the very bottom rung has an interface which only that user
can use.  
What do you mean by that last sentence? Why can't a manager use that 
interface too? Surely it depends on roles?

>Everyone above it is some sort of manager for maintaining there
shared group (separate from other resellers, or separate from other).

admin--- reseller1 (admin1, admin2, admin3) -- customer1
  customer2
  customer3
 reseller2 (admin4) - customer4
  customer5
 reseller3 (admin5, admin6) - customer6
 reseller7 (admin7, admin8, admin9) - customer7
  customer8
In the above tree, the customer(s) have a group of their own admins plus
individual employees (who have no shared responsibilities).
I know this sounds like I should use pow2acl but it doesn't seem to have
anything for replacing the Principal so I could become a user, nor does it
appear to have anything to let me hook SSLext into it to ensure good
http/https lock-downs.
Do you have any hints/suggestions for a better methodology/way?

Regards,
David
-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 4:25 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!
Right, I get it. So you not only want the higher level user to take on
the lower level user's role, you want them to have their complete ID or
username etc.
Tricky!

I think alot depends on what kind of use you have for the user info. Is
it purely roles that are important here? Or is there ownership too? I
mean, one user can see his / her stuff, which is not accessible to
another user of equal level?
On 03/15/2004 03:39 AM David Friedman wrote:

Jason,

They might need to go into the account underneath them to fix something
(if

they are asked) and won't know the password (encrypted).  The admin might
need to fix something for a reseller's client made us look into (admin ->
reseller -> client -> manager -> employee).  I've had a few projects where
someone 2 levels under asks for help from the level immediately above
them.

Then it goes up one and up again back to me.  Rather than make interfaces
for everyone for everything, I prefer the idea of "su'ing" into the
account

to fix something.  So, I might have to 'become' the reseller (I'm the
admin), then become a client, then become a manager then become an
employee

to look at or fix something for them.

Regards,
David
-Original Message-
From: Jason Lea [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 6:49 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!
David Friedman wrote:



I've also been looking into security frameworks and the only solutions
I've

really found are:

1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/
I was hoping, at some point, to use an SSL switching feature such as
SSLext.


From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.
My bigger problem is my scenario, which no one supports.  I'd like to
allow

manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way
to


Trying to figure out what you are asking here can you give an example?

If you have the following:
1. User Manfred is a manager
2. User Emily is an Employee
3. Emily is an employee under Manfred
Are you saying that Manfred can become Emily and perform certain
tasks/actions?  Then Manfred would return to be Manfred the manager?


push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and
still


be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.
Regards,
David
-Original Message-
From: Mailing

RE: security framework!!!

[David Friedman]

Adam,

I should have explained this a bit better.  Each level is like a company or
organization.  It has it's own group of parties to maintain but can be
managed by one or more managers.  The managers share group responsibility.
Only the user at the very bottom rung has an interface which only that user
can use.  Everyone above it is some sort of manager for maintaining there
shared group (separate from other resellers, or separate from other).

admin--- reseller1 (admin1, admin2, admin3) -- customer1
  customer2
  customer3
 reseller2 (admin4) - customer4
  customer5
 reseller3 (admin5, admin6) - customer6
 reseller7 (admin7, admin8, admin9) - customer7
  customer8

In the above tree, the customer(s) have a group of their own admins plus
individual employees (who have no shared responsibilities).

I know this sounds like I should use pow2acl but it doesn't seem to have
anything for replacing the Principal so I could become a user, nor does it
appear to have anything to let me hook SSLext into it to ensure good
http/https lock-downs.

Do you have any hints/suggestions for a better methodology/way?

Regards,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 4:25 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!


Right, I get it. So you not only want the higher level user to take on
the lower level user's role, you want them to have their complete ID or
username etc.

Tricky!

I think alot depends on what kind of use you have for the user info. Is
it purely roles that are important here? Or is there ownership too? I
mean, one user can see his / her stuff, which is not accessible to
another user of equal level?

On 03/15/2004 03:39 AM David Friedman wrote:
> Jason,
>
> They might need to go into the account underneath them to fix something
(if
> they are asked) and won't know the password (encrypted).  The admin might
> need to fix something for a reseller's client made us look into (admin ->
> reseller -> client -> manager -> employee).  I've had a few projects where
> someone 2 levels under asks for help from the level immediately above
them.
> Then it goes up one and up again back to me.  Rather than make interfaces
> for everyone for everything, I prefer the idea of "su'ing" into the
account
> to fix something.  So, I might have to 'become' the reseller (I'm the
> admin), then become a client, then become a manager then become an
employee
> to look at or fix something for them.
>
> Regards,
> David
>
> -Original Message-
> From: Jason Lea [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 14, 2004 6:49 PM
> To: Struts Users Mailing List
> Subject: Re: security framework!!!
>
>
> David Friedman wrote:
>
>
>>I've also been looking into security frameworks and the only solutions
I've
>>really found are:
>>
>>1. Standard (container) JAAS
>>2. SecurityFilter http://securityfilter.sourceforge.net
>>3. Pow2ACL http://pow2acl.sourceforge.net/
>>
>>I was hoping, at some point, to use an SSL switching feature such as
>
> SSLext.
>
>>>From my research, Pow2ACL and SecurityFilter won't work that way.
>>SecurityFilter has a note that certain 'elements' could be used for it but
>>the current code makes no use of them in that manner.  As for Pow2ACL, I
>>didn't find anything suggesting how to use it in that way either.
>>
>>My bigger problem is my scenario, which no one supports.  I'd like to
allow
>>manager accounts to become one of if it's sub-accounts.  My system would
>>support at least 5 levels where 4 could 'drill down' and back up again:
>>admin, reseller, client, manager, employee (bottom feeder, no managerial
>>tools and no popping into their accounts).  Since there is no easily way
to
>>
>>
>
> Trying to figure out what you are asking here can you give an example?
>
> If you have the following:
> 1. User Manfred is a manager
> 2. User Emily is an Employee
> 3. Emily is an employee under Manfred
>
> Are you saying that Manfred can become Emily and perform certain
> tasks/actions?  Then Manfred would return to be Manfred the manager?
>
>
>>push/pop or even set (then I could use my own internal stack) a
>>UserPrincipal object, I'm thinking of using something a bit like
>>SecurityFilter: wrap the request object with a subclass of
>>HttpServeletRequestWrapper and add my own push/pop/set/get/count
>>UserPrincipal object(s).  Then, I could hook the login p

Re: security framework!!!

[Adam Hardy]

Right, I get it. So you not only want the higher level user to take on 
the lower level user's role, you want them to have their complete ID or 
username etc.

Tricky!

I think alot depends on what kind of use you have for the user info. Is 
it purely roles that are important here? Or is there ownership too? I 
mean, one user can see his / her stuff, which is not accessible to 
another user of equal level?

On 03/15/2004 03:39 AM David Friedman wrote:
Jason,

They might need to go into the account underneath them to fix something (if
they are asked) and won't know the password (encrypted).  The admin might
need to fix something for a reseller's client made us look into (admin ->
reseller -> client -> manager -> employee).  I've had a few projects where
someone 2 levels under asks for help from the level immediately above them.
Then it goes up one and up again back to me.  Rather than make interfaces
for everyone for everything, I prefer the idea of "su'ing" into the account
to fix something.  So, I might have to 'become' the reseller (I'm the
admin), then become a client, then become a manager then become an employee
to look at or fix something for them.
Regards,
David
-Original Message-
From: Jason Lea [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 6:49 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!
David Friedman wrote:


I've also been looking into security frameworks and the only solutions I've
really found are:
1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/
I was hoping, at some point, to use an SSL switching feature such as
SSLext.

From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.
My bigger problem is my scenario, which no one supports.  I'd like to allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way to

Trying to figure out what you are asking here can you give an example?

If you have the following:
1. User Manfred is a manager
2. User Emily is an Employee
3. Emily is an employee under Manfred
Are you saying that Manfred can become Emily and perform certain
tasks/actions?  Then Manfred would return to be Manfred the manager?

push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and
still

be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.
Regards,
David
-Original Message-
From: Mailing List [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 6:19 AM
To: [EMAIL PROTECTED]
Subject: security framework!!!
I'm developing a web application with struts.I had a problem for support
security at jsp pages level for different roles.I send an email and recived
2 response to solve my problem:
1.  with HTML tags.
2.  2.with define role in tiles definition
but I'm searching for a good framework that be compatibled with struts
framework and support the security for different roles at page levels.
I mean for example if I have a jsp page with tow textfields and a submit
deponds on user's role at the system,one user just can see one of the
textfield and submit buttom and another user can see both of the textfield
and submit buttom.
Can you suggest a good framework for me.
regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jason Lea


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



--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: security framework!!!

[David Friedman]

Jason,

They might need to go into the account underneath them to fix something (if
they are asked) and won't know the password (encrypted).  The admin might
need to fix something for a reseller's client made us look into (admin ->
reseller -> client -> manager -> employee).  I've had a few projects where
someone 2 levels under asks for help from the level immediately above them.
Then it goes up one and up again back to me.  Rather than make interfaces
for everyone for everything, I prefer the idea of "su'ing" into the account
to fix something.  So, I might have to 'become' the reseller (I'm the
admin), then become a client, then become a manager then become an employee
to look at or fix something for them.

Regards,
David

-Original Message-
From: Jason Lea [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 6:49 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!


David Friedman wrote:

>I've also been looking into security frameworks and the only solutions I've
>really found are:
>
>1. Standard (container) JAAS
>2. SecurityFilter http://securityfilter.sourceforge.net
>3. Pow2ACL http://pow2acl.sourceforge.net/
>
>I was hoping, at some point, to use an SSL switching feature such as
SSLext.
>>From my research, Pow2ACL and SecurityFilter won't work that way.
>SecurityFilter has a note that certain 'elements' could be used for it but
>the current code makes no use of them in that manner.  As for Pow2ACL, I
>didn't find anything suggesting how to use it in that way either.
>
>My bigger problem is my scenario, which no one supports.  I'd like to allow
>manager accounts to become one of if it's sub-accounts.  My system would
>support at least 5 levels where 4 could 'drill down' and back up again:
>admin, reseller, client, manager, employee (bottom feeder, no managerial
>tools and no popping into their accounts).  Since there is no easily way to
>
>
Trying to figure out what you are asking here can you give an example?

If you have the following:
1. User Manfred is a manager
2. User Emily is an Employee
3. Emily is an employee under Manfred

Are you saying that Manfred can become Emily and perform certain
tasks/actions?  Then Manfred would return to be Manfred the manager?

>push/pop or even set (then I could use my own internal stack) a
>UserPrincipal object, I'm thinking of using something a bit like
>SecurityFilter: wrap the request object with a subclass of
>HttpServeletRequestWrapper and add my own push/pop/set/get/count
>UserPrincipal object(s).  Then, I could hook the login procedure with
>container methods (JAAS, i.e. a web browser login/password pop-up) and
still
>be able to (when I'm ready) use SSLext or something like it for the
>HTTP/HTTPS switching.
>
>Regards,
>David
>
>-Original Message-
>From: Mailing List [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 13, 2004 6:19 AM
>To: [EMAIL PROTECTED]
>Subject: security framework!!!
>
>
>I'm developing a web application with struts.I had a problem for support
>security at jsp pages level for different roles.I send an email and recived
>2 response to solve my problem:
>1. with HTML tags.
>2. 2.with define role in tiles definition
>but I'm searching for a good framework that be compatibled with struts
>framework and support the security for different roles at page levels.
>I mean for example if I have a jsp page with tow textfields and a submit
>deponds on user's role at the system,one user just can see one of the
>textfield and submit buttom and another user can see both of the textfield
>and submit buttom.
>Can you suggest a good framework for me.
>regards
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>


--
Jason Lea



-
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: security framework!!!

[David Friedman]

Adam,

They might need to go into the account underneath them to fix something (if
they are asked) and won't know the password (encrypted).  The admin might
need to fix something for a reseller's client made us look into (admin ->
reseller -> client -> manager -> employee).

Regards,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 6:28 PM
To: Struts Users Mailing List
Subject: Re: security framework!!!


You mean you don't want to force the user to log out and back in again?
I would have thought that was a reasonable demand since they are
effectively changing their identity.

Your HttpServletRequest wrapper sounds OK as a solution though.

Adam

On 03/14/2004 03:51 PM David Friedman wrote:
> Adam,
>
> I want to integrate everything with roles (for using actions and jsp tags)
> so I'm stuck, after container authentication, having a non-changeable
> Principal object within Tomcat: their Coyote HttpServletRequest wrapping
> class prevents the use of setUserPrincipal.  All of my research on Tomcat
(4
> or 5) suggests a filter-based wrapper for the HttpServletRequest object is
> the only way to go to be able to set the UserPrincipal from within my
action
> so I could replace the Principal (as the admin becomes the reseller
becomes
> the customer becomes the manager becomes the user account, etc. and
possibly
> backs out each level one by one).
>
> Can you suggest any other avenues or theories for me to investigate since
my
> research has resulted in only that one workable solution?  Hints
> appreciated. :)
>
> Regards,
> David
>
> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 14, 2004 5:21 AM
> To: Struts Users Mailing List
> Subject: Re: security framework!!!
>
>
> On 03/13/2004 05:48 PM David Friedman wrote:
>
>>My bigger problem is my scenario, which no one supports.  I'd like to
>
> allow
>
>>manager accounts to become one of if it's sub-accounts.  My system would
>>support at least 5 levels where 4 could 'drill down' and back up again:
>>admin, reseller, client, manager, employee (bottom feeder, no managerial
>>tools and no popping into their accounts).  Since there is no easily way
>
> to
>
>>push/pop or even set (then I could use my own internal stack) a
>>UserPrincipal object, I'm thinking of using something a bit like
>>SecurityFilter:
>
>
> I'm not sure why the standard container-managed security roles don't
> meet your requirements.
>
> You want a manager to be able to set himself to another role? Sounds
> like a design issue. Obviously the manager is also going to need to set
> himself back to his normal role again?
>
> I would use extra roles to allow changing roles. The manager can assign
> himself whatever standard role he likes depending on his 'extra' roles.
> This would change the info in your realm and he would have to log out
> and back in again.
>
> Or have I got the wrong end of the stick?
>
> Adam
> --
> struts 1.1 + tomcat 5.0.16 + java 1.4.2
> Linux 2.4.20 Debian
>
>
> -
> 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]
>
>


--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


-
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: security framework!!!

[Jason Lea]

David Friedman wrote:

I've also been looking into security frameworks and the only solutions I've
really found are:
1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/
I was hoping, at some point, to use an SSL switching feature such as SSLext.
From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.
My bigger problem is my scenario, which no one supports.  I'd like to allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way to
 

Trying to figure out what you are asking here can you give an example?

If you have the following:
1. User Manfred is a manager
2. User Emily is an Employee
3. Emily is an employee under Manfred
Are you saying that Manfred can become Emily and perform certain 
tasks/actions?  Then Manfred would return to be Manfred the manager?

push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and still
be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.
Regards,
David
-Original Message-
From: Mailing List [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 6:19 AM
To: [EMAIL PROTECTED]
Subject: security framework!!!
I'm developing a web application with struts.I had a problem for support
security at jsp pages level for different roles.I send an email and recived
2 response to solve my problem:
1.  with HTML tags.
2.  2.with define role in tiles definition
but I'm searching for a good framework that be compatibled with struts
framework and support the security for different roles at page levels.
I mean for example if I have a jsp page with tow textfields and a submit
deponds on user's role at the system,one user just can see one of the
textfield and submit buttom and another user can see both of the textfield
and submit buttom.
Can you suggest a good framework for me.
regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



--
Jason Lea


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

Re: security framework!!!

[Adam Hardy]

You mean you don't want to force the user to log out and back in again? 
I would have thought that was a reasonable demand since they are 
effectively changing their identity.

Your HttpServletRequest wrapper sounds OK as a solution though.

Adam

On 03/14/2004 03:51 PM David Friedman wrote:
Adam,

I want to integrate everything with roles (for using actions and jsp tags)
so I'm stuck, after container authentication, having a non-changeable
Principal object within Tomcat: their Coyote HttpServletRequest wrapping
class prevents the use of setUserPrincipal.  All of my research on Tomcat (4
or 5) suggests a filter-based wrapper for the HttpServletRequest object is
the only way to go to be able to set the UserPrincipal from within my action
so I could replace the Principal (as the admin becomes the reseller becomes
the customer becomes the manager becomes the user account, etc. and possibly
backs out each level one by one).
Can you suggest any other avenues or theories for me to investigate since my
research has resulted in only that one workable solution?  Hints
appreciated. :)
Regards,
David
-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 5:21 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!
On 03/13/2004 05:48 PM David Friedman wrote:

My bigger problem is my scenario, which no one supports.  I'd like to
allow

manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way
to

push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter:


I'm not sure why the standard container-managed security roles don't
meet your requirements.
You want a manager to be able to set himself to another role? Sounds
like a design issue. Obviously the manager is also going to need to set
himself back to his normal role again?
I would use extra roles to allow changing roles. The manager can assign
himself whatever standard role he likes depending on his 'extra' roles.
This would change the info in your realm and he would have to log out
and back in again.
Or have I got the wrong end of the stick?

Adam
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
-
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]



--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: security framework!!!

[David Friedman]

Adam,

I want to integrate everything with roles (for using actions and jsp tags)
so I'm stuck, after container authentication, having a non-changeable
Principal object within Tomcat: their Coyote HttpServletRequest wrapping
class prevents the use of setUserPrincipal.  All of my research on Tomcat (4
or 5) suggests a filter-based wrapper for the HttpServletRequest object is
the only way to go to be able to set the UserPrincipal from within my action
so I could replace the Principal (as the admin becomes the reseller becomes
the customer becomes the manager becomes the user account, etc. and possibly
backs out each level one by one).

Can you suggest any other avenues or theories for me to investigate since my
research has resulted in only that one workable solution?  Hints
appreciated. :)

Regards,
David

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 14, 2004 5:21 AM
To: Struts Users Mailing List
Subject: Re: security framework!!!


On 03/13/2004 05:48 PM David Friedman wrote:
> My bigger problem is my scenario, which no one supports.  I'd like to
allow
> manager accounts to become one of if it's sub-accounts.  My system would
> support at least 5 levels where 4 could 'drill down' and back up again:
> admin, reseller, client, manager, employee (bottom feeder, no managerial
> tools and no popping into their accounts).  Since there is no easily way
to
> push/pop or even set (then I could use my own internal stack) a
> UserPrincipal object, I'm thinking of using something a bit like
> SecurityFilter:

I'm not sure why the standard container-managed security roles don't
meet your requirements.

You want a manager to be able to set himself to another role? Sounds
like a design issue. Obviously the manager is also going to need to set
himself back to his normal role again?

I would use extra roles to allow changing roles. The manager can assign
himself whatever standard role he likes depending on his 'extra' roles.
This would change the info in your realm and he would have to log out
and back in again.

Or have I got the wrong end of the stick?

Adam
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


-
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: security framework!!!

[Adam Hardy]

On 03/13/2004 05:48 PM David Friedman wrote:
My bigger problem is my scenario, which no one supports.  I'd like to allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way to
push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: 
I'm not sure why the standard container-managed security roles don't 
meet your requirements.

You want a manager to be able to set himself to another role? Sounds 
like a design issue. Obviously the manager is also going to need to set 
himself back to his normal role again?

I would use extra roles to allow changing roles. The manager can assign 
himself whatever standard role he likes depending on his 'extra' roles. 
This would change the info in your realm and he would have to log out 
and back in again.

Or have I got the wrong end of the stick?

Adam
--
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: security framework!!!

[Mailing List]

Thanks a lot for your response.I 'm so interesting to know that which of the
three framework you use.all of them combine together or no just one of
them.and give me a sample of your configuration.
regards

-Original Message-
From: Dmitry Brin [mailto:[EMAIL PROTECTED] 
Sent: Sunday, March 14, 2004 1:08 AM
To: 'Struts Users Mailing List'
Subject: RE: security framework!!!

Oracle provides Single Sign On with OID - no extra work required.


-Original Message-
From: David Friedman [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 13, 2004 8:49 AM
To: Struts Users Mailing List
Subject: RE: security framework!!!

I've also been looking into security frameworks and the only solutions
I've
really found are:

1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/

I was hoping, at some point, to use an SSL switching feature such as
SSLext.
>From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it
but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.

My bigger problem is my scenario, which no one supports.  I'd like to
allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way
to
push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and
still
be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.

Regards,
David

-Original Message-
From: Mailing List [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 6:19 AM
To: [EMAIL PROTECTED]
Subject: security framework!!!


I'm developing a web application with struts.I had a problem for support
security at jsp pages level for different roles.I send an email and
recived
2 response to solve my problem:
1.  with HTML tags.
2.  2.with define role in tiles definition
but I'm searching for a good framework that be compatibled with struts
framework and support the security for different roles at page levels.
I mean for example if I have a jsp page with tow textfields and a submit
deponds on user's role at the system,one user just can see one of the
textfield and submit buttom and another user can see both of the
textfield
and submit buttom.
Can you suggest a good framework for me.
regards


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


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

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

RE: security framework!!!

[Dmitry Brin]

Oracle provides Single Sign On with OID - no extra work required.


-Original Message-
From: David Friedman [mailto:[EMAIL PROTECTED] 
Sent: Saturday, March 13, 2004 8:49 AM
To: Struts Users Mailing List
Subject: RE: security framework!!!

I've also been looking into security frameworks and the only solutions
I've
really found are:

1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/

I was hoping, at some point, to use an SSL switching feature such as
SSLext.
>From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it
but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.

My bigger problem is my scenario, which no one supports.  I'd like to
allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way
to
push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and
still
be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.

Regards,
David

-Original Message-
From: Mailing List [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 6:19 AM
To: [EMAIL PROTECTED]
Subject: security framework!!!


I'm developing a web application with struts.I had a problem for support
security at jsp pages level for different roles.I send an email and
recived
2 response to solve my problem:
1.  with HTML tags.
2.  2.with define role in tiles definition
but I'm searching for a good framework that be compatibled with struts
framework and support the security for different roles at page levels.
I mean for example if I have a jsp page with tow textfields and a submit
deponds on user's role at the system,one user just can see one of the
textfield and submit buttom and another user can see both of the
textfield
and submit buttom.
Can you suggest a good framework for me.
regards


-
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: security framework!!!

[David Friedman]

I've also been looking into security frameworks and the only solutions I've
really found are:

1. Standard (container) JAAS
2. SecurityFilter http://securityfilter.sourceforge.net
3. Pow2ACL http://pow2acl.sourceforge.net/

I was hoping, at some point, to use an SSL switching feature such as SSLext.
>From my research, Pow2ACL and SecurityFilter won't work that way.
SecurityFilter has a note that certain 'elements' could be used for it but
the current code makes no use of them in that manner.  As for Pow2ACL, I
didn't find anything suggesting how to use it in that way either.

My bigger problem is my scenario, which no one supports.  I'd like to allow
manager accounts to become one of if it's sub-accounts.  My system would
support at least 5 levels where 4 could 'drill down' and back up again:
admin, reseller, client, manager, employee (bottom feeder, no managerial
tools and no popping into their accounts).  Since there is no easily way to
push/pop or even set (then I could use my own internal stack) a
UserPrincipal object, I'm thinking of using something a bit like
SecurityFilter: wrap the request object with a subclass of
HttpServeletRequestWrapper and add my own push/pop/set/get/count
UserPrincipal object(s).  Then, I could hook the login procedure with
container methods (JAAS, i.e. a web browser login/password pop-up) and still
be able to (when I'm ready) use SSLext or something like it for the
HTTP/HTTPS switching.

Regards,
David

-Original Message-
From: Mailing List [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 6:19 AM
To: [EMAIL PROTECTED]
Subject: security framework!!!


I'm developing a web application with struts.I had a problem for support
security at jsp pages level for different roles.I send an email and recived
2 response to solve my problem:
1.  with HTML tags.
2.  2.with define role in tiles definition
but I'm searching for a good framework that be compatibled with struts
framework and support the security for different roles at page levels.
I mean for example if I have a jsp page with tow textfields and a submit
deponds on user's role at the system,one user just can see one of the
textfield and submit buttom and another user can see both of the textfield
and submit buttom.
Can you suggest a good framework for me.
regards


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

RE: security framework!!!

[Robert Taylor]

http://sourceforge.net/projects/securityfilter/ emulates container managed security.

robert

> -Original Message-
> From: Mailing List [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 13, 2004 6:19 AM
> To: [EMAIL PROTECTED]
> Subject: security framework!!!
> 
> 
> I'm developing a web application with struts.I had a problem for support
> security at jsp pages level for different roles.I send an email and recived
> 2 response to solve my problem:
> 1.with HTML tags.
> 2.2.with define role in tiles definition
> but I'm searching for a good framework that be compatibled with struts
> framework and support the security for different roles at page levels.
> I mean for example if I have a jsp page with tow textfields and a submit
> deponds on user's role at the system,one user just can see one of the
> textfield and submit buttom and another user can see both of the textfield
> and submit buttom.
> Can you suggest a good framework for me.
> regards
> 

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