[MidoNet-dev] Auth modification in MidoNet API

Adam Johnson adam at midokura.com
Mon Feb 11 18:43:13 UTC 2013


Great write-up, and I think this is a big step in the right direction.  I
also don't want to have to maintain code for communicating with
Keystone/CloudStack, it's better if we can consolidate all of that under
one abstracted login call, as you said.

I'm also interested to hear your thoughts on how to remove the call to get
all users in the GUI. :)


On Mon, Feb 11, 2013 at 5:20 AM, Ishimoto, Ryu <ryu at midokura.com> wrote:

> Hey All,
> 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
> issue: https://github.com/midokura/midonet/issues/78
> 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
> authentication header:
>    URI: https://<base_url>/login
>    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
> Cookie header:
>      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
> username/password.
>      // MidoNet is the realm where the username/password credentials are
> managed.  This is
>      // arbitrary.
> 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
> following:
> 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
> system.
> 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!
> Ryu
> _______________________________________________
> MidoNet-dev mailing list
> MidoNet-dev at lists.midonet.org
> http://lists.midonet.org/listinfo/midonet-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130211/c6a96bcc/attachment-0001.html>

More information about the MidoNet-dev mailing list