Jump to: navigation, search

Difference between revisions of "Nova openid service"

m (Text replace - "__NOTOC__" to "")
 
(16 intermediate revisions by one other user not shown)
Line 1: Line 1:
__NOTOC__
+
 
* '''Launchpad Entry''': OpenID Authentication Service API in [[OpenStack]] Nova
+
* '''Launchpad Entry''': [https://blueprints.launchpad.net/nova/+spec/openid-nova OpenID Authentication Service API in OpenStack Nova]
* '''Created''': Rasib Hassan Khan
+
* '''Created''': [http://launchpad.net/~rasibk Rasib Hassan Khan]
* '''Contributors''': Rasib Hassan Khan, Jukka Ylitalo, Abu Shohel Ahmed
+
* '''Contributors''': [https://launchpad.net/~rasibk Rasib Hassan Khan], [https://launchpad.net/~jukka-ylitalo Jukka Ylitalo], [https://launchpad.net/~shohel-csdu Abu Shohel Ahmed]
  
 
== Summary ==
 
== Summary ==
Currently, the Django-Nova/Dashboard supports only basic username/password based access. There is separate user credential management both on the web service point and [[OpenStack]]. [[OpenStack]] relies on the web server for user authentication resulting in Multiple Policy Decision Points (PDP). Integration of OpenID with Openstack allows flexible SSO mechanism for administrators. The solution also removes the existing multiple identity silos in web server and [[OpenStack]].
+
Currently, the Django-Nova/Dashboard supports only basic username/password based access. There is separate user credential management both on the web service point and [[OpenStack]]. [[OpenStack]] relies on the web server for user authentication resulting in Multiple Policy Decision Points (PDP). Integration of [http://openid.net/ OpenID] with Openstack allows flexible SSO mechanism for administrators. The solution also removes the existing multiple identity silos in web server and [[OpenStack]].
 +
 
 +
{{http://wiki.openstack.org/StartingPage?action=[[AttachFile]]&do=get&target=nova-openid-overview.png||height="306px",width="608px"}}
  
 
== Release Note ==
 
== Release Note ==
This section  should include a paragraph describing the end-user impact of this  change. It is meant to be included in the release notes of the first  release in which it is implemented. (Not all of these will actually be  included in the release notes, at the release manager's discretion; but  writing them is a useful exercise.)
+
Integration of [http://openid.net/ OpenID] SSO Authentication service for [[OpenStack]]. Includes implementations of APIs in [[OpenStack]] for [http://openid.net/ OpenID] Service, and incorporates extension of Django-Nova/Dashboard to use the APIs to allow administrative login into web server.[[OpenStack]] Nova database schema also includes additional field 'openid' in 'user' table, to tag specific OpenID user to an existing [[OpenStack]] user.
 +
 
 +
== User stories ==
 +
[http://openid.net/ OpenID] URL for administrative user is used to provide flexible SSO solution, and use [[OpenStack]] services from Dashboard.
 +
 
 +
== Design ==
 +
{{http://wiki.openstack.org/StartingPage?action=[[AttachFile]]&do=get&target=nova-openid-block-diag.png||height="305px",width="403px"}}
 +
 
 +
1: User requests OpenID login
  
It is mandatory.
+
2: API OpenidAuthReq called
  
== Rationale ==
+
3: Endpoint Discovery
  
== User stories ==
+
4: Receive OP meta-info
 +
 
 +
5: Response XML (redirection info.)
 +
 
 +
6: Redirect to OpenID provider
 +
 
 +
7: User authentication at OP
 +
 
 +
8: Redirect back to Dashboard
  
== Assumptions ==
+
9: API OpenidAuthVerify called
  
== Design ==
+
10: Discover and verify
You can have subsections that better describe specific parts of the issue.
 
  
== Implementation ==
+
11: Verification response, and find user for specific OpenID user
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
 
  
=== UI Changes ===
+
12: Response XML (user info.)
Should cover changes required to the UI, or specific UI that is required to implement this
 
  
=== Code Changes ===
+
13: Login user
Code changes should include an overview of what needs to change, and in some cases even the specific details.
 
  
=== Migration ===
+
== Implementation ==
Include:
+
For the purpose of the implementation, we have introduced two new APIs. For the present prototype implementation, they have been defined in the format of the other EC2 APIs, with the same response format. The description of the APIs are as follows:
  
* data migration, if any
+
* '''OpenidAuthReq''':
* redirects from old URLs to new ones, if any
+
** Called by the GUI web server, when a user tries to perform OpenID Authentication. Additional to the required parameters, it requires the 'name' parameter, formed in the format '<OpenID_URL>&<return_to_URL>'. The 'return_to_URL' is the point where the OpenID provider will redirect back the user (some URL in the web server, eg. dashboard:8080/openid-user) after the authentication is complete at the provider's end.
* how users will be pointed to the new way of doing things, if necessary.
+
** Response XML: Form and Input parameters required for user HTTP 302 redirection to OpenID provider
 +
* '''OpenidAuthVerify''':
 +
** Called by the GUI web server, after an OpenID provider redirects a user back to the web server after authentication is complete at the provider's end. Additional to the required parameters, it requires the 'name' parameter, which includes the whole response string from the OpenID provider.
 +
** Response XML: If verification is successful, and there exists a user for the specific OpenID user, returns user information (similar to DescribeUser API).
  
== Test/Demo Plan ==
+
'''Nova-Manage''' also incorporates additional functionality for admins to create/modify an OpenID URL for an existing Nova user.
This need not be added or completed until the specification is nearing beta.
 
  
== Unresolved issues ==
+
The detailed signalling and message sequence is shown in the following figure:
This should  highlight any issues that should be addressed in further specifications,  and not problems with the specification itself; since any specification  with problems cannot be approved.
 
  
== BoF agenda and discussion ==
+
{{http://wiki.openstack.org/StartingPage?action=[[AttachFile]]&do=get&target=nova-openid-msg-flow.png}}
Use this  section to take notes during the BoF; if you keep it in the approved  spec, use it for summarising what was discussed and note any options  that were rejected.
 

Latest revision as of 23:30, 17 February 2013

Summary

Currently, the Django-Nova/Dashboard supports only basic username/password based access. There is separate user credential management both on the web service point and OpenStack. OpenStack relies on the web server for user authentication resulting in Multiple Policy Decision Points (PDP). Integration of OpenID with Openstack allows flexible SSO mechanism for administrators. The solution also removes the existing multiple identity silos in web server and OpenStack.

{{http://wiki.openstack.org/StartingPage?action=AttachFile&do=get&target=nova-openid-overview.png||height="306px",width="608px"}}

Release Note

Integration of OpenID SSO Authentication service for OpenStack. Includes implementations of APIs in OpenStack for OpenID Service, and incorporates extension of Django-Nova/Dashboard to use the APIs to allow administrative login into web server.OpenStack Nova database schema also includes additional field 'openid' in 'user' table, to tag specific OpenID user to an existing OpenStack user.

User stories

OpenID URL for administrative user is used to provide flexible SSO solution, and use OpenStack services from Dashboard.

Design

{{http://wiki.openstack.org/StartingPage?action=AttachFile&do=get&target=nova-openid-block-diag.png||height="305px",width="403px"}}

1: User requests OpenID login

2: API OpenidAuthReq called

3: Endpoint Discovery

4: Receive OP meta-info

5: Response XML (redirection info.)

6: Redirect to OpenID provider

7: User authentication at OP

8: Redirect back to Dashboard

9: API OpenidAuthVerify called

10: Discover and verify

11: Verification response, and find user for specific OpenID user

12: Response XML (user info.)

13: Login user

Implementation

For the purpose of the implementation, we have introduced two new APIs. For the present prototype implementation, they have been defined in the format of the other EC2 APIs, with the same response format. The description of the APIs are as follows:

  • OpenidAuthReq:
    • Called by the GUI web server, when a user tries to perform OpenID Authentication. Additional to the required parameters, it requires the 'name' parameter, formed in the format '<OpenID_URL>&<return_to_URL>'. The 'return_to_URL' is the point where the OpenID provider will redirect back the user (some URL in the web server, eg. dashboard:8080/openid-user) after the authentication is complete at the provider's end.
    • Response XML: Form and Input parameters required for user HTTP 302 redirection to OpenID provider
  • OpenidAuthVerify:
    • Called by the GUI web server, after an OpenID provider redirects a user back to the web server after authentication is complete at the provider's end. Additional to the required parameters, it requires the 'name' parameter, which includes the whole response string from the OpenID provider.
    • Response XML: If verification is successful, and there exists a user for the specific OpenID user, returns user information (similar to DescribeUser API).

Nova-Manage also incorporates additional functionality for admins to create/modify an OpenID URL for an existing Nova user.

The detailed signalling and message sequence is shown in the following figure:

{{http://wiki.openstack.org/StartingPage?action=AttachFile&do=get&target=nova-openid-msg-flow.png}}