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