[security-dev] Entitlement versus Enforcement Model

[Bill Burke]

I committed some preliminary work a few months ago to prototype 
Openstack's Keystone service and protocol.  I want to ditch this work 
though in favor of developing my own protocol as it seems Keystone is 
very much in flux and they aren't sure of their own direction.  It as a 
good exercise though as I learned how AS7 and login-modules can fit 
together and how you can dynamically set roles/identity *per-request*. 
I also wrote a little utility that allows you to delegate authentication 
to your security domain. (login-module-authenticator)

https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-key-idm

I just started on my new (well really long time brewing) ideas this week 
as Resteasy 3.0 beta 1 is now out.  I plan on using JSON Web Token and 
JSON Web Signatures.  After evaluating these specs, they look very tight 
and simple enough to build upon.

On 11/7/2012 2:36 PM, Jason Porter wrote:
> Thanks Bill, that's an interesting idea. Where's your prototype?
>
>
> On Wed, Nov 7, 2012 at 12:21 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     I'm working on prototype/protocol that combines client-cert and signed
>     tokens.
>
>     Token is signed by the IDP and contains:
>     * user identity
>     * roles/permissions
>     * expiration/timestamp
>
>     Client makes an SSL client-verified connection to server and passes the
>     IDP-signed token.  Server verifies the client-cert.  Verifies the
>     IDP-signed token.  Matches the client-cert's identity to the user
>     identity in the token.  If everything is cool, server grants the
>     roles/permissions within the token.
>
>     What's cool about this is that the token could contain multiple
>     user/permission sets, so, if the initial service is a middleman and has
>     to make a bunch of cooridnated requests, it doesn't have to go back to
>     the IDP *ever* as long as it has the public keys of the IDPs it trusts.
>        It can just forward the token around.  In fact, the token can be
>     forwarded around as many times as needed.
>
>     Can work with browser-based apps, but its a pain to provision.  Instead,
>     for browser based apps, the initial auth could be done using OAuth2.
>     Server would get a signed token using the OAuth2 protocol.  Not as
>     secure as the addition of client-certs, but still good.
>
>
>     On 11/7/2012 10:53 AM, Anil Saldhana wrote:
>      > Hi All,
>      >     this is an issue I see more at a client (in the classic
>     client/server
>      > paradigm) that the computing industry is moving toward.
>      >
>      > With the increasing push towards mobility, cloud and REST
>      > architectures,  I think access control decisions may have to be made
>      > where a decision is needed.  So instead of making 100 authorization
>      > calls to the server, we need a model where one call is made to the
>      > server (given user, context etc) and we get back a set of
>     entitlements
>      > (or permissions) that need to be applied at the client side.
>      >
>      > Examples include a mobile client (such as banking) that needs to
>     figure
>      > out what aspects of the mobile screen the user is entitled to see and
>      > what operations he is capable of performing.
>      >
>      > The industry has put too much emphasis on the enforcement model
>      > (meaning, make 100 authorization calls to the glorified server).
>     There
>      > has been almost no models for the entitlement approach.
>      >
>      > I have prototyped something here:
>      > https://docs.jboss.org/author/display/SECURITY/EntitlementsManager
>      >
>      > The entitlements should be sent in a JSON response.
>      >
>      > Also, trying to get this standardized in the industry via the OASIS
>      > Cloud Authorization TC.
>      >
>     https://lists.oasis-open.org/archives/oasis-charter-discuss/201210/msg00003.html
>      >
>      > I have a hunch that projects such as Aerogear, Drools, Errai and
>      > Infinispan may need this model.
>      >
>      > Thoughts?
>      >
>      > Regards,
>      > Anil
>      > _______________________________________________
>      > security-dev mailing list
>      > security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/security-dev
>      >
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     security-dev mailing list
>     security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/security-dev
>
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net <http://keyserver.net>, pgp.mit.edu
> <http://pgp.mit.edu>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com