Hi Darin (and others)! Of course when you go on vacation, you come home to a mountain of catch-up work. Gratefully, I've caught up and can address these questions :)
The AccountStore concept was introduced because in Shiro 1.x, almost all Realm implementations looked and worked the same (pluggable caching, etc), and the only real difference between most of them was the account storage/lookup operations. In Shiro 2.x, we're trying to favor composition over inheritance almost everywhere that makes sense, and so it was a natural thing to have a default Realm concept (currently called AccountStoreRealm) that captured all the default behaviors that most people wanted and introduce a new pluggable component that just abstracted out interaction with a data store. That new component is the AccountStore. It is effectively the same thing as a 'Repository' or 'DAO', depending on your terminology preference. This model allows you to plug-and-play data stores more easily, rather than having to re-write realm implementations (much nicer). In the large majority of account data store implementations I've seen, there is a 1:1 correlation between accounts and storage location, so I think most AccountStore implementations will just 'talk' to only one data store. However, all Shiro cares about when interacting with an AccountStore is that it gets an Account back. Because an Account is an interface, you can have an implementation reflect data obtained from more than one data store if desired - Shiro wouldn't care, and you have total flexibility in obtaining that information however you wish. Additionally, there is a CompositeAccount concept (still in development, I wouldn't rely on it too much yet) that could aggregate data from different account stores and represent it as a single Account as far as Shiro is concerned. I hope that helps! -- Les On Sun, Sep 6, 2015 at 4:10 AM, Darin Gordon <[email protected]> wrote: > 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) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
