WebSphere Liberty 운영자용 싱글 사인온(SSO) 구성

관리자는 WebSphere® Liberty 운영자가 사용자를 인증하고 관리할 수 있도록 싱글 사인온(SSO)을 구성할 수 있습니다. 인증은 Google, 페이스북, LinkedIn,, 트위터, GitHub,, 또는 OpenID 나 2.0 클라이언트와 같은 외부 제공업체에 위임할 수 있습니다.

프로시저

싱글 사인온으로 애플리케이션 이미지를 구성하고 빌드합니다. 애플리케이션을 컨테이너로 이동 및 컨테이너의 애플리케이션에 대해 싱글 사인온 (SSO) 구성의 지시사항을 따르십시오.
운영자에서 SSO를 구성하려면 다음 선택사항 중 하나를 완료하십시오.

지정된 클라이언트 ID 및 시크릿으로 SSO 구성

운영자는 클라이언트 ID 및 시크릿을 미리 지정할 수 있습니다. 이 구성의 단점은 한 번 등록에 필요한 정보를 제공하는 제공자 관리자에게 자동으로 제공 하지 않고 등록을 위해 클라이언트 ID및 시크릿을 반복적으로 제공해야 한다는 점입니다.

애플리케이션 이미지에서 선택한 로그인 제공자에 대한 클라이언트 ID, 클라이언트 시크릿 및 토큰과 같은 민감한 정보를 지정하는 시크릿을 작성하십시오.
WebSphereLibertyApplication 인스턴스와 동일한 네임스페이스에 WebSphereLibertyApplication_name-wlapp-sso(이)라는 Secret을(를) 작성하십시오. 다음 샘플 스니펫에서 WebSphereLibertyApplication의 이름은 my-app이므로 시크릿의 이름은 my-app-wlapp-sso이어야 합니다. 둘 다 demo(이)라는 네임스페이스에 있습니다.

Secret 내의 키는 provider_name-sensitive_field_name 이름 지정 패턴을 따라야 합니다. 예: google-clientSecret. 사이에 - 문자 대신 . 또는 _을(를) 사용할 수도 있습니다. 예를 들어, oauth2_userApiToken입니다.
```
apiVersion: v1
kind: Secret
metadata:
  # Name of the secret should be in this format: <WebSphereLibertyApplication_name>-wlapp-sso
  name: my-app-wlapp-sso
  # Secret must be created in the same namespace as the WebSphereLibertyApplication instance
  namespace: demo
type: Opaque
data:
  # The keys must be in this format: <provider_name>-<sensitive_field_name>
  github-clientId: bW9vb29vb28=
  github-clientSecret: dGhlbGF1Z2hpbmdjb3c=
  twitter-consumerKey: bW9vb29vb28=
  twitter-consumerSecret: dGhlbGF1Z2hpbmdjb3c=
  oidc-clientId: bW9vb29vb28=
  oidc-clientSecret: dGhlbGF1Z2hpbmdjb3c=
  oauth2-clientId: bW9vb29vb28=
  oauth2-clientSecret: dGhlbGF1Z2hpbmdjb3c=
  oauth2-userApiToken: dGhlbGF1Z2hpbmdjb3c=
```
운영자는 SSO 시크릿의 작성 및 삭제와 이에 대한 업데이트를 감시합니다. 시크릿에서 키를 추가, 업데이트 또는 제거하면 자동으로 애플리케이션에 전달됩니다.
WebSphereLibertyApplication 사용자 정의 자원(CR)에서 싱글 사인온을 구성하십시오. 운영자가 시크릿의 값을 애플리케이션에 전달할 수 있도록 최소한 .spec.sso: {} 필드를 설정하십시오. 추가 SSO 구성은 WebSphereLibertyApplication CR 을 참조하십시오.
필요한 인증서를 사용하여 보안 서비스 및 보안 라우트를 구성하십시오. 자세한 정보는 인증서를 참조하십시오.

Google 및 Facebook과 같은 소셜 로그인 제공자를 포함하여 인기 있는 ID 제공자의 인증서를 자동으로 신뢰하려면 SEC_TLS_TRUSTDEFAULTCERTS 환경 변수를 true로 설정하십시오. Kubernetes 클러스터에서 발행된 인증서를 자동으로 신뢰하려면 SEC_IMPORT_K8S_CERTS 환경 변수를 true(으)로 설정하십시오. 또는 애플리케이션 이미지를 빌드하거나 애플리케이션을 배치할 때 볼륨을 사용하여 마운트할 때 필요한 인증서를 수동으로 포함할 수 있습니다.

apiVersion: liberty.websphere.ibm.com/v1
kind: WebSphereLibertyApplication
metadata:
  name: my-app
  namespace: demo
spec:
  applicationImage: quay.io/my-repo/my-app:1.0
  env:
    - name: SEC_TLS_TRUSTDEFAULTCERTS
      value: "true"
    - name: SEC_IMPORT_K8S_CERTS
      value: "true"
  sso:
    redirectToRPHostAndPort: https://redirect-url.mycompany.com
    github:
      hostname: github.mycompany.com
    oauth2:
      - authorizationEndpoint: specify-required-value
        tokenEndpoint: specify-required-value
    oidc:
      - discoveryEndpoint: specify-required-value
  service:
    certificateSecretRef: mycompany-service-cert
    port: 9443
    type: ClusterIP
  expose: true
  route:
    certificateSecretRef: mycompany-route-cert
    termination: reencrypt

OIDC 제공자를 사용하여 SSO 자동 등록 구성

운영자는 클라이언트 ID와 클라이언트 시크릿을 미리 요청하지 않고 제공자에게 요청할 수 있습니다. 제공자 관리자가 클라이언트 ID및 시크릿을 반복적으로 제공하는 대신 등록에 필요한 정보를 한 번 제공할 수 있으므로 이 기능은 배치를 단순화할 수 있습니다. 제공자에서 클라이언트로의 콜백 URL은 운영자가 제공하므로 미리 알 필요가 없습니다.

provider_name-autoreg-field_name 라는 속성을 Kubernetes 시크릿에 추가하십시오.
먼저 운영자는 .spec.sso.oidc[].discoveryEndpoint 필드에 대한 https 요청을 수행하여 후속 REST 호출에 대한 URL을 확보합니다. 다음으로, 제공자에 대한 다른 REST 호출을 작성하고 클라이언트 ID및 클라이언트 시크릿을 확보합니다. Kubernetes 시크릿은 획득한 값으로 업데이트됩니다.

Red Hat® 싱글 사인온 (RH-SSO) 의 경우 .spec.sso.oidc[].userNameAttribute 필드를 preferred_username 로 설정하여 로그인하는 데 사용된 사용자 ID를 얻을 수 있습니다. IBM Security Verify의 경우 필드를 given_name(으)로 설정하십시오.

다음 예제 시크릿은 RH-SSO와 IBM® Security Verify로 Red Hat OpenShift®에서 테스트됩니다.

apiVersion: v1
kind: Secret
metadata:
  # Name of the secret should be in this format: <WebSphereLibertyApplication_name>-wlapp-sso
  name: my-app-wlapp-sso
  # Secret must be created in the same namespace as the WebSphereLibertyApplication instance
  namespace: demo
type: Opaque
data:
  # base64 encode the data before entering it here.
  #
  # Leave the clientId and secret out, registration will obtain them and update their values.
  # oidc-clientId
  # oidc-clientSecret
  #
  # Reserved: <provider>-autoreg-RegisteredClientId and RegisteredClientSecret
  # are used by the operator to store a copy of the clientId and clientSecret values.
  #
  # Automatic registration attributes have -autoreg- after the provider name.
  #
  # Red Hat Single Sign On requires an initial access token for registration.
  oidc-autoreg-initialAccessToken: xxxxxyyyyy
  #
  # IBM Security Verify requires a special clientId and clientSecret for registration.
  # oidc-autoreg-initialClientId: bW9vb29vb28=
  # oidc-autoreg-initialClientSecret: dGhlbGF1Z2hpbmdjb3c=
  #
  # Optional: Grant types are the types of OAuth flows the resulting clients will allow
  # Default is authorization_code,refresh_token. Specify a comma separated list.
  # oidc-autoreg-grantTypes: base64 data goes here
  #
  # Optional: Scopes limit the types of information about the user that the provider will return.
  # Default is openid,profile. Specify a comma-separated list.
  # oidc-autoreg-scopes: base64 data goes here
  #
  # Optional: To skip TLS certificate checking with the provider during registration, specify insecureTLS as true. 
  # Default is false.
  # oidc-autoreg-insecureTLS: dHJ1ZQ==

다중 OIDC 및 OAuth 2.0 제공자 구성

여러 OIDC와 OAuth 2.0 제공자를 사용하여 인증할 수 있습니다.

여러 OIDC 또는 OAuth 2.0 제공자를 사용하여 애플리케이션 이미지를 구성하고 빌드합니다.
예를 들어, Dockerfile에서 제공자 이름을 설정합니다. 제공자 이름은 고유해야 하며 영숫자 문자만 포함해야 합니다.
```
ARG SEC_SSO_PROVIDERS="google oidc:provider1,provider2 oauth2:provider3,provider4"
```

SSO Secret의 제공자 이름을 사용하여 클라이언트 ID 및 시크릿을 지정하십시오.

예를 들어, 다음 Secret은(는) 클라이언트 ID 및 시크릿에 대해 provider1-clientSecret: dGhlbGF1Z2hpbmdjb3c=을(를) 설정합니다.

apiVersion: v1
kind: Secret
metadata:
  # Name of the secret should be in this format: <WebSphereLibertyApplication_name>-wlapp-sso
  name: my-app-wlapp-sso
  # Secret must be created in the same namespace as the WebSphereLibertyApplication instance
  namespace: demo
type: Opaque
data:
  # The keys must be in this format: <provider_name>-<sensitive_field_name>
  google-clientId: xxxxxxxxxxxxx
  google-clientSecret: yyyyyyyyyyyyyy
  provider1-clientId: bW9vb29vb28=
  provider1-clientSecret: dGhlbGF1Z2hpbmdjb3c=
  provider2-autoreg-initialClientId: bW9vb29vb28=
  provider2-autoreg-initialClientSecret: dGhlbGF1Z2hpbmdjb3c=
  provider3-clientId: bW9vb29vb28=
  provider3-clientSecret: dGhlbGF1Z2hpbmdjb3c=
  provider4-clientId: bW9vb29vb28=
  provider4-clientSecret: dGhlbGF1Z2hpbmdjb3c=

WebSphereLibertyApplication CR에서 각 해당 제공자에 대한 필드를 구성하십시오. .spec.sso.oidc[].id 및 .spec.sso.oauth2[].id 필드 중 하나 또는 둘 다 사용하십시오.

sso:
  oidc:
    - id: provider1
      discoveryEndpoint: specify-required-value
    - id: provider2
      discoveryEndpoint: specify-required-value
  oauth2:
    - id: provider3
      authorizationEndpoint: specify-required-value
      tokenEndpoint: specify-required-value
    - id: provider4
      authorizationEndpoint: specify-required-value
      tokenEndpoint: specify-required-value