OAuth 2.0
Last updated
Last updated
This is an older version of the document. To view the most recent version of the document, click here.
OAuth 2.0 is an authorization framework that allows applications to obtain restricted access to user accounts on an HTTP Service.
This method works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account.
Roles play a major role in OAuth, there are four types of OAuth roles ### OAuth Roles
Details of all OAuth roles are below
Resource Owner – This is the ‘user’ who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. read or write access).
Client – This is the application that wants the access to user accounts. To gain user account access, first it must be authorized by the user, and the authorization must be validated by the API.
Resource Server – Resource Server is that place which hosts safety for all the user account information.
Authorization Server – Authorization server, ensures to verify the user identify and then assigns a token to the user to access the application as per the roles defined for that user.
For user’s convenience, OAuth has several providers that are already pre-configured.
To give the client ID and secret, one must activate at least one of the Provider from the below table, follow the provider specific documentation to obtain Client ID and Secret.
Now, activate one of the provider by following the below
Follow the below steps to configure Own Provider.
Edit the gate-local.yaml and append the below configuration changes
UserInfoMapping is the section that allows to map the names of fields from the ‘userInfouri’ request to Spinnaker-specific fields. UserInfoMapping configuration should like below
It’s mandatory to configure ‘redirect-uri’ for OAuth on Spinnaker. So that, during the OAuth authentication and authorization process, Gate will be able to call the URI and access the Spinnaker UI as per the user roles.
To setup ‘redirect-uri’ manually execute the below command
Note
Ensure to include the /login suffix at the end of the --pre-established- redirect-uri flag!
In Addition to the above, below configurations make it necessary to ‘unwind’ external proxy instances. This makes the request to Gate look like the original request to the outer-most proxy.
Note: Edit the gate-local.yml and add the above in the Halyard custom profile.
On Spinnaker user access can be further restricted, based on the user info from the OAuth ID Token.
This is set by using the following parameter ‘--user-info-requirements’.
This enables one to restrict user access to specific domains or attributes. Execute the below command to achieve the same
Note: All the values in the above example command, needs to be updated as per the organization requirement.
Now that OAuth Setup is completed, proceed further to setup the authorization for the same.