deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: authentication with certificates
Date Thu, 01 Mar 2012 22:48:12 GMT
Hi Dies,

On Sat, 2012-02-25 at 12:28 +1100, Koper, Dies wrote:
> The Fujitsu Global Cloud Platform has an XML-RPC API to communicate
> with.
> It authenticates users in two ways:
> 1. Client authentication (https with each user having their own
> certificate, obtained from the FGCP portal).
> 2. A signed string in each message (signed using the user's private
> key).

That's quite a pickle.

> The DeltaCloud architecture seems to make the assumption credentials
> consist of two strings (user name/pwd, api key/secret key, etc.).
> Do you have any suggestions for what we can do for the FGCP?

Yes, DC uses the HTTP BasicAuth header to transmit auth information.

> If we store user certificates on the DeltaCloud server, it's easy.
> But if we don't (I suppose none of the other providers store user
> credentials on the DeltaCloud server?), we have the issue that the
> DeltaCloud server needs the certificate to talk to the FGCP endpoint.
> With the current architecture, I have thought of these solutions.
> 1. Store user certificates on the DeltaCloud server. The client sends
> the user name stored in the certificate and the certificate's password
> to the DeltaCloud server, which then picks the right certificate to talk
> to the FGCP endpoint.
> 2. The user converts the certificate to text format and uses that and
> the certificate password as credentials to the DeltaCloud server, which
> converts it back to a format the Ruby HTTPS APIs accept for client
> authentication.
> The disadvantage of the first option is of course the fact that users
> need access to the DeltaCloud server, and may feel uncomfortable storing
> their certificates there if it's a shared server.

I see 'access to the server' as a bigger issue than 'trusting the
server' - they need to do that already for any driver.

> The disadvantage of the second option is the added complexity for the
> user to convert the certificate (pkcs12 -> PEM -> base64 encoding ->
> stripping newlines?), potential issues sending this big string with each
> request (performance, web server dependent HTTP header length
> restrictions) , and again users feeling uncomfortable sending their
> actual certificate somewhere (although I suppose it is equivalent to
> sending user/pwd with other providers).

We could probably reduce some of that pain with some additions to the
client(s) - like some JavaScript magic in the HTML UI and some utilities
in the Ruby client.

The size issue is troublesome - by default, Apache limits headers to 8k.
We'd need to get a good idea on how big the headers will become, and
document that people will have to bump the corresponding config settings
on their servers.

> I am currently thinking to start with option 1 and investigate the
> feasibility of option 2 if/when users ask for it.

Yes, I agree that that seems the best route. Longer term, option 2 would
be hugely preferrable. If that is not possible, we can think about
adding some sort of 'authenticate' API call, that lets the user upload
their key material. In return they'd get a username/password for
subsequent requests. It would of course require that the key material is
stored on the DC server ...

> What do you think? Do you have an idea of how most users deploy their
> DeltaCloud server, locally or on a shared machine?

Both, and it doesn't really matter: users have to trust the DC server
they talk to for all servers. Whether they trust a DC server is a matter
of whether they trust whoever is running that server, and will vary from
user to user.


View raw message