Re: authentication with certificates

[David Lutterkort <lu...@redhat.com>]

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.

David

RE: authentication with certificates

["Koper, Dies" <di...@fast.au.fujitsu.com>]

Hi David,

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

My certificate is 6Kb when converted to PEM. I suppose it could be more
for other regions, depending on the number of intermediate certificates
that are included.
I couldn't find the limit for Thin.

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

I like that third option. At least once the user has uploaded the key
material (a one-time thing), they can use the API in the same way as for
other providers.

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

Well, I trust my sysadmin to host DC on his servers and keep it running.
I also trust he's not interested enough in my cloud stuff to bother
using my certificate. Colleagues however, may like to "borrow" mine when
they don't have access to something I have access to ;)

Thanks a lot, I'll proceed with option 1 for now.
Regards,
Dies