Modifying horizon with federated access

Registered by Deepak Selvaraj on 2013-11-24

This feature enables the user to login into Openstack by authenticating through a third party identity provider. This project focuses in enabling a federated authentication feature through graphical user interface client i.e. through the Openstack dashboard.

The assumed changes in Horizon would be as follows:


Install and configure federated keystone that holds the federation script to add an 3rd party idp into the service catalog of Keystone, and supports the federated Idp's.This would be achieved from (

Abstract and modify the federation module from (, into openstack-auth which acts as the authentication holder for horizon


The forms (openstack_auth/ in Horizon will be modified to have a dropdown with available list of Identity providers.

Horizon sends a REST request to keystone through the abstracted federation api, to populate the dropdown with the list of Idp's stored in the service catalog within (service type: identity)

The user selects the desired identity provider, which has its endpoint stored in the service catalog of Keystone.

Horizon makes a GET request of the user selection to Keystone.

Keystone POST the endpoint of the particular Idp to horizon.

Horizon connects to the endpoint and displays the login page of the Idp to the user.

The user authenticates with the Idp by providing his/her credentials maintained with the particular Idp.

Idp authenticates the user and would POST an token to Horizon.

Horizon POST this token to keystone.

Keystone now validates the token received from the client (Horizon) and exchanges it for the normal unscoped and scoped Keystone token that would allow the user to access the respective Openstack service.

Blueprint information

David Lyle
Needs approval
Series goal:
Milestone target:
milestone icon ongoing
Started by
Deepak Selvaraj on 2013-11-27
Completed by
David Lyle on 2015-07-15

Related branches



[e0ne 12.02.2013] It's a bad idea to use swiftclient in django_openstack_auth. We need to implement it in a django_openstack_auth or create separate [federated_]openstack_auth package
I think, We can use the following module Import this module in django_openstack_auth and modify the method authentication.

currently, the dashboard has a dependency on django_openstack_auth. You might want to fix that, too. Authentication plugins are meant to be pluggable/replaceable.

[david-lyle 11.28.2013] keystone will still be the identity endpoint. So using openstack_auth will still be useful. There will need to be changes in both horizon and openstack_auth, but they will likely not be extensive. Replacing openstack_auth should not be necessary. Theoretically, the backends are swappable in openstack_auth anyway. We just don't have support for a different identity provider at this point.

[david-lyle Dec 2 2013] I mis-understood the original intent. Why aren't you planning to use keystone for this? Keystone is working on supporting federated IDPs in Icehouse.

[deep42 dec 2 2013]And yes we will be using the federated keystone, to which Horizon will be communicating through the api in openstack-auth.

No we are not using swift client, instead there is a federation api used by swift client in the demo
(, same as ( which can be abstracted and modified in a way it can be used in Horizon client. Is there any better way to achieve this ?

[lin-hua-cheng Dec 3 2013] In the workflow, before the token from IDP is submitted to Keystone should there be a step to push the SAML assertions into keystone first. So that the federated user is created and mapping is performed?

Another thing to consider is we need to turn off the update of user/role/group for a federated user - should go on a separate blueprint.

[deepak selvaraj Dec 11 2013] The federated keystone should receive the token provided from Idp (via Horizon) and creates a temporary user through the CVS (Credential Validation System) with user id, validation time and the set of identity attributes based on the meta data of that particular Idp. Federated Keystone then performs the attribute mapping and gives an unscoped token and list of available projects to the user through the Horizon default dashboard

[lin-hua-cheng Dec 17 2013] Is the authentication method for Idp would be the same? - like requiring user for additional information from a device generating tokens. I am interested to know the process of Idp authentication and how horizon would be able to create the temporary user (or if horizon should be responsible for doing this).

[deepak Selvaraj Dec 14 2013] I have configured the federated keystone into my devstack environment and made the required changes with respect to adding the list of Idp's into the service catalog. The federated api is modified and implemented into the Horizon folder. I created a dropdown form within Horizon and the form is currently populating the Idp's from the service catalog through a get request to Federated Keystone. Upon selecting the Idp the user is redirected to the endpoint and allowed to authenticate with the IDp. But after authentication, instead of redirecting to the mentioned callback_url, the user gets redirected to a different url (localhost:8080). It will be very helpful if anyone can advise on this part to proceed further.

[lin-hua-cheng Dec 17 2013] Maybe you are missing the call to django_login(), see related code in openstack_auth:

Do you have a WIP patch in github?

Yes the horizon folder on a whole is shared in
and the openstack-auth module is shared separately in

In order to redirect the user back to dashboard, horizon is saved as a trusted service in the persistence server that provides the federated Idp's.

1. The request signing key in the keystone.conf is changed with a new privkey.pem which has its public pair saved in the server
2. SPName is changed to fedhorizon and the same is saved as the detail in the server side
3. is added with a new function called federated_horizon that receives the redirect after authentication of the user, the redirect url will be http://localhost/auth/federated_horizon

A new folder has been added in github, that includes the module changes within the existing horizon. It holds the additional modules included and also the code changes made in the existing Horizon at There is a read me file that gives a short description of the files attached.

Horizon is modified with Federated authentication and the code is available for review in github

Test performed on devstack environment, there is a bug in opening the web browser, which I am working on. Review from couple of Federated Keystone users felt that this issue is not happening when horizon is set up independently and happens only within Devstack. I am awaiting the code to be reviewed and expect the comments on required changes please

The work items below are all marked as done - has any of that merged to horizon? -Dolph

[lin-hua-cheng Jul 2 2014] Nothing got merged, the code was far from being ready.

lin-hua-cheng: thanks for the update! -Dolph

[deepakselvaraj Jul 14 2014] revised code to be updated in github by 15/07/2014

[deepakselvaraj Jul 14 2014] Updated the work items with the tasks currently in progress, testing needs to be performed and it is expected to be automated across multiple browsers using selenium webdriver


Work Items

Work items:
Requirements Gathering : DONE
Design : DONE
Install and Configure the federated keystone: DONE
Modify the script holding the Idp's in FK: DONE
Modify the forms in Horizon to have a dropdown: DONE
Modify the federation API: DONE
Dropdown Populates the IDP's from Keystone service catalog: DONE
Authenticate with Idp and pass the token to Keystone: DONE
Redirect the user from Keystone to Horizon : DONE
Generate Test scripts: INPROGRESS
Browser Level automation Testing using selenium: INPROGRESS