Ask Your Question

Question re external authentication and keystone

asked 2012-02-24 04:09:12 -0500

sgopalas gravatar image

We're trying to set up Openstack Swift and are thinking about how to use our Kerberos infrastructure for authentication with Keystone. For example, if we authenticate a user using Kerberos, how do we then send the appropriate information to Keystone so it can generate a token for this user. Do we have to include the username and password in plaintext in the request? I would rather not have the userid and password stored within Keystone and just have the token there for future operations. Is this possible?

The developer API that I reviewed had a POST interface but that required tenant id/userid/password to be sent to Keystone which then generated the token. Can I generate a token myself and then send that to Keystone so it can store it for future use? I'm trying to fit Keystone/Openstack into our existing authentication system.

Hopefully, I explained my question clearly, but if not, please feel free to ask for more info/clarification

edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted

answered 2012-03-06 17:24:33 -0500

heckj gravatar image

Morning Sridhar,

Just prior to the Essex-4 milestone, we re-baselined the code for Keystone rather dramatically. I'm expecting that in the Folsom timeframe, we're going to review the REST API for significant updates as well. WIth the essex release, the most effective means of supporting Kerberos to Swift Auth is to create a backend that does the relevant translation from Keystone's internal API's to Kerberos. The REST API was not at all intended to be used by both sides, and has some significant flaws when you try to use it in that fashion.

You can get a high level overview of how Keystone is put together at ( , and the piece I'm specifically suggesting you make a backend for is the "Identity" keystone-internal-service. For the code side, I'd recommend looking in keystone/identity/ - the specifically subclassing the Driver class in there. (See keystone/identity/backends/*.py for examples).

So - the gist is "code in python" is the most appropriate way of extended Keystone to work with Kerberos.

For the second question ("Can I generate a token and send it into Keystone to store it?") - Keystone doesn't support that sort of functionality at this time, so it's not a viable mechanism today. We're going to be talking more about Federation of keystone instances and enabling it to work with additional backends at the Folsom design summit - we'd love to have you join us, or you can keep and eye on the wiki and mailing list and raise up some design thoughts there.

edit flag offensive delete link more

answered 2012-03-06 20:39:30 -0500

sgopalas gravatar image

Joseph, Thanks for your response. One other possibility we were thinking of was to use CAS (Central Authentication Service which as the front end to Keystone and Swift. So, the flow would be to have users login using their userid and password (that they normally use on campus at our University) and then CAS would authenticate them (we already have CAS authenticating users to Kerberos here). Once the authentication is done, we were hoping we could send the appropriate information to Keystone indicating that this is an authenticated user and have Keystone respond back with the information required to get Swift access. So, in this case the user is authenticated before Keystone gets the relevant information.

Is this possible? I see in some of the middleware architecture docs ( ( ) that we can send in a header (Identity_Status = Confirmed) with the userid (Proxy_User = userid). I'm just not clear on how all this works and the doc doesn't fully flesh out the details. Hope you can clarify this and maybe give me an example of how this may work.

Thanks Sridhar

edit flag offensive delete link more

answered 2012-03-16 03:02:40 -0500

heckj gravatar image

Evening Sridhar,

Sorry for the relative slow response. The documentation on the middleware architecture has just been updated (by me, last night) as it was getting quite out of date, and recent work in across keystone to update the middleware as it needed was underway earlier. It's possible to hand in a token that the middleware will respect (documented on that page: ( - the "X-Identity-Status" header), OpenStack projects using that middleware also call back to keystone to get additional information about that token (user, tenant, and role name). Swift, in particular, is expecting some specific data handed to them by that middleware piece (that come in the forms of HTTP headers with relevant data) that I'm not sure CAS would be able to immediately provide. You can potentially shim that in yourself, and remove the auth_token middleware, but I recommend you have someone who knows swift AUTH intimately to help you debug that kind of setup.

A better solution would be to make an identity backend for keystone itself, using keystone as the API facade for OpenStack to your existing solution (CAS). That's exactly what Keystone is meant to do in most cases (be that facade).

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2012-02-24 04:09:12 -0500

Seen: 131 times

Last updated: Mar 16 '12