Thanks for providing that high level overview. This is as I understood it based on the comments, docs, and the v2 alpha. Let's go a level deeper. The devil is in the details.
If I understand you correctly, ALL account security details-- authentication and authorization -- generally reside within the same datastore. OK. This makes sense when the store is a database. However, what about a realistic scenario where the underlying store is an LDAP directory? A LDAP-based AccountStore's getAccount method would take a token as input and return an Account object that only includes credentials. Another realm would need to consulted by the realm to obtain authorization privileges, but this time using the Account object obtained from the LDAP store as input (rather than a token). For your 1:1 correlation to still hold true, the LDAP account <> the authz account *for the same user*. That doesn't seem likely if we're talking about User accounts. User Account abc123 has its credentials in LDAP and its privileges in a relational database. Both stores reference parts of the same account. Using AccountStores in a compositional way, you would have 3 AccountStore interfaces. This goes back to my original proposal: interface 1: AccountStore (abstract: getAccount) interface 2: AuthenticatingAccountStore (includes the "authenticationinfo" kind of abstract method specifications) interface 3: AuthorizingAccountStore (includes the "authorizationinfo" kind of abstract method method specifications) Thoughts? On Tue, Sep 8, 2015 at 2:14 PM, Les Hazlewood <[email protected]> wrote: > 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) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
