Difference between revisions of "Nova openid service"

Revision as of 13:06, 19 April 2011

Launchpad Entry: OpenID Authentication Service API in OpenStack Nova
Created: Rasib Hassan Khan
Contributors: Rasib Hassan Khan, Jukka Ylitalo, Abu Shohel Ahmed

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 OpenIDwith Openstack allows flexible SSO mechanism for administrators. The solution also removes the existing multiple identity silos in web server and OpenStack.

Release Note

Integration of OpenIDSSO Authentication service for OpenStack. Includes implementations of APIs in OpenStack for OpenIDService, and incorporates extension of Django-Nova/Dashboard to use the APIs to allow administrative login into web server.

User stories

OpenIDURL 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}}

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

12: Response XML (user info.)

13: Login user

@@ 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
 * '''Contributors''': Rasib Hassan Khan, Jukka Ylitalo, Abu Shohel Ahmed
 == 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]].
 == 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.
+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.
 == User stories ==
-OpenID URL for administrative user is used to provide flexible SSO solution, and use [[OpenStack]] services from Dashboard.
+[http://openid.net/ OpenID]URL for administrative user is used to provide flexible SSO solution, and use [[OpenStack]] services from Dashboard.
 == Design ==
@@ Line 34: / Line 34: @@
 : API [[OpenidAuthVerify]] called
 : Discover and verify
 : Verification response
@@ Line 43: / Line 43: @@
 == Implementation ==
-This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
-=== UI Changes ===
-Should cover changes required to the UI, or specific UI that is required to implement this
-=== Code Changes ===
-Code changes should include an overview of what needs to change, and in some cases even the specific details.
-=== Migration ===
-Include:
-* data migration, if any
-* redirects from old URLs to new ones, if any
-* how users will be pointed to the new way of doing things, if necessary.
-== Test/Demo Plan ==
-This need not be added or completed until the specification is nearing beta.
-== Unresolved issues ==
-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 ==
-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.