You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Amol Ghotankar <gh...@gmail.com> on 2010/07/07 13:04:41 UTC
Authorization Best Practices
Dear List members,
Using Struts 2.x can we do authorization of client request, if yes what are
the best practices for the same please discuss.
Authorization will have two parts
1. decide which action are allowed and which are not,
2 . decide how much data to access.
Means if I have a database which has 100 rows, then to show 100 or 10 or 50
based on the role of the user and this authorization permissions.
Also how to handle unauthorized request and redirect to called action or
some other page.
There are several ways we can discuss all here.
With Best Regards,
Amol Ghotankar
Cursive Technologies Pvt. Ltd.
www.cursivetech.com
CURSIVE TECHNOLOGIES EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or telephone and delete the original message from your mail system.
Re: Authorization Best Practices
Posted by Brian Thompson <el...@gmail.com>.
On Thu, Jul 8, 2010 at 1:09 PM, Burton Rhodes <bu...@gmail.com> wrote:
> I say we start another thread to discuss more about this ducussion.
I think that would fit best in the "struts-users-meta" list ;)
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Burton Rhodes <bu...@gmail.com>.
I say we start another thread to discuss more about this ducussion.
On Thu, Jul 8, 2010 at 9:31 AM, Dale Newfield <da...@newfield.org> wrote:
> On 7/8/10 10:17 AM, MB wrote:
>>
>> "Using Struts 2.x can we do authorization of client request, if yes
>> what are the best practices"
>
> That answer has been given 3 times in this thread: Spring Security.
>
> The best practices are to learn about architecture and security, which are
> completely independent of struts.
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
On 7/8/10 10:17 AM, MB wrote:
> "Using Struts 2.x can we do authorization of client request, if yes
> what are the best practices"
That answer has been given 3 times in this thread: Spring Security.
The best practices are to learn about architecture and security, which
are completely independent of struts.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by MB <di...@gmail.com>.
Dale Newfield suggested:
>Not a single one of your questions relates to struts.
How exactly doesn't "Using Struts 2.x can we do authorization of client
request, if yes what are
the best practices" apply to Struts? Or "we can discuss what practises
can be followed to implement this logic using struts2 and related
framework(s)"?
I'm not saying you're wrong that other frameworks may be better suited,
but to me it is Struts 2 knowledge to know that other frameworks may
have better solutions. That would mean it is related, though I wouldn't
expect in-depth discussions not involving Struts 2 in any shape or form.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
This isn't your architecture review board. This is a mailing list
supporting struts, just one of many components in your application.
Not a single one of your questions relates to struts.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Amol Ghotankar <gh...@gmail.com>.
Dear List Members,
Lot of theory put here now lets talk with example.
Lets assume there are three roles a user can have
1. user
2. manager
3, admin
Lets assume a simple CRUD use case which has four actions
1. insert
2. update
3. delete
4. list
Now
A. Part 1.
1. users loged in with user & manager role can access all actions except
delete.
B. Part 2
1. users logged in with role user can
-insert any record but
-update only records which he has inserted before
-and also list records which he has inserted.
2. users logged in with role manage can
- insert any record and
- update any record enter by him and users under his department
- list all records inserted by him and users under his department
3. users logged in with role admin can
- insert any record and
- update only his records not other users
- list all records by him and other users
- delete any record by him and other users
Now I think the discussion will be more focus and we can discuss what
practises can be followed to implement this logic using struts2 and related
framework.
Regards,
Amol Ghotankar.
On Thu, Jul 8, 2010 at 2:12 AM, Dale Newfield <da...@newfield.org> wrote:
> On 7/7/10 2:26 PM, Amol Ghotankar wrote:
>
>> Part 2 . How to control access of data from back end database based on
>> action/user-role.
>>
>> i.e how much data should be returned through called action, 10 rows, 100
>> rows or 1000 rows from database, based on user role and/or called action.
>>
>
> Whether data should be accessible and how much data should be accessible
> sound like orthogonal questions to me. Whether is a business logic or dao
> question. How much is just a parameter passed to business logic and/or dao,
> but is really more a question that the web layer should determine, no?
>
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
On 7/7/10 2:26 PM, Amol Ghotankar wrote:
> Part 2 . How to control access of data from back end database based on
> action/user-role.
>
> i.e how much data should be returned through called action, 10 rows, 100
> rows or 1000 rows from database, based on user role and/or called action.
Whether data should be accessible and how much data should be accessible
sound like orthogonal questions to me. Whether is a business logic or
dao question. How much is just a parameter passed to business logic
and/or dao, but is really more a question that the web layer should
determine, no?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Amol Ghotankar <gh...@gmail.com>.
Dear List member,
The issue we are discussing here is Authorization using Struts2x.
Part 1. How to control access of actions
i.e which actions can be accessed by which user role
Part 2 . How to control access of data from back end database based on
action/user-role.
i.e how much data should be returned through called action, 10 rows, 100
rows or 1000 rows from database, based on user role and/or called action.
Part 1 has been simple and several simple ways have solved this issue.
Part 2 is the major concern of discussion as isn't it a concern of MVC's C -
Controller to control the data also?
My actions know what data to be fetched but business layer can over-write it
where as the actual data is beneath the DAO layer.
So where can we intercept or we need to intercept all the three layers and
have a combined policy using them.
Regards,
Amol Ghotankar
On Wed, Jul 7, 2010 at 11:41 PM, Ken <ke...@aerose.com> wrote:
> On Wed, 2010-07-07 at 13:34 -0400, Dale Newfield wrote:
>
> > On 7/7/10 1:28 PM, Amol Ghotankar wrote:
> > > 2 . decide how much data to access.
> > >
> > > This I am really working something where struts2 intercepter will read
> what
> > > role the user has and set some global role for that reqest which will
> be
> > > read by dao to use to fetch the data.
> >
> > The interceptor cannot know independent of the action/business logic
> > what data will need to be fetched. I don't think you can solve this
> > problem within struts Even if you do, you've then built a toolset that
> > doesn't include any of these access restrictions in otherwise exposed
> > services.
> >
> > -Dale
>
>
> This is a hand rolled solution I used:
> Create an interceptor which checks if a User object exists when
> accessing a secure package, if it does not exist redirect the user to a
> login page and record the initial url (will redirect back to that page
> after login). I use hibernate... so the user object contains a
> connection to the database. If you're also using hibernate you'll
> notice you can supply the specific "hibernate.cfg.xml" when establishing
> the connection, by making this choice dependant on the particular user
> you can supply different database connections or even restrict data
> access. In this case I think xml files are better than annotations as
> you don't need to change the POJO which the *.hbm.xml files refer to.
>
> Sorry I'm not sure I really understood the issue, but this helped me a
> lot and was very easy to implement.
>
>
>
>
>
>
>
>
>
>
--
With Best Regards,
Amol Ghotankar
Technical Director
Cursive Technologies Pvt. Ltd.
104, A1 Wing, W Sector,
Masulkar Colony, Ajmera,
Pimpri, Pune-18 INDIA
O: +91 2020 270 570
M: +91 9960 980 419
www.cursivetech.com
CURSIVE TECHNOLOGIES EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail
or telephone and delete the original message from your mail system.
Re: Authorization Best Practices
Posted by Ken <ke...@aerose.com>.
On Wed, 2010-07-07 at 14:40 -0400, Dale Newfield wrote:
> On 7/7/10 2:11 PM, Ken wrote:
> > This is a hand rolled solution I used:
> > Create an interceptor which checks if a User object exists when
> > accessing a secure package, if it does not exist redirect the user to a
> > login page and record the initial url (will redirect back to that page
> > after login).
>
> This isn't part 2 of the asked question, but part 1. "Best Practices"
> in security usually means "Don't roll your own" since you're very likely
> to implement the same bugs that widely used packages have had time and
> eyeballs needed to fix.
>
> > I use hibernate... so the user object contains a connection to the
> > database.
>
> For the duration of the hibernate session, yes. But be careful about
> this, too, as for example if you store that in the http session you may
> be keeping hibernate sessions open far too long, or encountering
> hibernate backed objects that no longer have their active session and
> thus their connection to the DB.
The application is internal and the user needs constant access to the
database, for order entry and retrieval (among other things), I open a
small connection pool per user and am not worried about it being closed
down except once a day... even then I'm not very worried the server is a
decent iSeries the user base is small relative to its potential... The
application is supposed to fill the purpose of a "green screen"
connection (5250 session).
>
> > If you're also using hibernate you'll
> > notice you can supply the specific "hibernate.cfg.xml" when establishing
> > the connection, by making this choice dependant on the particular user
> > you can supply different database connections or even restrict data
> > access. In this case I think xml files are better than annotations as
> > you don't need to change the POJO which the *.hbm.xml files refer to.
>
> That's an interesting idea, although I don't know how having a per-user
> hibernate.cfg allows you to control which rows of which tables are
> fetchable...and I'd think complex business logic would quickly make this
> untenable.
I suppose it might, my system is pretty basic. But one possibility is
using named queries... (of course everyone thinks _their_ solution is
the easiest until they see something better, I'm always shopping!).
Because the hibernate.cfg is the base for bringing in the rest of the
associated xml files, simply
create a hibernate.cfg per role (I'm assuming something obviously about
the tractability for the number of roles but in my case there's only
three, right now)... Then have your particular hibernate.cfg.xml bring
in a roll specific namedQuery.hbm.xml file and vola... you can do some
fancy footwork. Since you can control updates via the named queries.
I'm not certain about this idea but, if the application has complex
state which needs to be taken into account... as perhaps the OP was
alluding too... well perhaps hibernate should also be made aware of it,
persist their state (the business objects state) to an in in memory
database (or the production DB, if you're lucky enough to be the DBA and
running on the same system...) then the queries can take that into
account, which aught to be way easier that trying to maintain some crazy
state machine combined with data access. In this way decisions can be
pushed down into the data layer, everything becomes a query. Which makes
sense, someone is asking a question of the data.
> "Person X has read access to all rows of Y that are not marked
> 'private', and write access to all rows of Y that are linked to some
> other object that lists person X as a manager."
>
> -Dale
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
On 7/7/10 2:11 PM, Ken wrote:
> This is a hand rolled solution I used:
> Create an interceptor which checks if a User object exists when
> accessing a secure package, if it does not exist redirect the user to a
> login page and record the initial url (will redirect back to that page
> after login).
This isn't part 2 of the asked question, but part 1. "Best Practices"
in security usually means "Don't roll your own" since you're very likely
to implement the same bugs that widely used packages have had time and
eyeballs needed to fix.
> I use hibernate... so the user object contains a connection to the
> database.
For the duration of the hibernate session, yes. But be careful about
this, too, as for example if you store that in the http session you may
be keeping hibernate sessions open far too long, or encountering
hibernate backed objects that no longer have their active session and
thus their connection to the DB.
> If you're also using hibernate you'll
> notice you can supply the specific "hibernate.cfg.xml" when establishing
> the connection, by making this choice dependant on the particular user
> you can supply different database connections or even restrict data
> access. In this case I think xml files are better than annotations as
> you don't need to change the POJO which the *.hbm.xml files refer to.
That's an interesting idea, although I don't know how having a per-user
hibernate.cfg allows you to control which rows of which tables are
fetchable...and I'd think complex business logic would quickly make this
untenable.
"Person X has read access to all rows of Y that are not marked
'private', and write access to all rows of Y that are linked to some
other object that lists person X as a manager."
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Ken <ke...@aerose.com>.
On Wed, 2010-07-07 at 13:34 -0400, Dale Newfield wrote:
> On 7/7/10 1:28 PM, Amol Ghotankar wrote:
> > 2 . decide how much data to access.
> >
> > This I am really working something where struts2 intercepter will read what
> > role the user has and set some global role for that reqest which will be
> > read by dao to use to fetch the data.
>
> The interceptor cannot know independent of the action/business logic
> what data will need to be fetched. I don't think you can solve this
> problem within struts Even if you do, you've then built a toolset that
> doesn't include any of these access restrictions in otherwise exposed
> services.
>
> -Dale
This is a hand rolled solution I used:
Create an interceptor which checks if a User object exists when
accessing a secure package, if it does not exist redirect the user to a
login page and record the initial url (will redirect back to that page
after login). I use hibernate... so the user object contains a
connection to the database. If you're also using hibernate you'll
notice you can supply the specific "hibernate.cfg.xml" when establishing
the connection, by making this choice dependant on the particular user
you can supply different database connections or even restrict data
access. In this case I think xml files are better than annotations as
you don't need to change the POJO which the *.hbm.xml files refer to.
Sorry I'm not sure I really understood the issue, but this helped me a
lot and was very easy to implement.
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
On 7/7/10 1:28 PM, Amol Ghotankar wrote:
> 2 . decide how much data to access.
>
> This I am really working something where struts2 intercepter will read what
> role the user has and set some global role for that reqest which will be
> read by dao to use to fetch the data.
The interceptor cannot know independent of the action/business logic
what data will need to be fetched. I don't think you can solve this
problem within struts Even if you do, you've then built a toolset that
doesn't include any of these access restrictions in otherwise exposed
services.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Amol Ghotankar <gh...@gmail.com>.
Dear List members,
1. decide which action are allowed and which are not,
What I used was a spring AOP which intercepted Struts 2 actions, this was
very simple and straight forward.
2 . decide how much data to access.
This I am really working something where struts2 intercepter will read what
role the user has and set some global role for that reqest which will be
read by dao to use to fetch the data.
3. Regarding Notice
I think somehow my firewall intercepted it and added to the mail, I am sorry
for it.
On Wed, Jul 7, 2010 at 7:52 PM, Brian Thompson <el...@gmail.com>wrote:
> On Wed, Jul 7, 2010 at 8:31 AM, Dale Newfield <da...@newfield.org> wrote:
> > Including a notice like this on a request for help sent to a public,
> > archived mailing list is obnoxious. JSYK, I've been seriously
> considering
> > instituting a personal policy whereby I will never respond to such
> messages.
> >
> > -Dale
>
> I think you mistyped "Including a notice like this in an email" ;)
>
> I really don't get where all these "OMG CONFIDENTIAL" notices come
> from. One wouldn't use postcards to snail-mail confidential
> information.
>
> As to authorization - I agree that Spring Security is a good way to go.
>
> -Brian
>
--
With Best Regards,
Amol Ghotankar
Re: Authorization Best Practices
Posted by Brian Thompson <el...@gmail.com>.
On Wed, Jul 7, 2010 at 8:31 AM, Dale Newfield <da...@newfield.org> wrote:
> Including a notice like this on a request for help sent to a public,
> archived mailing list is obnoxious. JSYK, I've been seriously considering
> instituting a personal policy whereby I will never respond to such messages.
>
> -Dale
I think you mistyped "Including a notice like this in an email" ;)
I really don't get where all these "OMG CONFIDENTIAL" notices come
from. One wouldn't use postcards to snail-mail confidential
information.
As to authorization - I agree that Spring Security is a good way to go.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Authorization Best Practices
Posted by Dale Newfield <da...@newfield.org>.
On 7/7/10 7:04 AM, Amol Ghotankar wrote:
> Authorization will have two parts
>
> 1. decide which action are allowed and which are not,
Spring Security.
> 2 . decide how much data to access.
>
> Means if I have a database which has 100 rows, then to show 100 or 10 or 50
> based on the role of the user and this authorization permissions.
There is no magic (that I'm aware of) here. My current solution is that
just about every dao request to load an object from the DB includes an
optional argument of the user making the request, which allows the fetch
logic to determine whether or not the data should be provided. Arguably
that should be part of the service layer instead, since in it's more
complex forms it's more of a business logic question. The main reason I
use the dao layer is that I'm also recording access data at the same
time I'm returning the requested info.
> CURSIVE TECHNOLOGIES EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail
> or telephone and delete the original message from your mail system.
Including a notice like this on a request for help sent to a public,
archived mailing list is obnoxious. JSYK, I've been seriously
considering instituting a personal policy whereby I will never respond
to such messages.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org