I'm traveling and will be out until Monday, August 24th. I'd like to dig in to this but won't have time until then. :/
-- Les On Thu, Aug 13, 2015 at 5:59 AM, Darin Gordon <[email protected]> wrote: > All > This was sent a week ago. Would anyone like to comment or is this topic > not open for broader group discussion? I do not know the background of the > new 2.0 AccountStoreRealm model nor what its creator(s) are envisioning for > it. It would be helpful for all to understand! > > Thanks > > > > > > > > On Fri, Aug 7, 2015 at 3:46 PM, Darin Gordon <[email protected]> wrote: > > > All > > > > For your consideration.. I tried my best to edit this draft but didn't > > want to delay it further. I will clarify any points as needed: > > > > There remains a general lack of support for realm-level authorization in > > the new > > shiro v2 and there is no specification for how Shiro will provide it. > So, > > to facilitate > > discussion, and for your consideration, is a proposal for doing so. > > > > In Summary: > > 1) Expand use of the Account object to include information used for authz > > 2) deprecate the AuthorizationInfo object model as it is replaced by the > > revised Account object > > 3) Define 2 new interfaces for the AccountStore to facilitate requests > for > > credentials or privileges > > 4) Define 2 new interfaces for the AccountStoreRealm to facilitate > > authentication > > and authorization > > 5) consolidate the A.S.R.'s cache handling to a single method-- account > > cache handling > > > > > > Details: > > > > Account > > ==================== > > Generally speaking, a user account entity includes identifiers > > (principals), credentials. > > Further, an account has access privileges. The latest Shiro v2 > > implementation > > is as if one side of a coin has been addressed to support use of an > > Account object > > yet the other side hasn't yet been touched: the AuthenticationInfo object > > is deprecated, > > yet the AuthorizationInfo object isn't. > > > > In v2, the legacy "information object", AuthenticationInfo, is replaced > > by a more intuitive Account object. This Account object currently > > contains an > > accountID, credentials, and identifiers (attributes). With this object > > specification, > > an Account object can satisfy authentication attempts. > > > > Unfortunately, with this design another legacy "information object" -- > > the AuthorizationInfo object -- must still be created and used to > > facilitate authorization. > > > > What I mean with the coin metaphor is that who a user is, how a user's > > identity > > is confirmed, and what that user can do in a system are all considered > > within > > the context of an Account: > > I) Who a user is = Identifiers (formerly Principals) > > II) Confirming identity = Credentials > > III) What a user can do = Privileges > > > > > > AccountStore > > ==================== > > An AccountStore is the intermediary between a realm and a data store. > > An AccountStore obtains Account information -- who a user is, how a user > > is > > identified, and/or what that user can do in an application -- from a > data > > store > > and returns it in the form of an Account object to the realm that is > > requesting > > this information. > > > > An AccountStore MAY OR MAY NOT interact with an all-inclusive, > > comprehensive > > data source containing all application security related information. In > > an > > enterprise, there may be multiple data stores used for application > > security. > > For instance, an enterprise may use one data store to obtain > > authentication > > credentials (LDAP). Another data store may be consulted to obtain access > > control > > privileges (RDBMS). > > > > Therefore, an AccountStore MAY OR MAY NOT return a comprehensive Account > > object that > > contains all security-related information (credentials and privileges). > > > > With this given, I propose that two AccountStore interfaces be created: > > 1) CredentialsAccountStore > > 2) PrivilegesAccountStore > > > > Doing so allows gives a developer the flexibility to implement in an > > AccountStore > > support for one or both information gathering responsibilities with any > > given data store. > > > > > > AccountStoreRealm > > ==================== > > The AccountStoreRealm (A.S.R.) is the AccountStore (A.S.) liaisan. > > Contrary > > to what has been stated in v2 code comments, there need not be a 1:1 > > relationship > > between an A.S.R. and an A.S. > > - An A.S. may realistically only communicate with no more than one > > A.S.R., > > but it has an interface that would allow any other to issue > requests > > with > > it > > - An A.S.R , if it handles authentication AND authorization requests, > > will likely communicate with more than one AccountStore (such as > when > > LDAP is used for authc and an RDBMS is used for authz info) > > > > > > >
