shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: shiro v2 proposal for realm-level authorization support
Date Wed, 09 Sep 2015 18:04:24 GMT
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)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message