[security-dev] Entitlement versus Enforcement Model

[Jason Porter]

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> 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
> > 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
> 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, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121107/aad19a47/attachment-0001.html