shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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)

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <da...@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 <da...@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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <da...@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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Les Hazlewood <lh...@apache.org>]

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 <da...@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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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 <da...@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)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Les Hazlewood <lh...@apache.org>]

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 <da...@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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <lh...@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 <da...@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 <lh...@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 <da...@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 <da...@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)
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Les Hazlewood <lh...@apache.org>]

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 <da...@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 <lh...@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 <da...@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 <da...@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)
> > > >
> > > >
> > > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

Hey Les

Are you ready to move forward with v2 discussion?



On Thu, Aug 13, 2015 at 4:56 PM, Les Hazlewood <lh...@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 <da...@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 <da...@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)
> > >
> > >
> > >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Les Hazlewood <lh...@apache.org>]

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 <da...@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 <da...@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)
> >
> >
> >
>

Re: shiro v2 proposal for realm-level authorization support

[Darin Gordon <da...@gmail.com>]

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 <da...@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)
>
>
>