Hey Les I'm following up regarding my last inquiry. Why get_account rather than query for more specific credentials or authorization info?
On Sun, Sep 27, 2015 at 8:17 AM, Darin Gordon <[email protected]> wrote: > 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) >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> >> >> >
