I replied to almost exactly this email off-list and so thought i would copy my reply to -dev.
----- Original Message ----- > From: "Jamie Lennox" <jamielen...@redhat.com> > To: "Sanket Lawangare" <sanket.lawang...@gmail.com> > Sent: Wednesday, February 25, 2015 6:39:14 AM > Subject: Re: Kerberos in OpenStack > > > > ----- Original Message ----- > > From: "Sanket Lawangare" <sanket.lawang...@gmail.com> > > To: jamielen...@redhat.com > > Sent: Wednesday, February 25, 2015 5:43:38 AM > > Subject: Kerberos in OpenStack > > > > Hello Mr. Jamie Lennox, > > > > My name is Sanket Lawangare. I am a graduate Student studying at The > > University of Texas, at San Antonio. For my Master’s Thesis I am > working on > > the Identity component of OpenStack. My research is to investigate > external > > authentication with Identity(keystone) using Kerberos. I am working > with > > ICS- Institute for Cyber Security at UTSA under Mr. Farhan Patwa. > > Hi Sanket, we are working quite hard on kerberos at the moment so it's > nice to have you on board . > Make sure you hang around in #openstack-keystone on Freenode, if i'm not > around (I'm based in Sydney so Timezones clash) Adam Young (ayoung) is > up to date on all this. > > > Based on reading your Blogs and my understanding of Kerberos I have > come up > > with a figure explaining possible interaction of KDC with the > OpenStack > > client, Keystone and the OpenStack services(Nova, Cinder, Swift...). I > am > > trying to understand the working of Kerberos in OpenStack. > > > > Please click this link for viewing the figure: > > > https://docs.google.com/drawings/d/1re0lNbiMDTbnkrqGMjLq6oNoBtR_GA0x7NWacf0Ulbs/edit?usp=sharing > > > > P.S. - [The steps in this figure are self explanatory the basic > > understanding of Kerberos is expected] > > > > Based on the figure i had couple of questions: > > > > > > 1. > > > > Is Nova or other services registered with the KDC? > > No not at this time. OpenStack does all it's AuthN/AuthZ for > non-keystone services via a token at this time we purely capture the > POST /v3/auth/tokens route which issues a token with kerberos and use > the REMOTE_USER as proof of AuthN rather than needing a user/pass. After > this point OpenStack operates using a token as per normal. > > > > > 1. > > > > What does keystone do with Kerberos ticket/credentials? Does > Keystone > > authenticates the users and gives them direct access to other > services > > such > > as Nova, Swift etc.. > > Related to the first question, the OpenStack user information and their > roles is encoded into the token data which is then validated by > auth_token middleware on each of the services. After the initial AuthN > kerberos request we do not currently do any additional kerberos auth. > > > > > 1. > > > > After receiving the Ticket from the KDC does keystone embed some > > kerberos credential information in the token? > > Keystone will set 'method' in the token field to reflect the method that > was used to authenticate the token - however i can't remember if it sets > the method to 'kerberos' or 'external' for kerberos auth. > > > > > 1. > > > > What information does the service (e.g.Nova) see in the Ticket and > the > > token (Does the token have some kerberos info or some customized > info > > inside it?). > > No this information is completely hidden from the other services. > > > > > If you could share your insights and guide me on the interaction > between > > these components. I would be really appreciate it. Thank you for your > time. > > So those answers are pretty short in that kerberos is really only used > for that initial AuthN contact, after which keystone issues a token and > everything else works without kerberos. there is an advantage to this in > that you don't have to do the 401 Negotiate dance on every request but > it does lack the security of kerberos (tokens are bearer tokens and can > be intercepted and used). > > I think what you are looking for is the 'token binding' feature. This is > actually one of the first things I worked on in keystone, and we were > simply not ready for it at the time. > > There is the functionality in the tokens that make it so that a token > can only be used in conjunction with another form of authentication and > the expectation we had was that kerberos would be the main candidate, > followed by SSL client certs. It means that if you used a valid token > without also presenting the appropriate kerberos ticket authentication > would fail. > > The reason that this never took off is due to the way service to service > communication happens. When you ask nova to boot you a virtual machine > it makes a number of calls to the other services, glance to get the > image, cinder for a block store, neutron for a network connection etc. > To do this it reuses the user token, so nova will forward the token you > give it to each of those services - and so if you bind it to the > kerberos ticket then the same feature that gives security essentially > stops that sharing and OpenStack stops working. > > Now, there is an effort underway that when doing service to service > communication you should also a service token. The way we currently > operate is that each service requires a user which has permission to at > least validate any tokens it is given. So instead of just passing > 'X-Auth-Token' as we do now when a service forwards that token on to > another service it would also forward a current 'X-Service-Token' for > the service user. > > What I hope this means is that we can start validating binds on tokens > only on 'X-Service-Token' if present - because if this is nova talking > to neutron the service token could be correctly bound to the nova > service user. If not present we validate bind on 'X-Auth-Token' as > normal. I think this will make token binding viable again. I'm pushing > this from a number of fronts however I would be surprised if I could get > all the services to fully adopt the approach in the L time frame (next 8 > months). > > > I'm pretty sure I just overwhelmed you with information and it may not > make sense immediately but I hope it does as you get into it more and > give you some areas to research. > > Feel free to send me any follow ups or future questions, I'm generally > available in #openstack-keystone as well - though as i mentioned > timezones don't always work out. > > > Jamie > > > > > Regards, > > > > Sanket Lawangare > > > > (Cell phone: 832-449-0550) > > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev