In thinking-out-loud mode. Grid clients use certificates: generally this enhances security as you get mutual authentication. So to present authorisation attributes, these either have to be carried with the credential, or queried otherwise via a callout (or cached locally). Access control is generally performed at the resource.
For authorisation attributes we tend to use VOMS,using attribute certificates. These are embedded inside the Globus proxy certificate, which is a temporary client certificate created (signed by) the user certificate, and "decorated" with the authorisation stuff - this makes sense: it separates authentication from authorisation. Globus proxies, however, tend not to work with "standard" HTTP clients, like browsers (which is not HTTP's fault, but a feature of the secure sockets.)
VOMS is nice because you get group membership and can choose to optionally assert rôles. The user selection is often missing in many authorisation schemes which either present all your attributes or none (or give you no choice at all.)
So how would we get grid authorisation working with "standard" HTTP clients? One way is to do what SARoNGS does: get a temporary certificate and decorate that instead. The client doesn't manage the certificate directly, but grants access to it, like GlobusOnline does, either by giving GO access to your MyProxy server, either by giving it your MyProxy username/password (!), or using OAuth.
If, instead, you want to have your own certificate in the browser (or other user agent), then authorisation could be done in one of two ways: you can have the resource call out to an external authorisation server, saying "I am resource W and I've got user X trying to do action Y on item Z" and the authorisation server must then look up the actual authorisation attributes of user X and take a decision. XACML could work here, with (in XACMLese) the resource being the PEP, the authorisation server the PDP, and the authorisation database (here, a VOMS database) being the PIP. VOMS also supports a SAML format, allegedly, but if it does, it's rarely seen in the wild.
Or, you could use OAuth directly. If do an HTTP GET on a protected URL, presenting a client certificate, the user agent would be directed to the authorisation server to which it would authenticate using the user certificate. The authorisation server would then need hooks to (a) find the relevant authorisation attributes in VOMS, and (b) take the decision based on the requested URL. The catch is that the OAuth client (the user agent) would need to present a client id to the authorisation server - a shared secret. Also the resource would need a means of validating the Access Token which is generally opaque. Hm. It's easy to see that something much like OAuth could work but it would obviously be better to use an existing protocol.
There are other things one could try, taking a more pure SAML approach, using some of the SAML and web services federation stuff.
Somebody may of course already have done this, but it would be interesting to do some experiments and maybe summarise the state of the art.
For authorisation attributes we tend to use VOMS,using attribute certificates. These are embedded inside the Globus proxy certificate, which is a temporary client certificate created (signed by) the user certificate, and "decorated" with the authorisation stuff - this makes sense: it separates authentication from authorisation. Globus proxies, however, tend not to work with "standard" HTTP clients, like browsers (which is not HTTP's fault, but a feature of the secure sockets.)
VOMS is nice because you get group membership and can choose to optionally assert rôles. The user selection is often missing in many authorisation schemes which either present all your attributes or none (or give you no choice at all.)
So how would we get grid authorisation working with "standard" HTTP clients? One way is to do what SARoNGS does: get a temporary certificate and decorate that instead. The client doesn't manage the certificate directly, but grants access to it, like GlobusOnline does, either by giving GO access to your MyProxy server, either by giving it your MyProxy username/password (!), or using OAuth.
If, instead, you want to have your own certificate in the browser (or other user agent), then authorisation could be done in one of two ways: you can have the resource call out to an external authorisation server, saying "I am resource W and I've got user X trying to do action Y on item Z" and the authorisation server must then look up the actual authorisation attributes of user X and take a decision. XACML could work here, with (in XACMLese) the resource being the PEP, the authorisation server the PDP, and the authorisation database (here, a VOMS database) being the PIP. VOMS also supports a SAML format, allegedly, but if it does, it's rarely seen in the wild.
Or, you could use OAuth directly. If do an HTTP GET on a protected URL, presenting a client certificate, the user agent would be directed to the authorisation server to which it would authenticate using the user certificate. The authorisation server would then need hooks to (a) find the relevant authorisation attributes in VOMS, and (b) take the decision based on the requested URL. The catch is that the OAuth client (the user agent) would need to present a client id to the authorisation server - a shared secret. Also the resource would need a means of validating the Access Token which is generally opaque. Hm. It's easy to see that something much like OAuth could work but it would obviously be better to use an existing protocol.
There are other things one could try, taking a more pure SAML approach, using some of the SAML and web services federation stuff.
Somebody may of course already have done this, but it would be interesting to do some experiments and maybe summarise the state of the art.
No comments:
Post a Comment