Menu
▾
▴
jsecurity-authorization — Using JSecurity for access control (users, roles, groups, permissions, etc).
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
|---|
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-07 02:55:02
|
Relay from old forum ----------------------------------- Awesome - I'll make the change. Jeremy -- Sent from the JSecurity-Authorization forum at Nabble.com: http://www.nabble.com/AuthorizationContext-multiple-principals-t691831c13668.html#a1826038 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-07 02:54:39
|
Ahh, sorry about that - I must have missed that. Yes, lets add the methods you're talking about. You want to do it? -- Sent from the JSecurity-Authorization forum at Nabble.com: http://www.nabble.com/AuthorizationContext-multiple-principals-t691831c13668.html#a1826033 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-07 02:54:18
|
Relay from old forum
---------------------------------
Yes. I was actually arguing that we could have the best of both worlds in my post. See the "And of course, we would keep the setPrincipal and getPrincipal methods so that applications that only use a single principal could ignore the complexity of multiple principals." comment in the previous post.
I would actually see the method looking something more like this:
public Principal getPrincipal() {
if( getPrincipals().size() > 1 ) {
throw new IllegalStateException( ... );
}
return getPrincipals().iterator().next();
}
Of course, that also depends on the implementation of your AuthorizationContext. The example above would be for an unordered set of principals like the current JSecurity default implementation, where returning the first principal in an iterator would have non-deterministic behavior and therefore be illegal.
Jeremy Haile
--
Sent from the JSecurity-Authorization forum at Nabble.com:
http://www.nabble.com/AuthorizationContext-multiple-principals-t691831c13668.html#a1826029
|
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-07 02:53:46
|
I would argue that with a vast majority of applications, a single principal is all that is needed to identify the current user - usually a user ID or a username. Once an application knows this, they can get all other principals by querying the db for the User and getting the other principals from that.
Applications that are stateless (in as much as is possible) would just store the primary user principal in a session and subsequently query for the User every time. If the worry is about query performance, enable an enterprise cache (Ehcache, OS Cache, etc) to keep your programming model stateless yet high-performing.
The other principals are almost always generally inferred or accessible by knowing the primary principal.
Now, all that being said, I can see a benefit for supporting multiple principals for convenience's sake and fringe cases. But I'm still on the fence as to whether or not the public API should support this. It might impose unnecessary complexity to the majority of applications that almost always use a username or user ID.
After thinking about it for a bit, maybe we could have the best of both worlds? Perhaps something like:
getPrincipals(): Set
getPrincipal() : Principal
getPrincipal() would return the primary identifying principal used by the application - maybe like this:
public Principal getPrincipal() {
//just an example - we'd have to check for nulls, refine, etc.
return getPrincipals().iterator().next();
}
unfortunately, there is no guarantee the first element returned from the iterator is the 'primary' principal. We'd have to think through that to make a clean implementation.
The point is that most apps could use the getPrincipal() the majority of the time and that the specialized/fringe apps could use the getPrincipals() method if they wanted all of them. This would also make JAAS integration a little easier as well, since we could mirror to the Subject.getPrincipals() method.
As long as the JavaDoc is clear on both methods, I think this would work well.
What do you think?
--
Sent from the JSecurity-Authorization forum at Nabble.com:
http://www.nabble.com/AuthorizationContext-multiple-principals-t691831c13668.html#a1826024
|
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-07 02:51:51
|
Just relaying this from the old forums: ------------------ In many applications, a single principal is enough information to identify the current user. For example, a username or user ID. JSecurity supports a single principal to be associated with a user via the AuthorizationContext that is constructed when a user authenticates. However, many applications also have several different principals that could represent a user. For example, an application may associate a user ID, a username, and a public key with each user. In various cases, one or more of these principals may be required to make security or access decisions. So the question I am raising is whether or not JSecurity should support associating multiple principals with a user via their AuthorizationContext. There are a few alternatives that have been suggested for how to accomplish this: 1) Add explicit support to the AuthorizationContext class to allow multiple principals. This is exactly how JAAS currently support principals. A subject may have a set of principals associated with it. JSecurity would probably add a few different methods to make dealing with multiple principals, such as getAllPrincipals():Set , getPrincipalOfType( Class ), getRequiredPrincipalOfType(Class), etc. And of course, we would keep the setPrincipal and getPrincipal methods so that applications that only use a single principal could ignore the complexity of multiple principals. The upside of this solution is that it is very clean when dealing with multiple principals and allows security code to only retrieve the type of principal that it expects. The downside is that it introduces more methods into the AuthorizationContext API and makes the API look more complex, especially if the applications that need this complexity are the minority 2) Use a composite principal class to encapsulate the multiple principals. In this solution, the current implementation would remain unchanged, but the principal returned would either be a CompositePrincipal type that wraps a set of principals or it would be a principal specific to the application (e.g. MyApplicationPrincipal) that encapsulates several principals. The upside of this solution is that it requires no API changes to JSecurity and maintains the simple API that will be sufficient for most applications. The downside is that it prevents JSecurity from offering helper methods that would make it very easy to deal with multiple principals. It also forces security code to be aware of the fact that an application does or doesn't use composite principals. For example, using this solution an application would have to retrieve the composite principal and then retrieve the principal it needed. Wheras using solution #1, the application could simply call getRequiredPrincipalOfType( UsernamePrincipal.class ) and have no knowledge of a composite principal. 3) Store a Map of arbitrary properties in the AuthorizationContext. Another idea is to allow the AuthorizationContext to store an arbitrary map of properties that could contain principals or any other security-context related information. The upside of this solution is that it is very flexible, and would allow the software to store any information in the AuthorizationContext that it needs. The downside is that it could easily be misused as a replacement for storing information in the session that shouldn't really be the responsibilty (and may be very inefficient) to store in JSecurity. Also, it genericizes principals so that a user of the JSecurity API really would have no idea what is contained within the map. Finally, it removes type-saftey since an arbitrary map could not know what someone may put in it. My personal preference is #1. I think #3 is the worst option, since it invites the possibility of misues. But please let me know your opinions! Jeremy Haile -- Sent from the JSecurity-Authorization forum at Nabble.com: http://www.nabble.com/AuthorizationContext-multiple-principals-t691831c13668.html#a1826010 |
|
From: Les A. H. <le...@ha...> - 2005-12-06 03:49:34
|
Welcome to the JSecurity-Authorization integrated mailing list / support forum. Please use this list/forum for questions about using JSecurity to provide access control (users, groups, roles, permissions, etc). |
