Multicloud apps with Istio

Protecting front-end apps

If you're using a browser-based application, you can use the Open ID Connect (OIDC) / OAuth 2.0 authorization_grant flow to authenticate your users. When an unauthenticated user is detected, they are automatically redirected to the authentication page. When the authentication completes, the browser is redirected to an implicit /oidc/callback endpoint where the Adapter intercepts the request. At this point, the Adapter obtains tokens from the identity provider and then redirects the user back to their originally requested URL.

To view the user session information, including the session tokens, you can look in the Authorization header.

Authorization: Bearer <accessToken> <IDToken>

You can also log out authenticated users. When an authenticated user accesses any protected endpoint with oidc/logout appended as shown in the following example, they are logged out.

https://myhost/path/oidc/logout

If needed, a refresh token can be used to automatically acquire new access and identity tokens without your user's needing to reauthenticate. If the configured identity provider returns a refresh token, it's persisted in the session and used to retrieve new tokens when the identity token expires.

Protecting backend apps

The Adapter can be used in collaboration with the OAuth 2.0 JWT Bearer flow to protect service APIs by validating JWT Bearer tokens. The Bearer authorization flow expects a request to contain an Authorization header with a valid access token and an optional identity token. The expected header structure is Authorization=Bearer {access_token} [{id_token}]. Unauthenticated clients are returned an HTTP 401 response status with a list of the scopes that are needed to obtain authorization. If the tokens are invalid or expired, the API strategy returns an HTTP 401 response with an optional error component that says Www-Authenticate=Bearer scope="{scope}" error="{error}".

For more information about tokens and how they're used, see understanding tokens.

Defining a configuration

Depending on whether you're protecting front end or backend applications, create a policy configuration with one of the following options.

• For front-end applications: Browser-based applications that require user authentication can be configured to use the OIDC / OAuth 2.0 authentication flow. To define an OidcConfig CRD containing the client used to facilitate the authentication flow with the Identity provider, use the following example as a guide.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: OidcConfig
  metadata:
     name:      oidc-provider-config
     namespace: sample-namespace
  spec:
     discoveryUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/.well-known/openid-configuration
     clientId:     <clientID>
     clientSecret: <randomlyGeneratedClientSecret>
     clientSecretRef:
           name: <nameOfKubeSecret>
           key: <keyInKubeSecret>
  

  Table 1. YAML configuration file components explained

  Field	Type	Required	Description
  discoveryUrl	string	Yes	A well-known endpoint that provides a JSON document of OIDC/OAuth 2.0 configuration information.
  clientId	string	Yes	An identifier for the client that is used for authentication.
  clientSecret	string	*No	A plain text secret that is used to authenticate the client. If not provided, a clientSecretRef must exist.
  clientSecretRef	object	No	A reference secret that is used to authenticate the client. The reference can be used in place of the clientSecret.
  clientSecretRef.name	string	Yes	The name of the Kubernetes Secret that contains the clientSecret.
  clientSecretRef.key	string	Yes	The field within the Kubernetes Secret that holds the clientSecret.

• For backend applications: The OAuth 2.0 Bearer token spec defines a pattern for protecting APIs by using JSON Web Tokens (JWTs). By using the following configuration as an example, define a JwtConfig CRD that contains the public key resource, which is used to validate token signatures.

  apiVersion: "security.cloud.ibm.com/v1"
  kind: JwtConfig
  metadata:
     name:      jwt-config
     namespace: sample-app
  spec:
     jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys
  

Registering application endpoints

Register application endpoints within a Policy CRD to validate incoming requests and enforce authentication rules. Each Policy applies exclusively to the Kubernetes namespace in which the object lives and can specify the services, paths, and methods that you want to protect.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
  name:      samplepolicy
  namespace: sample-app
spec:
  targets:
    -
      serviceName: <svcSampleApp>
      paths:
        - exact: /web/home
          method: ALL
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              rules:
                - claim: scope
                  match: ALL
                  source: access_token
                  values:
                    - appid_default
                    - openid
                - claim: amr
                  match: ANY
                  source: id_token
                  values:
                    - cloud_directory
                    - google

        - exact: /web/user
          method: GET
          policies:
            - policyType: oidc
              config: <oidcProviderConfig>
              redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
        - prefix: /
          method: ALL
          policies:
            -
              policyType: jwt
              config: <jwtConfig>

Adapter

To see the Adapter logs, you can use kubectl or access the pod from the appidentityandaccessAdapter pod from the Kubernetes console.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq

Mixer

If the Adapter does not appear to receive requests, check the Mixer logs to ensure that it connected successfully to the Adapter.

alias mixer_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=telemetry -o jsonpath='{.items[0].metadata.name}') -c mixer"
mixer_logs | jq