OpenStack and EC2 APIs use different usernames and passwords

I disagree with the unsaid premise of the bug which seems to say that the OpenStack and EC2 APIs should be completely interchangeable. IMO each API must be given the freedom to authenticate users how they see fit, set up their own authorization rules using OpenStack libraries, and otherwise be able to operate with complete autonomy. I see this flexibility as a key differentiator allowing OpenStack to host any number of different APIs while still providing a wide variety of features.

Well, as long as you understand that by disagreeing you're personally signing up for 10 years of front-line support, on the helpdesk whose sole responsibility is the question "why can't I log in to my cloud?"

Here's the schedule so far:

2011 - 2020
Monday 1st shift: BL
Monday 2nd shift: BL
Monday 3rd shift: BL
Tuesday 1st shift: BL
Tuesday 2nd shift: BL
...

:-)

Justin didn't say that the OpenStack and EC2 APIs should be completely interchangeable -- he said that they should use the same username and password.

I agree with Justin. We're going to have a world where some tools are built using the EC2 API, and some using the OpenStack API, and both will be used in parallel in the one cloud, and which is which is going to be completely invisible to the end user. We'd be crazy to have two independent passwords.

"So, here are your two usernames and two passwords. When you log into self-service.acme.com, then use this password, and when you log into billing-records.acme.com, use this other password. And we're upgrading self-service.acme.com at the end of the year and they've switched to the OpenStack API, so you'll switch passwords at that point. Oh, and it's going to be an incremental upgrade, so for a couple of weeks the GSLB might direct you either to a version 1.0 node or a version 2.0 node. You'll figure that out. Have fun!"

This isn't strictly true. The ec2 credentails are an access and secret key, which is a bit different from a username and password. I don't think we can think of them as completely interchangable. In many auth systems, you use a username and password to generate a token which has a key and a secret.

Vish

On Mar 10, 2011, at 2:19 PM, justinsb wrote:

> Public bug reported:
>
> The OpenStack and EC2 APIs don't use the same username & password.
>
> This is obviously untenable: it leads to a world where an end user would
> need to know which API their front-end application was using behind the
> scenes.
>
> ** Affects: nova
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Nova Bug
> Team, which is subscribed to OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/732907
>
> Title:
> OpenStack and EC2 APIs use different usernames and passwords
>
> Status in OpenStack Compute (Nova):
> New
>
> Bug description:
> The OpenStack and EC2 APIs don't use the same username & password.
>
> This is obviously untenable: it leads to a world where an end user
> would need to know which API their front-end application was using
> behind the scenes.

You signing up to join Brian on the schedule there Vish? :-)

I think these nuances of access key / secret key vs username / password are a bit lost on me. For both, you have an identifier and a secret. At the moment of authentication, I need to demonstrate that I know the password. I can either do this by telling you my secret over a secure link, or we can both do a crypto calculation that proves I have the same secret. Whether I exchange this for a token or not is just an implementation detail, mostly to support federation. I don't see why we can't use the same credentials irrespective of these details, just like I don't have to switch passwords when I'm using HTTP basic auth vs HTTP digest. What am I missing?

I think Ewan nailed the explanation - it's a terrible user experience. In the absence of a solid technical reason, I just don't understand why we would want to do that.

Yes, I know that the EC2 API calls them "access key ID" and "secret access key", but this doesn't make it a token exchange scheme just because they are named differently. It's a fixed public identifier plus a fixed secret thing, aka a username and password.

I think the point is, Amazon have a username and password, but it's in an authentication system that's completely distinct from the EC2 system. With your Amazon password, you can log in to their auth system and obtain your "access key ID" and "secret access key", but those are just a username/password pair with fancy names.

Presumably, Amazon felt the need to separate your API access from everything else so that you couldn't buy books with someone's EC2 credentials. This doesn't apply to us for two reasons: 1) we don't sell books and 2) we don't have other systems that you can log into.

We can simplify the distinction between "password" and "secret access key" because our password is only useful for one thing.

On Fri, Mar 11, 2011 at 09:35:22AM -0000, justinsb wrote:
> I think Ewan nailed the explanation - it's a terrible user experience.
> In the absence of a solid technical reason, I just don't understand why
> we would want to do that.

The main reason I'm aware is so you can generate multiple access
keys/secrets for the same account (tied to a single user/pass). This
allows you to hand out access keys to various places (management
websites, tools, etc.) and revoke those access keys if needed should
something happen to just a single tool. This doesn't require changing
your password everywhere. The same thing can be accomplished with
proper user management within a single account, it's just another
way of looking at the same problem.

If we go with token based auth, this may be a bit more difficult
since OS can lookup the token, but EC2 would not use the token (it
needs key and secret for signature). So some clients would be need
to use ec2 style and others would simply have a token. All things to
discuss at the summit probably as we figure out the auth plan.

-Eric

Ewan suggests that this has been addressed well enough that this ticket is no longer useful, and I agree.