You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Sune Lindberg Riedel <su...@axiell.com> on 2009/04/02 07:37:21 UTC
Writing a custom authorization component...
Hi!
I tried to post my question below on the forum, but either nobody knows
the answer or the amount of people who knows that answer and has time to
help are too limited - so I will give it a shot on the mailing list - I
am not looking for an answer that will provide me with the perfect
solution - just some thoughts and ideas about how to make it work using
JSecurity/Ki:
I am currently working on a web project where some bright people
thought: Hey, we need some authorization... ...cue ME!
The Setup:
The great thing about this project is, that so far we don't have any
existing security model (like LDAP), so we can pretty much choose what
we like.
The not so brilliant thing (from a security/authorization point of view)
is that we don't have a setup, where we can use the general user/role
model.
We have a setup where we have one central backend server - this is where
the global user profiles are stored.
We then have several "local" servers, each of which contains several web
sites (which have their own unique URL's).
A person only have one global user profile, but may have a local profile
for each web site. The user may log on to any web site, where he has a
local profile, and he may use his global username/password or the
credentials he has for the local web site (if he uses the global
username, we will look at the URL to figure out which local profile he
has).
Now the tricky part is the roles:
- A user may have certain roles at the global level - these roles (and
their permissions) are valid for all web sites he logs in to.
- A user may have certain roles at the web site level - these roles are
valid for the entire site (and sub-sites).
- A user may have certain roles at a sub-site level - these roles are
only valid for a particular subset of the website (typically a sub-URL)
he is logged into.
Now, the first two levels of roles can be determined at login time, but
the roles that are only valid for a given sub-site, must be
added/removed to the active set of roles/permissions whenever the user
switches to another sub-site.
The question:
Now, I've looked a little at the documentation, examples and some source
code of JSecurity/Ki and I am convinced that somehow we can make a
solution with this - a good solution even. Unfortunately I'm no security
expert, so I am struggling quite a bit, trying to figure out which
classes I need replace in the default implementation with my own
implementations to make this work. I figure I need to make a custom
Authorizer at least, but I may also have to do my own implementations of
AuthorizationInfo...
Bottom line: I just don't get it - looking at the sample app, which
instantiates a DefaultSecurityManager and uses Default[everything] -
what do I replace to make a custom security solution, that will help me
solve the scenario described above?
Heeelp...
Best Regards
/Sune
Re: {SPAM 03.3} Re: Writing a custom authorization component...
Posted by Jeremy Haile <jh...@fastmail.fm>.
> P.S. There has been some discussion to provide an out-of-the-box
> data model that would employ what the Ki team feels are best
> practices, specifically to kick-start many users who don't really
> want to think about the data model design of flexible security
> systems. If created, it would definitely be purely optional.
To build on Les' comment here, many users have expressed a desire for
an out-of-the-box security solution that includes read/write support
and an optional interface for managing it. This could be very useful
for new projects that want to get security up and running quickly.
This would be probably be provided as an optional module that would
build on top of the core JSecurity module and add write support and a
basic UI.
Check out this earlier thread and see if it sounds like what you are
after:
http://markmail.org/thread/rlu6cjz3wghwuiht
Re: Writing a custom authorization component...
Posted by Jeremy Haile <jh...@fastmail.fm>.
> If only configuration is needed, then my next question would be:
> Couldn’t you just make an implementation for managing permissions,
> that used the same configuration to figure out how to write to the
> tables? …or is it more complicated than that? (I’m just
> I learned that Spring Security specifies how to design the data
> model, when you want to use ACL – how come they do that? Is that
> because ACL is so freaky, that it needs to be implemented in a
> certain way (and most likely *not* part of the existing user tables
> you got) or am I getting it all wrong?
I haven't looked at Spring Security's ACL support in a while, so I
can't comment there. However, Ki takes a very simple approach to
ACLs. Check out the JavaDoc on Ki's WildcardPermission. The
underlying model can model the ACL any way it wants and just hand Ki
back some simple strings that explain a user's ACL permissions. In
fact, many applications just store these ACL string permissions in the
database exactly in the format Ki supports so it's extremely easy to
model.
>
> From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com]
> On Behalf Of Les Hazlewood
> Sent: Monday, April 06, 2009 05:36
> To: jsecurity-user@incubator.apache.org
> Subject: Re: Writing a custom authorization component...
>
>
>
> On Sun, Apr 5, 2009 at 10:46 PM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> > wrote:
> On Sun, Apr 5, 2009 at 3:00 PM, Sune Lindberg Riedel <sune.riedel@axiell.com
> > wrote:
> Another huge black hole in our solution is: where is the API for
> *declaring* the roles and permissions for the different realms – I
> don’t see methods for setting roles and permissions anywhere in the
> Ki API’s (and neither in Spring Security, which we have also been
> investigating). In eg. JDBCRealm, there are nice queries for
> resolving roles and permissions, but how does the data get into
> these tables in the first place. What do people do when it comes to
> declaring this stuff? Is there a standard way to do this? Or some
> widely used standard products (that I have just missed)?
>
> Just comments from another user of Ki, but I also have lots of
> experience on Acegi/Spring Security as well CMA (Container Managed
> Authentication) and JAAS. There are too many ways to map roles and
> permissions to your persistence model to make any default
> implementation. In real world, users often start with an existing
> user database (LDAP, Windows domain users, NIS accounts etc.) and
> adapting it to a default implementation is often impractical. Ki
> could supply some generic base interfaces that users can choose to
> implement (which Spring Security does to some extent).
>
> Yep, this is exactly why Ki is mostly a 'read only' API. Data
> models vary so dramatically across multiple applications that there
> is no way we could impose conventions on end users - which would be
> required if Ki managed the CRUD operations for said data model.
>
> For example, a common convention is that a User has one or more
> Roles. Roles can have one or more Permissions. But that's usually
> where the similarities end. That is, could a User have Permissions
> assigned to them directly? In my apps, I don't do that - I always
> have a private Role to which permissions are added, just like any
> other Role, which gives me per-user permissioning capability - this
> keeps my permission-check code consistent. But that's not to say
> that another application would do that.
>
> Or, do you use Groups? In my apps that need them, a Group has a
> collection of one or more Users and also has a collection of one or
> more Roles. By transitive association, if a user is in a group,
> then they also have the group's roles. This is purely a convenience
> mechanism - many applications (I dare say most) don't have the need
> for Groups at all. Similarly, many simple applications don't use
> Permissions at all and get by on Roles only.
>
> Hopefully the number of permutations based on application
> requirements can give you insight as to why we don't provide 'write
> operations'. There's no way to predict how application's will
> declare their data model.
>
> I hope the above examples give some insight in to our decisions and
> perhaps some ideas for your own data model.
>
> Cheers,
>
> Les
>
> P.S. There has been some discussion to provide an out-of-the-box
> data model that would employ what the Ki team feels are best
> practices, specifically to kick-start many users who don't really
> want to think about the data model design of flexible security
> systems. If created, it would definitely be purely optional.
>
Re: Writing a custom authorization component...
Posted by Les Hazlewood <lh...@apache.org>.
Hi Sune,
> Kalle, if I am understanding you correctly, there is no “total package” for
> a security solution (meaning API and underlying implementation for both
> managing and applying security features)? – and the reason or this is, that
> in most cases when you need to apply security to your application, you
> already have an existing user database (and then you just extend it with
> roles and permissions as needed – by hand).
>
Its not that they're existing only. Applications might want to store this
data in a new data source, which might be LDAP or RDBMS-based, or some
proprietary back-end entirely.
> But is this what everybody does when they need to apply role-based
> permissions to a system – code it from scratch (everything from designing
> database tables to making a UI within your application, that allows the
> administrators to manage these settings)?
>
Yep, that's pretty much what everyone does - the data model format, entity
relationships and GUIs are all _very_ specific to the application or company
or both.
> Of course I see the problem in making an API, that adapts to all the
> various ways these data can be stored, but in some (most?) situations you
> don’t have to that much to apply the security (i.e. read from the model) –
> you only have to do some configuration, right? …or do you need to extend one
> of the existing realms to make it understand exactly how your data model is
> wired?
>
It depends - applications with simpler data modes can use many of the
existing realm implementations out of the box. However, medium to complex
applications often require subclassing for custom logic.
> If only configuration is needed, then my next question would be: Couldn’t
> you just make an implementation for managing permissions, that used the same
> configuration to figure out how to write to the tables? …or is it more
> complicated than that? (I’m just talking about making an API available for
> managing this – not an entire UI application)
>
It depends on the Realm. For example, the JdbcRealm assumes a particular
table structure, but you can of course override the select statements to
match your tables. The same would have to happen for update statements. So
yes, this is configurable to a degree, but it is still heavily
realm-dependent.
> I learned that Spring Security specifies how to design the data model, when
> you want to use ACL – how come they do that? Is that because ACL is so
> freaky, that it needs to be implemented in a certain way (and most likely *
> *not** part of the existing user tables you got) or am I getting it all
> wrong?
>
Jeremy answered this, but I'll add that perhaps having an interface-based
(but still optional) API would probably be very useful to helping people
understand a 'best practices' data model. You might want to open a Jira
issue to ask for this - it usually won't get done unless its in Jira :)
> I hope you won’t forget my question from my previous mail about having to
> apply security to an application where part of it has a session with a
> logged in user, and part of it is stateless and requires all information to
> be included in the invocation…
>
What information are you talking about exactly? Ki's default mechanisms
usually append a session ID as payload to a remote method invocation. This
session id is attributed to a session on the back end, which contains
identity information enough such that a Subject can be associated with the
request/method invocation and appropriate checks can be done during that
request/MI.
Regards,
Les
RE: Writing a custom authorization component...
Posted by Sune Lindberg Riedel <su...@axiell.com>.
Hi again!
Once more – thanks for answering my questions so quickly – it’s nice to know there is an active community behind Ki.
Kalle, if I am understanding you correctly, there is no “total package” for a security solution (meaning API and underlying implementation for both managing and applying security features)? – and the reason or this is, that in most cases when you need to apply security to your application, you already have an existing user database (and then you just extend it with roles and permissions as needed – by hand).
But is this what everybody does when they need to apply role-based permissions to a system – code it from scratch (everything from designing database tables to making a UI within your application, that allows the administrators to manage these settings)?
Of course I see the problem in making an API, that adapts to all the various ways these data can be stored, but in some (most?) situations you don’t have to that much to apply the security (i.e. read from the model) – you only have to do some configuration, right? …or do you need to extend one of the existing realms to make it understand exactly how your data model is wired?
If only configuration is needed, then my next question would be: Couldn’t you just make an implementation for managing permissions, that used the same configuration to figure out how to write to the tables? …or is it more complicated than that? (I’m just talking about making an API available for managing this – not an entire UI application)
I learned that Spring Security specifies how to design the data model, when you want to use ACL – how come they do that? Is that because ACL is so freaky, that it needs to be implemented in a certain way (and most likely *not* part of the existing user tables you got) or am I getting it all wrong?
I hope you won’t forget my question from my previous mail about having to apply security to an application where part of it has a session with a logged in user, and part of it is stateless and requires all information to be included in the invocation…
That was a lot of questions (again) – I hope some of you will find the time to help me along – then someday I hope I’ll be clever enough to help the next new kid on the block… J
BR
/Sune
(apparently I hope a lot)
From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On Behalf Of Les Hazlewood
Sent: Monday, April 06, 2009 05:36
To: jsecurity-user@incubator.apache.org
Subject: Re: Writing a custom authorization component...
On Sun, Apr 5, 2009 at 10:46 PM, Kalle Korhonen <ka...@gmail.com> wrote:
On Sun, Apr 5, 2009 at 3:00 PM, Sune Lindberg Riedel <su...@axiell.com> wrote:
Another huge black hole in our solution is: where is the API for *declaring* the roles and permissions for the different realms – I don’t see methods for setting roles and permissions anywhere in the Ki API’s (and neither in Spring Security, which we have also been investigating). In eg. JDBCRealm, there are nice queries for resolving roles and permissions, but how does the data get into these tables in the first place. What do people do when it comes to declaring this stuff? Is there a standard way to do this? Or some widely used standard products (that I have just missed)?
Just comments from another user of Ki, but I also have lots of experience on Acegi/Spring Security as well CMA (Container Managed Authentication) and JAAS. There are too many ways to map roles and permissions to your persistence model to make any default implementation. In real world, users often start with an existing user database (LDAP, Windows domain users, NIS accounts etc.) and adapting it to a default implementation is often impractical. Ki could supply some generic base interfaces that users can choose to implement (which Spring Security does to some extent).
Yep, this is exactly why Ki is mostly a 'read only' API. Data models vary so dramatically across multiple applications that there is no way we could impose conventions on end users - which would be required if Ki managed the CRUD operations for said data model.
For example, a common convention is that a User has one or more Roles. Roles can have one or more Permissions. But that's usually where the similarities end. That is, could a User have Permissions assigned to them directly? In my apps, I don't do that - I always have a private Role to which permissions are added, just like any other Role, which gives me per-user permissioning capability - this keeps my permission-check code consistent. But that's not to say that another application would do that.
Or, do you use Groups? In my apps that need them, a Group has a collection of one or more Users and also has a collection of one or more Roles. By transitive association, if a user is in a group, then they also have the group's roles. This is purely a convenience mechanism - many applications (I dare say most) don't have the need for Groups at all. Similarly, many simple applications don't use Permissions at all and get by on Roles only.
Hopefully the number of permutations based on application requirements can give you insight as to why we don't provide 'write operations'. There's no way to predict how application's will declare their data model.
I hope the above examples give some insight in to our decisions and perhaps some ideas for your own data model.
Cheers,
Les
P.S. There has been some discussion to provide an out-of-the-box data model that would employ what the Ki team feels are best practices, specifically to kick-start many users who don't really want to think about the data model design of flexible security systems. If created, it would definitely be purely optional.
Re: Writing a custom authorization component...
Posted by Les Hazlewood <lh...@apache.org>.
On Sun, Apr 5, 2009 at 10:46 PM, Kalle Korhonen
<ka...@gmail.com>wrote:
> On Sun, Apr 5, 2009 at 3:00 PM, Sune Lindberg Riedel <
> sune.riedel@axiell.com> wrote:
>
>> Another huge black hole in our solution is: where is the API for **
>> declaring** the roles and permissions for the different realms – I don’t
>> see methods for setting roles and permissions anywhere in the Ki API’s (and
>> neither in Spring Security, which we have also been investigating). In eg.
>> JDBCRealm, there are nice queries for resolving roles and permissions, but
>> how does the data get into these tables in the first place. What do people
>> do when it comes to declaring this stuff? Is there a standard way to do
>> this? Or some widely used standard products (that I have just missed)?
>>
> Just comments from another user of Ki, but I also have lots of experience
> on Acegi/Spring Security as well CMA (Container Managed Authentication) and
> JAAS. There are too many ways to map roles and permissions to your
> persistence model to make any default implementation. In real world, users
> often start with an existing user database (LDAP, Windows domain users, NIS
> accounts etc.) and adapting it to a default implementation is often
> impractical. Ki could supply some generic base interfaces that users can
> choose to implement (which Spring Security does to some extent).
>
Yep, this is exactly why Ki is mostly a 'read only' API. Data models vary
so dramatically across multiple applications that there is no way we could
impose conventions on end users - which would be required if Ki managed the
CRUD operations for said data model.
For example, a common convention is that a User has one or more Roles.
Roles can have one or more Permissions. But that's usually where the
similarities end. That is, could a User have Permissions assigned to them
directly? In my apps, I don't do that - I always have a private Role to
which permissions are added, just like any other Role, which gives me
per-user permissioning capability - this keeps my permission-check code
consistent. But that's not to say that another application would do that.
Or, do you use Groups? In my apps that need them, a Group has a collection
of one or more Users and also has a collection of one or more Roles. By
transitive association, if a user is in a group, then they also have the
group's roles. This is purely a convenience mechanism - many applications
(I dare say most) don't have the need for Groups at all. Similarly, many
simple applications don't use Permissions at all and get by on Roles only.
Hopefully the number of permutations based on application requirements can
give you insight as to why we don't provide 'write operations'. There's no
way to predict how application's will declare their data model.
I hope the above examples give some insight in to our decisions and perhaps
some ideas for your own data model.
Cheers,
Les
P.S. There has been some discussion to provide an out-of-the-box data model
that would employ what the Ki team feels are best practices, specifically to
kick-start many users who don't really want to think about the data model
design of flexible security systems. If created, it would definitely be
purely optional.
Re: Writing a custom authorization component...
Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Apr 5, 2009 at 3:00 PM, Sune Lindberg Riedel <sune.riedel@axiell.com
> wrote:
> Another huge black hole in our solution is: where is the API for **
> declaring** the roles and permissions for the different realms – I don’t
> see methods for setting roles and permissions anywhere in the Ki API’s (and
> neither in Spring Security, which we have also been investigating). In eg.
> JDBCRealm, there are nice queries for resolving roles and permissions, but
> how does the data get into these tables in the first place. What do people
> do when it comes to declaring this stuff? Is there a standard way to do
> this? Or some widely used standard products (that I have just missed)?
>
Just comments from another user of Ki, but I also have lots of experience on
Acegi/Spring Security as well CMA (Container Managed Authentication) and
JAAS. There are too many ways to map roles and permissions to your
persistence model to make any default implementation. In real world, users
often start with an existing user database (LDAP, Windows domain users, NIS
accounts etc.) and adapting it to a default implementation is often
impractical. Ki could supply some generic base interfaces that users can
choose to implement (which Spring Security does to some extent).
> So far the score between Ki and Spring Security are fairly even in our
> evaluation, but the architects who gave us this assignment, are really
> looking for alternatives, which also provides either a UI or at least a
> sensible API for managing users, roles, permissions etc. – and so far we
> have found nothing – I hope some of you security experts out there can point
> me in a promising direction… …or tell me, that we have to develop ourselves…
>
>
Authentication is very similar to Spring Security (even too much to my
liking, down to some Spring specific conventions e.g. afterPropertiesSet).
What makes a difference is the flexible permission model in Ki (dynamic,
instance-based permissions are just not in the scope of plain Spring
Security). Whether you need it or not, depends on the requirements of your
projects - for standard role-based permissions either would work absolutely
fine. I wouldn't expect or use any default UI/app for managing users - I
mean I'd hate to use a Java standalone app for user management if my
application was otherwise inherently web-based or the other way around.
There are plenty of CRUD application frameworks that you could use to
quickly build up a user management app.
Kalle
> *From:* les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] *On
> Behalf Of *Les Hazlewood
> *Sent:* Thursday, April 02, 2009 18:58
> *To:* jsecurity-user@incubator.apache.org
> *Subject:* Re: Writing a custom authorization component...
>
>
>
> Hi Sune!
>
> Sorry for the confusion - I replied to the forum earlier today, but you did
> the right thing by using the mailing list instead. I'll post my reply here
> for your (and others') benefit. I hope it helps. Please let us know if you
> have further questions!
>
> ----
>
> Sorry for the late reply - most traffic is on the mailing lists these days.
>
> Basically, I think you can make this work rather easily actually, even
> without overriding most of the infrastructure. Most users configure Realms
> and not much else, and I think you can get away with that as well.
>
> JSecurity (now called Ki) allows for multiple Realms to be configured in
> the application's SecurityManager instance. Assuming each 'level' (global,
> web site, and sub site) requires accessing a different data source, you
> would probably have 3 Realms configured - one for each level. The first time
> an authorization check (role, permission) is performed, each realm will do
> the required lookup and cache the results if possible. So, the first 2
> realms should work as normal.
>
> Your third 'sub site' realm can extend the AuthorizingRealm class, and when
> a user switches sites, you can write some framework code that calls
> yourAuthorizingRealmSubclass.clearCachedAuthenticationInfo(PrincipalCollection)
> for that user only. Then the next time a role check occurs on that sub-site
> Realm, it will force doGetAuthorizationInfo(principals) to be called again.
> Your implementation of this method can then access the appropriate 'sub
> site' data source, and the results will be cached for further use until you
> clear that cache entry again (presumably upon switching sites).
>
> Does that help? Feel free to ask more questions, but you might get a faster
> response on the Apache Ki mailing lists since the project has moved to the
> Apache infrastructure. The jsecurity.org website is just online primarily
> for archival purposes.
>
> Cheers,
>
> Les
>
>
>
> On Thu, Apr 2, 2009 at 1:37 AM, Sune Lindberg Riedel <
> sune.riedel@axiell.com> wrote:
>
> Hi!
>
> I tried to post my question below on the forum, but either nobody knows
> the answer or the amount of people who knows that answer and has time to
> help are too limited - so I will give it a shot on the mailing list - I
> am not looking for an answer that will provide me with the perfect
> solution - just some thoughts and ideas about how to make it work using
> JSecurity/Ki:
>
> I am currently working on a web project where some bright people
> thought: Hey, we need some authorization... ...cue ME!
>
> The Setup:
> The great thing about this project is, that so far we don't have any
> existing security model (like LDAP), so we can pretty much choose what
> we like.
>
> The not so brilliant thing (from a security/authorization point of view)
> is that we don't have a setup, where we can use the general user/role
> model.
>
> We have a setup where we have one central backend server - this is where
> the global user profiles are stored.
> We then have several "local" servers, each of which contains several web
> sites (which have their own unique URL's).
>
> A person only have one global user profile, but may have a local profile
> for each web site. The user may log on to any web site, where he has a
> local profile, and he may use his global username/password or the
> credentials he has for the local web site (if he uses the global
> username, we will look at the URL to figure out which local profile he
> has).
>
> Now the tricky part is the roles:
> - A user may have certain roles at the global level - these roles (and
> their permissions) are valid for all web sites he logs in to.
> - A user may have certain roles at the web site level - these roles are
> valid for the entire site (and sub-sites).
> - A user may have certain roles at a sub-site level - these roles are
> only valid for a particular subset of the website (typically a sub-URL)
> he is logged into.
>
> Now, the first two levels of roles can be determined at login time, but
> the roles that are only valid for a given sub-site, must be
> added/removed to the active set of roles/permissions whenever the user
> switches to another sub-site.
>
> The question:
> Now, I've looked a little at the documentation, examples and some source
> code of JSecurity/Ki and I am convinced that somehow we can make a
> solution with this - a good solution even. Unfortunately I'm no security
> expert, so I am struggling quite a bit, trying to figure out which
> classes I need replace in the default implementation with my own
> implementations to make this work. I figure I need to make a custom
> Authorizer at least, but I may also have to do my own implementations of
> AuthorizationInfo...
> Bottom line: I just don't get it - looking at the sample app, which
> instantiates a DefaultSecurityManager and uses Default[everything] -
> what do I replace to make a custom security solution, that will help me
> solve the scenario described above?
>
> Heeelp...
>
> Best Regards
> /Sune
>
>
>
RE: Writing a custom authorization component...
Posted by Sune Lindberg Riedel <su...@axiell.com>.
Hi Les (and everybody else)!
Thanks for answering my questions. J
I think I see, how to solve the problem with several realms. However, I don’t quite understand how to “resolve” which realms to use when a user logs in at a particular subsite. I mean, I know I have to use the global realm everytime, but when a user logs in to a subdomain under domain A, how do I make sure that the realm for domain A is “loaded” for this user?
I have just learned a little more about the system – we only have sessions on the sub-domain and domain levels, beyond this the application is stateless, so we need to provide userinformation (and information about domain/subdomain to resolve permissions) directly in the call to these services. I suppose we we can use some sort of AOP to intercept the method invocations and provide security in the part of the application, where we have a state (and a session), but how do we apply security in the sessionless part (the global backend mainly)?
Another huge black hole in our solution is: where is the API for *declaring* the roles and permissions for the different realms – I don’t see methods for setting roles and permissions anywhere in the Ki API’s (and neither in Spring Security, which we have also been investigating). In eg. JDBCRealm, there are nice queries for resolving roles and permissions, but how does the data get into these tables in the first place. What do people do when it comes to declaring this stuff? Is there a standard way to do this? Or some widely used standard products (that I have just missed)?
So far the score between Ki and Spring Security are fairly even in our evaluation, but the architects who gave us this assignment, are really looking for alternatives, which also provides either a UI or at least a sensible API for managing users, roles, permissions etc. – and so far we have found nothing – I hope some of you security experts out there can point me in a promising direction… …or tell me, that we have to develop ourselves…
Man, it’s uphill getting into this security stuff…
BR
/Sune
From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On Behalf Of Les Hazlewood
Sent: Thursday, April 02, 2009 18:58
To: jsecurity-user@incubator.apache.org
Subject: Re: Writing a custom authorization component...
Hi Sune!
Sorry for the confusion - I replied to the forum earlier today, but you did the right thing by using the mailing list instead. I'll post my reply here for your (and others') benefit. I hope it helps. Please let us know if you have further questions!
----
Sorry for the late reply - most traffic is on the mailing lists these days.
Basically, I think you can make this work rather easily actually, even without overriding most of the infrastructure. Most users configure Realms and not much else, and I think you can get away with that as well.
JSecurity (now called Ki) allows for multiple Realms to be configured in the application's SecurityManager instance. Assuming each 'level' (global, web site, and sub site) requires accessing a different data source, you would probably have 3 Realms configured - one for each level. The first time an authorization check (role, permission) is performed, each realm will do the required lookup and cache the results if possible. So, the first 2 realms should work as normal.
Your third 'sub site' realm can extend the AuthorizingRealm class, and when a user switches sites, you can write some framework code that calls yourAuthorizingRealmSubclass.clearCachedAuthenticationInfo(PrincipalCollection) for that user only. Then the next time a role check occurs on that sub-site Realm, it will force doGetAuthorizationInfo(principals) to be called again. Your implementation of this method can then access the appropriate 'sub site' data source, and the results will be cached for further use until you clear that cache entry again (presumably upon switching sites).
Does that help? Feel free to ask more questions, but you might get a faster response on the Apache Ki mailing lists since the project has moved to the Apache infrastructure. The jsecurity.org website is just online primarily for archival purposes.
Cheers,
Les
On Thu, Apr 2, 2009 at 1:37 AM, Sune Lindberg Riedel <su...@axiell.com> wrote:
Hi!
I tried to post my question below on the forum, but either nobody knows
the answer or the amount of people who knows that answer and has time to
help are too limited - so I will give it a shot on the mailing list - I
am not looking for an answer that will provide me with the perfect
solution - just some thoughts and ideas about how to make it work using
JSecurity/Ki:
I am currently working on a web project where some bright people
thought: Hey, we need some authorization... ...cue ME!
The Setup:
The great thing about this project is, that so far we don't have any
existing security model (like LDAP), so we can pretty much choose what
we like.
The not so brilliant thing (from a security/authorization point of view)
is that we don't have a setup, where we can use the general user/role
model.
We have a setup where we have one central backend server - this is where
the global user profiles are stored.
We then have several "local" servers, each of which contains several web
sites (which have their own unique URL's).
A person only have one global user profile, but may have a local profile
for each web site. The user may log on to any web site, where he has a
local profile, and he may use his global username/password or the
credentials he has for the local web site (if he uses the global
username, we will look at the URL to figure out which local profile he
has).
Now the tricky part is the roles:
- A user may have certain roles at the global level - these roles (and
their permissions) are valid for all web sites he logs in to.
- A user may have certain roles at the web site level - these roles are
valid for the entire site (and sub-sites).
- A user may have certain roles at a sub-site level - these roles are
only valid for a particular subset of the website (typically a sub-URL)
he is logged into.
Now, the first two levels of roles can be determined at login time, but
the roles that are only valid for a given sub-site, must be
added/removed to the active set of roles/permissions whenever the user
switches to another sub-site.
The question:
Now, I've looked a little at the documentation, examples and some source
code of JSecurity/Ki and I am convinced that somehow we can make a
solution with this - a good solution even. Unfortunately I'm no security
expert, so I am struggling quite a bit, trying to figure out which
classes I need replace in the default implementation with my own
implementations to make this work. I figure I need to make a custom
Authorizer at least, but I may also have to do my own implementations of
AuthorizationInfo...
Bottom line: I just don't get it - looking at the sample app, which
instantiates a DefaultSecurityManager and uses Default[everything] -
what do I replace to make a custom security solution, that will help me
solve the scenario described above?
Heeelp...
Best Regards
/Sune
Re: Writing a custom authorization component...
Posted by Les Hazlewood <lh...@apache.org>.
Hi Sune!
Sorry for the confusion - I replied to the forum earlier today, but you did
the right thing by using the mailing list instead. I'll post my reply here
for your (and others') benefit. I hope it helps. Please let us know if you
have further questions!
----
Sorry for the late reply - most traffic is on the mailing lists these days.
Basically, I think you can make this work rather easily actually, even
without overriding most of the infrastructure. Most users configure Realms
and not much else, and I think you can get away with that as well.
JSecurity (now called Ki) allows for multiple Realms to be configured in the
application's SecurityManager instance. Assuming each 'level' (global, web
site, and sub site) requires accessing a different data source, you would
probably have 3 Realms configured - one for each level. The first time an
authorization check (role, permission) is performed, each realm will do the
required lookup and cache the results if possible. So, the first 2 realms
should work as normal.
Your third 'sub site' realm can extend the AuthorizingRealm class, and when
a user switches sites, you can write some framework code that calls
yourAuthorizingRealmSubclass.clearCachedAuthenticationInfo(PrincipalCollection)
for that user only. Then the next time a role check occurs on that sub-site
Realm, it will force doGetAuthorizationInfo(principals) to be called again.
Your implementation of this method can then access the appropriate 'sub
site' data source, and the results will be cached for further use until you
clear that cache entry again (presumably upon switching sites).
Does that help? Feel free to ask more questions, but you might get a faster
response on the Apache Ki mailing lists since the project has moved to the
Apache infrastructure. The jsecurity.org website is just online primarily
for archival purposes.
Cheers,
Les
On Thu, Apr 2, 2009 at 1:37 AM, Sune Lindberg Riedel <sune.riedel@axiell.com
> wrote:
> Hi!
>
> I tried to post my question below on the forum, but either nobody knows
> the answer or the amount of people who knows that answer and has time to
> help are too limited - so I will give it a shot on the mailing list - I
> am not looking for an answer that will provide me with the perfect
> solution - just some thoughts and ideas about how to make it work using
> JSecurity/Ki:
>
> I am currently working on a web project where some bright people
> thought: Hey, we need some authorization... ...cue ME!
>
> The Setup:
> The great thing about this project is, that so far we don't have any
> existing security model (like LDAP), so we can pretty much choose what
> we like.
>
> The not so brilliant thing (from a security/authorization point of view)
> is that we don't have a setup, where we can use the general user/role
> model.
>
> We have a setup where we have one central backend server - this is where
> the global user profiles are stored.
> We then have several "local" servers, each of which contains several web
> sites (which have their own unique URL's).
>
> A person only have one global user profile, but may have a local profile
> for each web site. The user may log on to any web site, where he has a
> local profile, and he may use his global username/password or the
> credentials he has for the local web site (if he uses the global
> username, we will look at the URL to figure out which local profile he
> has).
>
> Now the tricky part is the roles:
> - A user may have certain roles at the global level - these roles (and
> their permissions) are valid for all web sites he logs in to.
> - A user may have certain roles at the web site level - these roles are
> valid for the entire site (and sub-sites).
> - A user may have certain roles at a sub-site level - these roles are
> only valid for a particular subset of the website (typically a sub-URL)
> he is logged into.
>
> Now, the first two levels of roles can be determined at login time, but
> the roles that are only valid for a given sub-site, must be
> added/removed to the active set of roles/permissions whenever the user
> switches to another sub-site.
>
> The question:
> Now, I've looked a little at the documentation, examples and some source
> code of JSecurity/Ki and I am convinced that somehow we can make a
> solution with this - a good solution even. Unfortunately I'm no security
> expert, so I am struggling quite a bit, trying to figure out which
> classes I need replace in the default implementation with my own
> implementations to make this work. I figure I need to make a custom
> Authorizer at least, but I may also have to do my own implementations of
> AuthorizationInfo...
> Bottom line: I just don't get it - looking at the sample app, which
> instantiates a DefaultSecurityManager and uses Default[everything] -
> what do I replace to make a custom security solution, that will help me
> solve the scenario described above?
>
> Heeelp...
>
> Best Regards
> /Sune
>