Les Following up on my last response-- Why collect credentials AND authorization related info through the get_account interface rather than query credentials, permissions, or roles when needed? I suspect that there may be a valid reason for your "get everything at once through get_account" concept but it eludes me.
On Mon, Sep 21, 2015 at 4:33 PM, Darin Gordon <[email protected]> wrote: > Using the LDAP + RDBMS example, let's suppose a login attempt is under > way. If you were to use a simple get_account interface to the > AccountStore(s), authentication is blocked until authorization privileges > are obtained. > > How about unpacking get_account into methods with more specific intent: > for Authentication AccountStores: get_credentials > For Authorization AccountStores: get_privileges, get_roles > > The goal is to query for what is needed and no more. Is authorization > data needed at a login attempt? > > Expanding the AccountStore interface upholds the principle of > Realm==interpret data, AccountStore==get data > > CompositeAccount doesn't seem consistent with this principle, though, as > business logic is controlling the packaging of "sub accounts" into a > composite. The Realm should know "who" to go to for what data, not an > AccountStore? > > > > > On Wed, Sep 9, 2015 at 2:04 PM, Les Hazlewood <[email protected]> > wrote: > >> 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) >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
