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 |