Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
MIME-Version: 1.0
From: Darin Gordon <darinc@gmail.com>
Date: Fri, 7 Aug 2015 15:46:25 -0400
Message-ID: 
 <CAJTjJvU2y3t022vzxbEiwDVG9hn68e7rRO0xgr6dttvSRqpgsg@mail.gmail.com>
Subject: shiro v2 proposal for realm-level authorization support
To: dev@shiro.apache.org
Content-Type: multipart/alternative; boundary=089e011602b27a4b12051cbde65b

--089e011602b27a4b12051cbde65b
Content-Type: text/plain; charset=UTF-8

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)

--089e011602b27a4b12051cbde65b--