shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darin Gordon <dar...@gmail.com>
Subject Re: shiro v2 proposal for realm-level authorization support
Date Sat, 03 Oct 2015 10:48:51 GMT
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 <darinc@gmail.com> 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 <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)
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

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