[security-dev] Entitlement versus Enforcement Model
lightguard.jp at gmail.com
Wed Nov 7 14:36:27 EST 2012
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
> 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.
> > 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
> security-dev mailing list
> security-dev at lists.jboss.org
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security-dev