OAuth 2.0

Overview

• 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

    1. 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).

    2. 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.

    3. Resource Server – Resource Server is that place which hosts safety for all the user account information.

    4. 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.

OAuth Providers

Pre-Configured Providers

• 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

  CLIENT_ID=myClientId
  CLIENT_SECRET=myClientSecret
  PROVIDER=google|github|azure
  hal config security authn oauth2 edit \
  --client-id $CLIENT_ID \
  --client-secret $CLIENT_SECRET \
  --provider $PROVIDER
  hal config security authn oauth2 enable

Configure Own Provider

• Follow the below steps to configure Own Provider.

• Edit the gate-local.yaml and append the below configuration changes

  security:
  oauth2:
  client:
  clientId:
  clientSecret:
  userAuthorizationUri: # Used to get an authorization code
  accessTokenUri: # Used to get an access token
  scope:
  resource:
  userInfoUri: # Used to get the current user's email address/profile
  userInfoMapping: # Used to map the userInfo response to our User
  email:
  firstName:
  lastName:
  username:

UserInfoMapping

• 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

  userInfoMapping:
  email: <[e-mail]>
  firstName: <FirstName>
  lastName: <LastName>
  username: <UserName>

Setup Network Architecture and SSL Termination

• 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.

      server:
      tomcat:
      protocolHeader: X-Forwarded-Proto
      remoteIpHeader: X-Forwarded-For
      internalProxies: .*

  Note: Edit the gate-local.yml and add the above in the Halyard custom profile.

Restrict Access for User based authentication

• 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

      hal config security authn oauth2 edit \
      --user-info-requirements hd=your-org.net \
      --user-info-requirements batz=/^Sample.*Regex/ \
      --user-info-requirements foo=bar

  Note: All the values in the above example command, needs to be updated as per the organization requirement.

Next Steps

• Now that OAuth Setup is completed, proceed further to setup the authorization for the same.