[security-dev] Entitlement versus Enforcement Model
Anil Saldhana
Anil.Saldhana at redhat.com
Wed Nov 7 15:28:13 EST 2012
On 11/07/2012 01:21 PM, Bill Burke 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
Bill, this translates to a SAML Response from an IDP that contains
Authentication Statement (who the user is, who issued the assertion,
public key of the IDP etc) and attribute Statements (roles/permissions
can be viewed as attributes an identity has).
If we can somehow translate this entire thing into a JSON construct, it
will be lightweight and cool.
>
> 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.
Perfect...
> 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
More information about the security-dev
mailing list