Les could we start this by sharing the vision for what the AccountStore model entails? I've been making a lot of assumptions. An Account has not only credentials but also privileges and so an Account object *could* easily include both within its scope of use without violating any principles. An AccountStore could be used to obtain Account metadata. Another AccountStore could be used to obtain credentials, and another for privileges. Two out of three of these stores use Account objects as input and returns them.
Again, curious what you've been envisioning! On Fri, Aug 28, 2015 at 4:21 PM, Les Hazlewood <[email protected]> wrote: > 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) > > > > > > > > > > > > > > > > > > > > > > > > >
