authentication with certificates

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

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

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?

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

When a user certificate is issued, the user gets three files:

1. user certificate in pkcs12 format (binary)
2. public key in ssh-rsa format (useful to upload to a server instance
so you can ssh to it with your certificate) 
3. private key in PEM format (useful to import into putty to connect to
your server instance)

So this is what we have to work with.

I am currently thinking to start with option 1 and investigate the
feasibility of option 2 if/when users ask for it.
What do you think? Do you have an idea of how most users deploy their
DeltaCloud server, locally or on a shared machine?

Thanks!
Dies

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

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