shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darin Gordon <>
Subject Re: shiro v2 proposal for realm-level authorization support
Date Thu, 13 Aug 2015 12:59:00 GMT
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!


On Fri, Aug 7, 2015 at 3:46 PM, Darin Gordon <> 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)

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