-
Notifications
You must be signed in to change notification settings - Fork 27
OAuth_ _Conductor_and_ConfigServer
Currently, in order to seed an Audrey Config Server with instance configuration data, Conductor needs to authenticate with Basic Authentication over HTTPS. The SSL Termination and authentication is handled completely by Apache. And, Apache proxies the request to Config Server over HTTP with no authentication or user information.
The goal is to switch from Basic Authentication to OAuth for authenticating requests from Conductor to Config Server. The authentication via OAuth will be handled by Config Server, while SSL termination will still be handled by Apache.
The Config Server will need to change to authenticate requests based on OAuth request headers.
The process for setting up an Audrey Config Server uses puppet to configure httpd and config server. Today, puppet is used to configure httpd SSL Termination and HTTP Basic Authentication.
These puppet scripts will have to change to no longer configure HTTP Basic Auth. Instead of setting up Basic Auth, the puppet scripts will need to generate a consumer key and shared secret for Conductor. This information will need to be input into the Conductor UI by the user.
The Audrey Config Server relies solely on the HTTP Basic Authentication provided by the proxy. This will have to change to enforce the OAuth validation from within Config Server.
The Audrey Client will need to authenticate with the Config Server by sending OAuth request headers.
The “user data” format will change slightly. Mainly this is to make the Config Server data input into Conductor a little more streamlined. Today, the user has to input the Config Server host, port, basic auth user, basic auth password, and an SSL cert. After this change, the user will input the Config Server service endpoint, the Conductor client key, and the shared secret. These three pieces of information will be output by the Config Server setup script.
The Audrey Client will need to be updated to read this new user data format.
The Audrey Client will now need to use the correct HTTP headers to create the correct OAuth authentication request.
Conductor will require some cosmetic and functional changes to support authenticating with Config Server via OAuth.
When creating a Config Server reference in Conductor, the user currently inputs:
- Config Server host
- Config Server port
- Config Server basic auth user
- Config Server basic auth password
- Config Server SSL cert
- this is a bit of a hack…the SSL cert is never actually used by Conductor; it’s simply around to indicate to Conductor that the connection is https
With the change over to OAuth, the data required by the user changes to:
- Config Server service endpoint
- Conductor client key
- Conductor-Config Server shared secret
Conductor will need to generate different “user data” when constructing the call to DeltaCloud. Today, the “user data” looks like:
config_server_host:config_server_ip:instance_uuid:generated_password
Once Config Server is authenticating requests with OAuth, the “user data” will need to change to look like:
config_server_service_endpoint:instance_uuid:shared_secret
Conductor currently uses the basic auth username and password to build the authenticated request with Config Server when POSTing the instance configuration data. Now, Conductor will need to use OAuth headers to build the authenticated request.
When Conductor generates the instance configuration XML file that is POSTed to Config Server, it needs to generate the instance uuid (serving as the instance’s client key) and a shared secret. This information needs to be in the “user data” transmitted through DeltaCloud to the instance. This information also needs to be delivered to the Config Server via the instance configuration XML file.