Hey Les Are you ready to move forward with v2 discussion?
On Thu, Aug 13, 2015 at 4:56 PM, Les Hazlewood <[email protected]> wrote: > 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) > > > > > > > > > > > >
