I suspect that to be true. Just adding a second authentication backend to the django-openstack-auth package would be fine. At least some of the logic should be reusable and creating a whole additional package seems like an unnecessary separation.
- Gabriel From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, June 04, 2014 12:43 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?) On 06/04/2014 03:10 PM, Gabriel Hurley wrote: I've implemented Kerberos (via Apache) + Django once before, and yes, taking this as pseudo-code you're on the right track. Obviously the devil is in the details and you'll work out the particulars as you go. The most important bit (obviously) is just making absolutely sure your REMOTE_USER header/environment variable is trusted, but that's outside the Django layer. Assuming that you can work out "with the other parameters from the original call going into auth, session, or client as appropriate" as you said then you should be fine. Thanks. One part I'm not really sure about was if it is OK to skip adding a token to the session before calling on the keystone code. It seems like the django_openstack_auth code creates a user object and adds that to the session. I don't want any of the login forms from that package. I'm guessing that I would really need to write django-openstack-kerberos-backend to merge the logic from RemoteUserBackend with django_openstack_auth; I think I want the logic of django_openstack_auth.backend.KeystoneBackend.authenticate All the best, - Gabriel From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, June 04, 2014 11:53 AM To: OpenStack Development Mailing List Subject: [openstack-dev] Kerberization of Horizon (kerbhorizon?) OK, so I'm cranking on All of the Kerberso stuff: plus S4U2Proxy work etc....except that I have never worked with DJango directly before. I want to get a sanity check on my approach: Instead of "authenticating" to Keystone, Horizon will use mod_auth_krb5 and REMOTE_USER to authenticate the user. Then, in order to get a Keystone token, the code in openstack_dashboard/api/keystone.py:keystoneclient needs to fetch a token for the user. This will be done using a Kerberized Keystone and S4U2Proxy setup. There are alternatives using TGT delegation that I really want to have nothing to do with. The keystoneclient call currently does: conn = api_version['client'].Client(token=user.token.id, endpoint=endpoint, original_ip=remote_addr, insecure=insecure, cacert=cacert, auth_url=endpoint, debug=settings.DEBUG) when I am done it would do: from keystoneclient.contrib.auth.v3 import kerberos ... if REMOTE_USER: auth = kerberos.Kerberos(OS_AUTH_URL) else: auth = v3.auth.Token(token=user.token.id) sess=session.Session(kerb_auth,verify=OS_CACERT) conn=client.Client(session=sess,region_name='RegionOne') (with the other parameters from the original call going into auth, session. or client as appropriate) Am I on track? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
