shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: shiro v2 proposal for realm-level authorization support
Date Thu, 13 Aug 2015 20:56:10 GMT
I'm traveling and will be out until Monday, August 24th.  I'd like to dig
in to this but won't have time until then. :/

--
Les

On Thu, Aug 13, 2015 at 5:59 AM, Darin Gordon <darinc@gmail.com> wrote:

> All
> This was sent a week ago.  Would anyone like to comment or is this topic
> not open for broader group discussion?  I do not know the background of the
> new 2.0 AccountStoreRealm model nor what its creator(s) are envisioning for
> it.  It would be helpful for all to understand!
>
> Thanks
>
>
>
>
>
>
>
> On Fri, Aug 7, 2015 at 3:46 PM, Darin Gordon <darinc@gmail.com> wrote:
>
> > All
> >
> > For your consideration.. I tried my best to edit this draft but didn't
> > want to delay it further.  I will clarify any points as needed:
> >
> > There remains a general lack of support for realm-level authorization in
> > the new
> > shiro v2 and there is no specification for how Shiro will provide it.
> So,
> > to facilitate
> > discussion, and for your consideration, is a proposal for doing so.
> >
> > In Summary:
> > 1) Expand use of the Account object to include information used for authz
> > 2) deprecate the AuthorizationInfo object model as it is replaced by the
> >    revised Account object
> > 3) Define 2 new interfaces for the AccountStore to facilitate requests
> for
> >    credentials or privileges
> > 4) Define 2 new interfaces for the AccountStoreRealm to facilitate
> > authentication
> >    and authorization
> > 5) consolidate the A.S.R.'s cache handling to a single method-- account
> > cache handling
> >
> >
> > Details:
> >
> > Account
> > ====================
> > Generally speaking, a user account entity includes identifiers
> > (principals), credentials.
> > Further, an account has access privileges.  The latest Shiro v2
> > implementation
> > is as if one side of a coin has been addressed to support use of an
> > Account object
> > yet the other side hasn't yet been touched: the AuthenticationInfo object
> > is deprecated,
> > yet the AuthorizationInfo object isn't.
> >
> > In v2, the legacy "information object", AuthenticationInfo, is replaced
> > by a more intuitive Account object.  This Account object currently
> > contains an
> > accountID, credentials, and identifiers (attributes).  With this object
> > specification,
> > an Account object can satisfy authentication attempts.
> >
> > Unfortunately, with this design another legacy "information object" --
> > the AuthorizationInfo object -- must still be created and used to
> > facilitate authorization.
> >
> > What I mean with the coin metaphor is that who a user is, how a user's
> > identity
> > is confirmed, and what that user can do in a system are all considered
> > within
> > the context of an Account:
> > I) Who a user is = Identifiers (formerly Principals)
> > II) Confirming identity = Credentials
> > III) What a user can do  = Privileges
> >
> >
> > AccountStore
> > ====================
> > An AccountStore is the intermediary between a realm and a data store.
> > An AccountStore obtains Account information -- who a user is, how a user
> > is
> > identified, and/or what that user can do in an application --  from a
> data
> > store
> >  and returns it in the form of an Account object to the realm that is
> > requesting
> > this information.
> >
> > An AccountStore MAY OR MAY NOT interact with an all-inclusive,
> > comprehensive
> > data source containing all application security related information.  In
> > an
> > enterprise, there may be multiple data stores used for application
> > security.
> > For instance, an enterprise may use one data store to obtain
> > authentication
> > credentials (LDAP).  Another data store may be consulted to obtain access
> > control
> > privileges (RDBMS).
> >
> > Therefore, an AccountStore MAY OR MAY NOT return a comprehensive Account
> > object that
> > contains all security-related information (credentials and privileges).
> >
> > With this given, I propose that two AccountStore interfaces be created:
> >     1) CredentialsAccountStore
> >     2) PrivilegesAccountStore
> >
> > Doing so allows gives a developer the flexibility to implement in an
> > AccountStore
> > support for one or both information gathering responsibilities with any
> > given data store.
> >
> >
> > AccountStoreRealm
> > ====================
> > The AccountStoreRealm (A.S.R.) is the AccountStore (A.S.) liaisan.
> > Contrary
> > to what has been stated in v2 code comments, there need not be a 1:1
> > relationship
> > between an A.S.R. and an A.S.
> >     - An A.S. may realistically only communicate with no more than one
> > A.S.R.,
> >       but it has an interface that would allow any other to issue
> requests
> > with
> >       it
> >     - An A.S.R , if it handles authentication AND authorization requests,
> >       will likely communicate with more than one AccountStore (such as
> when
> >       LDAP is used for authc and an RDBMS is used for authz info)
> >
> >
> >
>

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