The AccountStore concept exists to only abstract away the details of how to obtain persistent account information. All the details available for authentication or authorization don't *have* to be in a single AccountStore - they could come from different locations in some cases, at which point they could be aggregated into a single Account instance (via the CompositeAccount concept I mentioned earlier). I'd say 90% of the realm implementations I've ever seen by Shiro users use one and only one data store. However, this 1:1 correlation is not *required* in Shiro - you can compose different data stores if necessary as discussed previously.
However, *how* that information is interpreted for the purpose of authentication and authorization is the responsibility of the Realm concept (AccountStore == get data, Realm == interpret data). The Realm is free to do whatever it wants to find out authentication or authorization information and interpret that accordingly. The AccountStoreRealm exists as a convenience where there is one (or a few) data source(s) where the account information can easily be represented as (composed into) a single Account instance. If this model causes more problems than it helps in your particular use case, you don't need to use the AccountStore or AccountStoreRealm concept at all - you can implement the Realm interface directly and have it do whatever you prefer. So in summary: Shiro's authentication and authorization components don't care about (or even know about) an 'AccountStore' concept - Shiro's other components always talk to Realms. The Realm implementation is free to do whatever it likes to perform an authentication or authorization check. *Most* Realms however have the same exact behavior (caching, logout invalidation, etc) and differ only based on the data store(s) accessed. For scenarios where this is true (and this is largely true for most Shiro users), the AccountStoreRealm can be used easily to 'point' to whatever AccountStore you need to support. If the AccountStore concept complicates things more than it helps in a particular use case, the recommendation is to implement the Realm interface directly to do what you want. For the example of credentials in LDAP but permissions in an RDBMS and you wanted to leverage the AccountStoreRealm concept, the following could work nicely: 1. Create an LdapAccountStore that looks up an account w/ credentials for authentication 2. Create an RdbmsAccountStore (JdbcAccountStore?) that looked up permissions for authorization 3. Create a CompositeAccountStore that 'wraps' 1 and 2. Upon login, the CompositeAccountStore invokes the LdapAccountStore to get the account. If found, it then calls the RdbmsAccountStore for the account's permissions. After obtaining both, it returns a single Account instance that contains both pieces of data. 4. The AccountStoreRealm that invokes your CompositeAccountStore 'sees' only a single Account instance, not knowing that the data came from 2 places. But again, if this doesn't work well for whatever reason, you can always implement the Realm interface. I hope this helps! -- Les On Tue, Sep 8, 2015 at 12:49 PM, Darin Gordon <[email protected]> wrote: > 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) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
