MashMyData explored solutions for delegation in a secured workflow involving a portal, an OGC Web Processing Service and OPeNDAP. The aim was where possible, to re-use existing components a large part of which was the federated access control infrastructure developed for the Earth System Grid Federation. ESGF supports single sign-on with PKI short-lived credentials but we had no use case requiring user delegation. When it came to MashMyData the traditional solution with Proxy certificates won out. So why bother revisiting OAuth?
- OAuth 2.0 simplifies the protocol flow compared with OAuth 1.0. Where OAuth 1.0 used signed artifacts in the HTTP headers, with OAuth 2.0, message confidentiality and integrity can be taken care of with SSL.
- Custom SSL verification code is required for consumers to correctly verify certificate chains involving proxy certificates. We can dispense with this as OAuth uses an independent mechanism for delegation.
There's a progression to this solution as follows:
- MyProxyCA alters the standard MyProxy to enable certificates to be dynamically issued from a CA configured with the service. User's input credentials (username/password) are authenticated against a PAM or SASL plugin. This could link to a user database or some other mechanism. MyProxyCA issues EECs.
- Front MyProxyCA with a web service interface and you gain all the benefits - tools, middleware, support and widespread use of HTTP.
- If you have a HTTP interface you can easily front it with OAuth
Once the client has obtained an authorisation grant, it generates a key pair and puts the public key in a certificate request to despatch to the online CA. The latter verifies the authorisation grant and returns an OAuth access token in the form of a new user certificate delegated to the client. The client can then use this in requests to other services where they need to act on behalf of the user. A big thank you to Jim Basney for his feedback in iterating towards this solution.
There is the question remaining of the provenance of credentials: how do I distinguish this delegated certificate to one obtain directly by the user? With proxy certificates you at least have the chain of trust going back to the original user certificate issuer and the CN component of the certificate subject name added for each delegation step. For ESGF, we added in a SAML attribute assertion into the certificates extension for issued EECs. There's a profile for this with VOMS which we hope to adopt for Contrail and the same idea has been used elsewhere. I'd like to be able to express provenance information in this same space. I would think it would likewise be as an attribute assertion but it needs some more thought. The certificate extension content could be extended with additional SAML to meet a couple of other objectives:
- add an authorisation decision statement to restrict the scope of resources that the issued certificate is allowed to access
- add level of assurance information via a SAML Authentication Context.