shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darin Gordon <>
Subject shiro v2 proposal for realm-level authorization support
Date Fri, 07 Aug 2015 19:46:25 GMT

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
   and authorization
5) consolidate the A.S.R.'s cache handling to a single method-- account
cache handling


Generally speaking, a user account entity includes identifiers
(principals), credentials.
Further, an account has access privileges.  The latest Shiro v2
is as if one side of a coin has been addressed to support use of an Account
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
accountID, credentials, and identifiers (attributes).  With this object
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
is confirmed, and what that user can do in a system are all considered
the context of an Account:
I) Who a user is = Identifiers (formerly Principals)
II) Confirming identity = Credentials
III) What a user can do  = Privileges

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
 and returns it in the form of an Account object to the realm that is
this information.

An AccountStore MAY OR MAY NOT interact with an all-inclusive,
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
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
support for one or both information gathering responsibilities with any
given data store.

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
between an A.S.R. and an A.S.
    - An A.S. may realistically only communicate with no more than one
      but it has an interface that would allow any other to issue requests
    - 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