Question re external authentication and keystone

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 http://keystone.openstack.org/architecture.html, 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/core.py - 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.

Joseph,
Thanks for your response. One other possibility we were thinking of was to use CAS (Central Authentication Service whichhttp://www.jasig.org/cas) 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 (http://keystone.openstack.org/middleware_architecture.html ) 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

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: http://keystone.openstack.org/middleware_architecture.html - 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).