[MidoNet-dev] Auth modification in MidoNet API
ryu at midokura.com
Mon Feb 11 13:20:43 UTC 2013
I want to make a proposal to add 'login' in MidoNet API. Currently,
MidoNet API simply accepts a token in the header, and this will not change,
but in addition to it, I want to have 'login' API endpoint that lets the
clients get temporary session IDs given username/password credentials.
This session ID then can be used as a token in the header on the
subsequent requests, until they expire. This is for the existing GitHub
The reason for proposing this feature is that, we need a way to generate
these session tokens for the clients with admin privilege(like OpenStack
integration) when its auth system does not provide them with permanent
tokens (tokens that don't expire). Take Quantum for example. It relies on
Keystone but Keystone does not provide permanent tokens. That means that
if you generate a token for Quantum to use to access the MidoNet API, it
will eventually expire, and since it is making requests on behalf of all
the users, it would shut down the service until a new token is generated
and specified in the config, and services restarted. Keystone, however,
does provide password-based authentication in which it generates a
temporary token for the client to use. All OpenStack projects are
encouraged to use this mechanism. But since MidoNet API only accepts
tokens, the python-midonet-client had to be configured to talk directly to
Keystone, and had to contain the code that handles the login and generation
of session tokens via Keystone API. Tomoe and I, when we worked on the
Grizzly integration design, did not like this because it tied the client
too closely with the authentication system (in this case, Keystone), and it
adds more work on the client side when we have to integrate with other auth
systems. One solution would be for Quantum to give us the temporary admin
token to use since Quantum itself has to do the same thing with Keystone to
generate a temporary token. We asked for this, but the community has not
accepted our request since they feel uncomfortable passing the admin token
to the plugins.
Another solution, which I chose, is to implement 'login' to MidoNet API.
Keep in mind that this does not mean MidoNet would manage the accounts.
All it's doing here is to expose a convenience API for the clients(like
Quantum integration code) that are not given permanent tokens. The way it
works is as follow:
MidoNet API now has the login API that accepts same old Basic HTTP
Authorization: Basic <base64 encoded username:password>
MidoNet API would login to its configured auth service (keystone is the
only thing it supports for this feature) and returns a session ID in the
Set-Cookie: sessionId=<SessionId>; Expires=<Expiration Time in GMT>
MidoNet API returns a challenge to the user to send username/password if
the token did not work:
WWW-Authenticate: Basic MidoNet
// That just says the client should try Basic authentication using
// MidoNet is the realm where the username/password credentials are
managed. This is
Sending username/password in the HTTP header most likely makes many people
uncomfortable, and I'm one of them. Here, however, I'm assuming the
1. In most deployments, MidoNet API will accessed only by the integration
code or GUI. So they should be running in a secure, controlled
environment. It is up to these applications to make sure that they don't
send clear text username/password through insecure channels in the
Internet. They need to secure their 'login' pages.
2. If MidoNet API were to be exposed to users directly for some reason,
then it is also the responsibility of the administrator to not expose it
insecurely. This should be documented in the deployment manual.
3. This is just a first step to adding this features, so we should revisit
this at a later time to improve. As of now, doing it the 'OpenStack-way'
makes the integration work easier.
The addition of login feature has some immediate benefits:
1. Simplifies the client code. It just now needs username/password to
connect to MidoNet API.
2. It allows the API to have a completely separate auth system from cloud
orchestration layer since the client is no longer tied to any specific auth
3. GUI could potentially use this for its login, but unfortunately, this
change does not completely remove its dependency to Keystone(or any other
auth) for the GUI because it still needs to do user account operations like
'get all users in the system'. I think such operation can also be removed
in the future, removing all dependencies to external auth systems, but that
is a different discussion.
Since Grizzly release is coming up in two days (gulp!), I have implemented
this over the weekend and just sent for review (
https://reviews.midonet.org:8443/#/c/282/). This does not change the
current functionality, but adds one new feature.
I will also modify the Python client code as well. Feedback appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev