Silvano, Seems to me you are doing it for browser based dashboard access only ?
How about if I want to use the API straight up, how do you integrate an Oauth workflow there ? On Jul 15, 2014, at 1:35 AM, Santhosh Edukulla <santhosh.eduku...@citrix.com> wrote: > Hi Silvano, > > Few Notes: > > 1. We had implementation details mentioned i believe, but we didn't mentioned > the design details and workflows. > 2. We didn't mentioned whether it is 2 legged flow or 3 legged flow. > 3. Not clear with this statement, "Once user is authorized by oauth2 server, > javascript code reads parameters in url", > 4. Whats the difference between "oauth2.credentials.url" and > "oauth2.baseurl", the later is redirect uri? If yes, Where will have redirect > uri hosted? > 5. referring to the statement " When oauth2.baseurl, oauth2.client.id and > oauth2.client.secret are not set (default), oauthRequestUrl returns empty > response and OAuth2 > authentication is turned off.", can we use a flag to denote whether to use > oauth flow or not? If set to false, dont use it otherwise continue with > default. > 6. What about refresh token,i believe access token has limited life time? Any > call back mechanism to update with latest token if it gets expired? > 7. Details like clientid,clientsecret needs to be encrypted when stored and > retrieved from global config? > 8. How do we map the user logged in to roles and hierarchy inside CS? based > on email mapping? > 9. What is the significance of these two parameters mentioned? > oauth2.credentials.parameter.email (defaults to "email") > * oauth2.domainid > 10. clientid and clientsecret key are based upon per tenant basis, so what if > we want to oauth mechanism from multiple tenants at any stage? > 11. Default values for clientid and clientsecret are loaded at which stage? > during initial installation and for which tenant? > 12. How do we verify the validity of clientid and clientsecret values? If > they are revoked? possibility of revoke is there? > 13. If we understand, it is only to authenticate a user through oauth flow, > we dont need authorization part inside of cs? I mean, what do we mean by > authorization from tenant once access key is granted? > 14. If access key is not stored, how do we get refresh token? > 15. What is the default sequence of authentication in case if oauth fails? > and order in which a given authentication mechanism will be chosen? > 16. Can we also show a ui, where user can enable\disable oauth setting for a > given account? here, possibility of mismatch with emailid based upon current > implementation and oauth retrieved emailid post authentication is there? how > do we handle it? > 17. Last, what is the significance of this feature, apart from authentication > support from third party clients? > > > Thanks! > Santhosh > ________________________________________ > From: Silvano Nogueira Buback [silv...@corp.globo.com] > Sent: Monday, July 14, 2014 4:59 PM > To: dev@cloudstack.apache.org > Subject: [PROPOSAL] OAuth2 Single SignOn Integration > > Hi gyus, > > I need to implement OAuth2 integration to provide single sign-on with > others tools in my company. I can share this implementation with the > community if you are interested. I suggest these changes in code: > > 1. Create a new javascript called oauth2.js. This javascript is responsible > for calling the new command called oauthRequestUrl that reads the global > option "oauth2.baseurl" and returns this url plus "/authorize" with oauth2 > parameters. After receiving the answer, javascript redirects user to oauth2 > server. > 2. Once user is authorized by oauth2 server, javascript code reads > parameters in url and call oauthAuthorizeToken command. This command asks > the oauth2 server by the access token, and if everything is ok, calls > "oauth2.credentials.url" about user email and finds this user in the > database, like ldap implementation does and returns authentication data. > 3. Javascript fills g_loginResponse with answer from command and user is > logged in. > > What do you think about this approach? > > > ---- More details ---- > > Alternative flows: > > * When the url has parameter direct=true, the login dialog is shown. > * When oauth2.baseurl, oauth2.client.id and oauth2.client.secret are not > set (default), oauthRequestUrl returns empty response and OAuth2 > authentication is turned off. > * If authorization token is invalid, user is redirected again to oauth2 > server. > > > Commands: > * oauthRequestUrl > * oauthAuthorizeToken > > > Global Options: > * oauth2.baseurl > * oauth2.client.id > * oauth2.client.secret > * oauth2.credentials.url: defaults to "/oauth2/v2/userinfo" > * oauth2.credentials.parameter.email (defaults to "email") > * oauth2.domainid > > > Restrictions: > * Domain Id will be a global option > * Users are always redirected to oauth2 server. Access tokens are not > stored. > * Before using Cloudstack, the administrator must insert user in an account.
