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/msg000... 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 11/07/2012 10:28 AM, Jason Porter wrote: > This is something I've been thinking about actually. A small side project I'm working on during the late hours of the evening is going to be doing something like this. My current line of thinking is to authenticate once and pass back a token then double check the token and IP address with each request and have a server side timeout for their authorized session. I know it's not the same as what you're talking about, but I couldn't come up with anything good to stop spoofing a valid token and also enforcing a time limit to a secure session. Jason - good thinking. What you are trying to do maps perfectly into a SAML rich structure but exceeds the JSON Web Token work (JWT http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05) that is going on in IETF. Toward this, I have been thinking that we definitely need a JSON Token representation of the SAML XML structure (that can capture identity, authentication, attribute, authorization decisions etc). Basically a literal translation of the SAML XML structures into JSON.

> > > On Wed, Nov 7, 2012 at 8:53 AM, Anil Saldhana <Anil.Saldhana(a)redhat.com&gt; 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/msg000... >> >> I have a hunch that projects such as Aerogear, Drools, Errai and >> Infinispan may need this model. >> >> Thoughts? >> >> Regards, >> Anil

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/msg000... > > 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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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

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(a)redhat.com > <mailto:bburke@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/msg000... > > > > 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(a)lists.jboss.org <mailto:security-dev@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(a)lists.jboss.org <mailto:security-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/security-dev > > >

On 11/7/2012 4:09 PM, Anil Saldhana wrote: > 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-... >> >> 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. > Yup, I was wrong about JWS and JWE. When I chewed you, i was thinking more about HTTP message bodies, and not thinking about URLs and header strings. Keystone uses application/pks7-signature, which is a possibility too, but I don't know how viable it is within javascript. JWS/JWE already has code here. Bill

On 11/7/2012 4:34 PM, Anil Saldhana wrote: > On 11/07/2012 03:26 PM, Bill Burke wrote: >> On 11/7/2012 4:09 PM, Anil Saldhana wrote: >>> 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-... >>>> >>>> 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. >>> >> Yup, I was wrong about JWS and JWE. When I chewed you, i was thinking >> more about HTTP message bodies, and not thinking about URLs and header >> strings. Keystone uses application/pks7-signature, which is a >> possibility too, but I don't know how viable it is within javascript. >> JWS/JWE already has code here. >> >> Bill >> > Bill, dont write any JWS/JWE implementation because this Duetsche > Telecom researcher has done implementation of the latest drafts of these > specs. https://code.google.com/p/jsoncrypto/ > The challenge I have with this project is that the code is not indented > properly and not readable. Build is not mavenized. It is BSD licensed. I > was supposed to help him with the project code organization, maven etc. > > I only implemented the bare minimum JWE/JWS algorithms we require with > the intent of integrating jsoncrypto. > https://docs.jboss.org/author/display/SECURITY/JSON+Security > There's this too: https://bitbucket.org/nimbusds/nimbus-jose-jwt/wiki/Home

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/msg000... > > I have a hunch that projects such as Aerogear, Drools, Errai and > Infinispan may need this model. > > Thoughts? > > Regards, > Anil

On 11/7/2012 3:28 PM, Anil Saldhana wrote: > 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. > Translating all the verbose nonsense contained in SAML documents to the much simpler domain of Java EE role-based model is something you'll have to do anyways. You probably have *already* it. :) What I want to see happen is ditching SAML entirely for a very tight token format that is as small as possible. If you follow this route, you can include signed tokens within URLs (Will work great with OAuth2). SAML documents are just WAY too big for these types of redirection protocols. IMO, SAML is ridiculous. All the metadata a service needs in an authenticated request is really userid, permission metadata, and maybe a URL that references the full information about that user. If the service wants information like first/last name, email, etc., it can query this URL and negotiate the desired format using HTTP.

To integrate with existing SAML based solutions, is there any reason an IDM Proxy couldn't be written that is a bridge between this simple token protocol and the SAML-based third-party? Bill