I just got back from vacation - I should be ready for some good discussion starting next week (probably Tuesday).
Cheers, -- Les On Fri, Aug 28, 2015 at 4:06 AM, Darin Gordon <[email protected]> wrote: > 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) > > > > > > > > > > > > > > > > > >
