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: 
 <CAAtvD4UbOXvZ+q5BccQBwmzkpEP75ar3D_gyRcjoEH12u+AukA@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>
From: Darin Gordon <darinc@gmail.com>
Date: Mon, 21 Sep 2015 16:33:31 -0400
Message-ID: 
 <CAJTjJvXaFgh+3K0wzRA9mbkmWpBCmjrSA=51gu0HciWmL59oOQ@mail.gmail.com>
Subject: Re: shiro v2 proposal for realm-level authorization support
To: dev@shiro.apache.org
Content-Type: multipart/alternative; boundary=f46d04428f1cd4389f052047cdfb

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

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)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--f46d04428f1cd4389f052047cdfb--