[security-dev] Entitlement versus Enforcement Model

[Anil Saldhana]

On 11/07/2012 03:05 PM, Bill Burke wrote:
> 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.
Bill, last time I mentioned JWT and JWE, you chewed me. Yeah, pretty 
lightweight stuff and applicable to REST style services.
It is possible that JWT lacks the richness that may be desired in a 
token, for certain usecases. I have not come across those use cases yet 
apart from serving SAML users over a REST style interface with JSON binding.

>
> 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
>>
>>
>>