Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJTjJvXaFgh+3K0wzRA9mbkmWpBCmjrSA=51gu0HciWmL59oOQ@mail.gmail.com>
References: 
 <CAJTjJvU2y3t022vzxbEiwDVG9hn68e7rRO0xgr6dttvSRqpgsg@mail.gmail.com>
 <CAJTjJvXK2NuEPmnq1vowxXzaEKR4R4SjfCeBiSsyd0DO2ARHpQ@mail.gmail.com>
 <CAAtvD4XR-GFh1BueUsFhPZ4-ywOTf9KEV7-dQN=QUExnvEKpzg@mail.gmail.com>
 <CAJTjJvWMMvgW63tYtGe2EKZ0qwrB5jqTsgPKe_GtjShES5_uFQ@mail.gmail.com>
 <CAAtvD4WBs-nAhueviRSCbAFgyg59OrcpgvGw5=6XtbkBjQMamA@mail.gmail.com>
 <CAJTjJvWjrMvhyXvaQC_QtvyFUTYDpUq+Pf_sp4i7R=vLcjtoiQ@mail.gmail.com>
 <CAAtvD4X23_wpu5N0JhKVmEpOhmgKxBm-YVTqtfvNdCUigh89ow@mail.gmail.com>
 <CAJTjJvWUzTmw8_Wp7_WSXt+t5fBZX0NeZuZg2cgtWkc65ZAWCQ@mail.gmail.com>
 <CAAtvD4UbOXvZ+q5BccQBwmzkpEP75ar3D_gyRcjoEH12u+AukA@mail.gmail.com>
 <CAJTjJvXaFgh+3K0wzRA9mbkmWpBCmjrSA=51gu0HciWmL59oOQ@mail.gmail.com>
From: Darin Gordon <darinc@gmail.com>
Date: Sun, 27 Sep 2015 08:17:56 -0400
Message-ID: 
 <CAJTjJvVD_MmbjK6PV3m53tgdx=65FxmdtDX2_tp_coj6dbkk9Q@mail.gmail.com>
Subject: Re: shiro v2 proposal for realm-level authorization support
To: dev@shiro.apache.org
Content-Type: multipart/alternative; boundary=001a11c14caa84662b0520b994a4

--001a11c14caa84662b0520b994a4
Content-Type: text/plain; charset=UTF-8

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 <darinc@gmail.com> 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 <lhazlewood@apache.org>
> 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 <darinc@gmail.com> 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 <lhazlewood@apache.org>
>> > 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 <darinc@gmail.com>
>> 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 <
>> lhazlewood@apache.org>
>> > > > 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 <darinc@gmail.com>
>> > > wrote:
>> > > > >
>> > > > > > Hey Les
>> > > > > >
>> > > > > > Are you ready to move forward with v2 discussion?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Aug 13, 2015 at 4:56 PM, Les Hazlewood <
>> > > lhazlewood@apache.org>
>> > > > > > 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 <
>> darinc@gmail.com>
>> > > > > 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 <
>> darinc@gmail.com
>> > >
>> > > > > 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)
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

--001a11c14caa84662b0520b994a4--