11.9. 인증 정보 사용 사례에 대한 3scale WebAssembly 모듈 예제


구성 단계를 적용하는 데 대부분의 시간을 할애하여 서비스에 대한 요청의 인증 정보를 가져옵니다.

다음은 특정 사용 사례에 맞게 조정하도록 수정할 수 있는 인증 정보 예제입니다.

자체 조회 쿼리 를 사용하여 여러 소스 오브젝트를 지정할 때 모두 결합할 수 있지만 둘 중 하나가 성공적으로 해결될 때까지 순서대로 평가됩니다.

11.9.1. 쿼리 문자열 매개변수의 API 키(user_key)

다음 예제에서는 쿼리 문자열 매개변수 또는 동일한 이름의 헤더에서 user_key 를 조회합니다.

credentials:
  user_key:
    - query_string:
        keys:
          - user_key
    - header:
        keys:
          - user_key

11.9.2. 애플리케이션 ID 및 키

다음 예제에서는 쿼리 또는 헤더에서 app_keyapp_id 자격 증명을 조회합니다.

credentials:
  app_id:
    - header:
        keys:
          - app_id
    - query_string:
        keys:
          - app_id
  app_key:
    - header:
        keys:
          - app_key
    - query_string:
        keys:
          - app_key

11.9.3. 인증 헤더

요청에는 권한 부여 헤더에 app_idapp_key 가 포함됩니다. 끝에 출력되는 하나 이상의 값이 있는 경우 app_key 를 할당할 수 있습니다.

해결 방법은 끝에 하나 또는 두 개의 출력이 있는 경우 app_key 를 할당합니다.

권한 부여 헤더는 권한 부여 유형이 포함된 값을 지정하고 해당 값은 Base64 로 인코딩됩니다. 즉, 값을 공백 문자로 분할하고 두 번째 출력을 가져온 다음 콜론(:)을 구분 기호로 사용하여 다시 분할할 수 있습니다. 예를 들어 app_id:app_key 형식을 사용하는 경우 헤더는 인증 정보에 대한 다음 예와 유사합니다.

aladdin:opensesame: Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

다음 예와 같이 소문자 헤더 필드 이름을 사용해야 합니다.

credentials:
  app_id:
    - header:
        keys:
          - authorization
        ops:
          - split:
              separator: " "
              max: 2
          - length:
              min: 2
          - drop:
              head: 1
          - base64_urlsafe
          - split:
              max: 2
  app_key:
    - header:
        keys:
          - app_key

이전 예제 사용 사례에서는 헤더에서 권한 부여를 확인합니다.

  1. 문자열 값을 사용하여 공백으로 분할하여 인증정보 유형 및 인증 정보 자체의 두 개 이상의 값을 생성하는지 확인한 다음 인증 정보 -유형을 삭제합니다.
  2. 그런 다음 필요한 데이터를 포함하는 두 번째 값을 디코딩하고 콜론(:) 문자를 사용하여 첫 번째 app_id, app_key 를 포함한 작업 스택을 사용하여 분할합니다.

    1. 권한 부여 헤더에 app_key 가 없으면 해당 특정 소스가 확인됩니다. 예를 들어 이 경우 키가 app_key 인 헤더가 있습니다.
  3. 인증 정보에 추가 조건을 추가하려면 app_idaladdin 또는 admin 인 경우 기본 권한 부여를 허용하거나 app_id 가 길이가 8자 이상입니다.
  4. app_key 는 다음 예와 같이 값을 포함해야 하며 최소 64자 이상이어야 합니다.

    credentials:
      app_id:
        - header:
            keys:
              - authorization
            ops:
              - split:
                  separator: " "
                  max: 2
              - length:
                  min: 2
              - reverse
              - glob:
                - Basic
              - drop:
                  tail: 1
              - base64_urlsafe
              - split:
                  max: 2
              - test:
                  if:
                    length:
                      min: 2
                  then:
                    - strlen:
                        max: 63
                    - or:
                        - strlen:
                            min: 1
                        - drop:
                            tail: 1
              - assert:
                - and:
                  - reverse
                  - or:
                    - strlen:
                        min: 8
                    - glob:
                      - aladdin
                      - admin
  5. 권한 부여 헤더 값을 선택한 후 유형을 맨 위에 배치하도록 스택을 리버스하여 기본 인증 정보-type이 제공됩니다.
  6. 그 위에 glob match를 실행합니다. 유효성을 검증하고 인증 정보가 디코딩되고 분할되면 스택 하단에서 app_id 를 가져오고 상단에 app_key 가 발생할 수 있습니다.
  7. 테스트 실행: 스택에 두 개의 값이 있는 경우, 이는 app_key 를 인수했음을 의미합니다.

    1. app_idapp_key 를 포함하여 문자열 길이가 1에서 63 사이인지 확인합니다. 키 길이가 0인 경우 키를 삭제하고 키가 없는 것처럼 계속합니다. app_id 만 있고 app_key 가 없는 경우 누락된 다른 분기는 성공적인 테스트 및 평가가 계속됨을 나타냅니다.

마지막 작업인 assert 는 부작용을 스택에 추가하지 않음을 나타냅니다. 그런 다음 스택을 수정할 수 있습니다.

  1. 맨 위에 app_id 를 갖도록 스택을 리버스합니다.

    1. app_key 가 있는지 여부에 관계없이 스택을 리버스하면 app_id 가 맨 위에 있습니다.
  2. 테스트 전반에서 스택의 내용을 보존하려면 를 사용합니다.

    그런 다음 다음 옵션 중 하나를 사용합니다.

    • app_id 의 문자열 길이가 8인지 확인합니다.
    • app_idaladdin 또는 admin 과 일치하는지 확인합니다.

11.9.4. OpenID Connect (OIDC) 사용 사례

Service Mesh 및 3scale Istio 어댑터의 경우 다음 예에 표시된 대로 RequestAuthentication 을 배포하여 자체 워크로드 데이터 및 jwtRules 를 채워야 합니다.

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: <info>
spec:
  selector:
    matchLabels:
      app: <productpage>
  jwtRules:
  - issuer: >-
      "<url>/auth/realms/<realm_name>"
    jwksUri: >-
      "<url>/auth/realms/<realm_name>/protocol/openid-connect/certs"

RequestAuthentication 을 적용하면 JWT 토큰을 검증하기 위해 기본 플러그인 으로 Envoy 를 구성합니다. 프록시는 모듈을 실행하기 전에 모든 것을 검증하므로 실패하는 요청이 3scale WebAssembly 모듈로 만들지 않습니다.

JWT 토큰이 검증되면 프록시는 해당 콘텐츠를 내부 메타데이터 오브젝트에 저장하고, 해당 키는 플러그인의 특정 구성에 따라 달라지는 항목을 저장합니다. 이 사용 사례는 알 수 없는 키 이름을 포함하는 단일 항목을 사용하여 구조 오브젝트를 조회할 수 있는 기능을 제공합니다.

OIDC의 3scale app_id 는 OAuth client_id 와 일치합니다. 이는 JWT 토큰의 azp 또는 aud 필드에 있습니다.

Envoy의 기본 JWT 인증 필터에서 app_id 필드를 가져오려면 다음 예제를 참조하십시오.

credentials:
  app_id:
    - filter:
        path:
          - envoy.filters.http.jwt_authn
          - "0"
        keys:
          - azp
          - aud
        ops:
          - take:
              head: 1

이 예제에서는 필터 소스 유형을 사용하여 Envoy-별 JWT 인증 네이티브 플러그인에서 오브젝트의 필터 메타데이터를 찾도록 모듈에 지시합니다. 이 플러그인에는 단일 항목이 있고 사전 구성된 이름이 있는 구조 오브젝트의 일부로 JWT 토큰이 포함됩니다. 단일 항목에만 액세스하도록 지정하려면 0 을 사용합니다.

결과 값은 다음 두 필드를 해결할 구조입니다.

  • azp: app_id 가 있는 값입니다.
  • AUD: 이 정보를 찾을 수 있는 값입니다.

이 작업을 수행하면 할당에 대해 하나의 값만 유지됩니다.

11.9.5. 헤더에서 JWT 토큰 가져오기

일부 설정에는 인증된 토큰이 JSON 형식의 헤더를 통해 이 모듈에 도달하는 JWT 토큰에 대한 검증 프로세스가 있을 수 있습니다.

app_id 를 가져오려면 다음 예제를 참조하십시오.

credentials:
  app_id:
    - header:
        keys:
          - x-jwt-payload
        ops:
          - base64_urlsafe
          - json:
            - keys:
              - azp
              - aud
          - take:
              head: 1
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.