지원콘솔개발자평가판 시작연락처

8.3. 인증 흐름

인증 흐름 은 로그인, 등록 및 기타 Red Hat Single Sign-On 워크플로 중 인증, 화면 및 작업의 컨테이너입니다. 모든 흐름, 작업 및 검사를 보려면 각 흐름에는 다음이 필요합니다.

절차

  1. 메뉴에서 인증을 클릭합니다.
  2. 흐름 탭을 클릭합니다.

8.3.1. 기본 제공 흐름

Red Hat Single Sign-On에는 여러 가지 흐름이 내장되어 있습니다. 이러한 흐름을 수정할 수는 없지만 필요에 맞게 흐름의 요구 사항을 변경할 수 있습니다.

드롭다운 목록에서 브라우저 를 선택하여 browsers Flow 화면을 표시합니다.

브라우저 흐름

Browser Flow

드롭다운 목록의 질문 표시 툴팁 위로 커서를 이동하여 흐름에 대한 설명을 확인합니다. 두 섹션이 있습니다.

8.3.1.1. auth 유형

인증 또는 실행할 작업의 이름입니다. 인증을 들여쓰기하면 하위 흐름에 있습니다. 부모의 동작에 따라 실행될 수도 있고 그렇지 않을 수도 있습니다.

  1. 쿠키

    사용자가 처음 로그인하면 Red Hat Single Sign-On이 세션 쿠키를 설정합니다. 쿠키가 이미 설정되어 있으면 이 인증 유형이 성공한 것입니다. 쿠키 공급자는 성공을 반환하고 이 수준의 흐름에서 각 실행을 대체 하므로 Red Hat Single Sign-On은 다른 실행을 수행하지 않습니다. 이로 인해 로그인에 성공합니다.

  2. Kerberos

    이 인증자는 기본적으로 비활성화되어 있으며 IANA 흐름 중에 건너뜁니다.

  3. ID 공급자 리디렉션

    이 작업은 Actions > Config 링크를 통해 구성됩니다. ID 브로커 를 위해 다른 IdP로 리디렉션됩니다.

  4. 양식

    이 하위 흐름이 대안으로 표시되므로 authentication 유형이 통과된 경우 실행되지 않습니다. 이 하위 흐름에는 실행해야 하는 추가 인증 유형이 포함되어 있습니다. Red Hat Single Sign-On은 이 하위 흐름에 대한 실행을 로드하고 처리합니다.

첫 번째 실행은 사용자 이름 암호 양식에 사용자 이름 및 암호 페이지를 렌더링하는 인증 유형입니다. 필수 로 표시되어 있으므로 사용자가 유효한 사용자 이름과 암호를 입력해야 합니다.

두 번째 실행은 browsers - Conditional OTP 하위 흐름입니다. 이 하위 흐름은 조건 - 사용자 구성 실행 결과에 따라 조건부 로 실행됩니다. 결과가 true인 경우 Red Hat Single Sign-On은 이 하위 흐름에 대한 실행을 로드하여 처리합니다.

다음 실행은 상태 - 사용자 구성 인증입니다. 이 인증은 Red Hat Single Sign-On이 사용자의 흐름에 다른 실행을 구성했는지 확인합니다. browser - Conditional OTP 하위 흐름은 사용자가 OTP 인증 정보가 구성된 경우에만 실행됩니다.

최종 실행은 OTP Form 입니다. Red Hat Single Sign-On은 이 실행을 필요에 따라 표시되지만 조건부 하위 흐름의 설정으로 인해 사용자에게 OTP 인증 정보가 설정된 경우에만 실행됩니다. 그렇지 않은 경우 사용자는 OTP 양식을 볼 수 없습니다.

8.3.1.2. 요구 사항

작업 실행을 제어하는 일련의 라디오 버튼이 실행됩니다.

8.3.1.2.1. 필수 항목

흐름에 필요한 모든 요소는 순차적으로 실행해야 합니다. 필요한 요소가 실패하면 흐름이 종료됩니다.

8.3.1.2.2. alternative

흐름이 성공한 것으로 평가되려면 단일 요소만 성공적으로 실행해야 합니다. 필수 흐름 요소는 흐름을 성공으로 표시하기에 충분하기 때문에 필수 흐름 요소가 포함된 흐름 내의 모든 대체 흐름 요소는 실행되지 않습니다.Because the Required flow elements are sufficient to mark a flow as successful, any Alternative flow element within a flow containing Required flow elements will not execute.

8.3.1.2.3. disabled

요소는 흐름을 성공으로 표시하는 것으로 계산되지 않습니다.

8.3.1.2.4. Condition

이 요구 사항 유형은 하위 흐름에서만 설정됩니다.

  • Conditional 하위 흐름에는 실행이 포함됩니다. 이러한 실행은 논리 문으로 평가되어야 합니다.
  • 모든 실행이 true 로 평가되면 조건 하위 흐름이 Required 로 작동합니다.
  • 모든 실행이 false 로 평가되면 Conditional 하위 흐름이 Disabled 로 작동합니다.
  • 실행을 설정하지 않으면 Conditional 하위 흐름이 Disabled 로 작동합니다.
  • 흐름에 실행이 포함되어 있고 흐름이 조건부 로 설정되지 않은 경우 Red Hat Single Sign-On은 실행을 평가하지 않으며 실행은 기능적으로 Disabled 로 간주됩니다.

8.3.2. 흐름 생성

중요한 기능 및 보안 고려 사항은 흐름을 설계할 때 적용됩니다.

흐름을 만들려면 다음을 수행합니다.

절차

  1. 메뉴에서 인증을 클릭합니다.
  2. New 를 클릭합니다.
참고

기존 흐름을 복사한 다음 수정할 수 있습니다. 흐름을 선택하고 복사를 클릭하고 새 흐름의 이름을 입력합니다.

새 흐름을 만들 때 먼저 다음 옵션을 사용하여 최상위 흐름을 만들어야 합니다.

별칭
흐름의 이름입니다.
설명
흐름으로 설정할 수 있는 설명입니다.
최상위 흐름 유형
흐름의 유형입니다. 유형 클라이언트는 클라이언트 (애플리케이션)의 인증에만 사용됩니다. 다른 모든 경우에는 generic 을 선택합니다.

최상위 흐름 생성

Top Level Flow

Red Hat Single Sign-On이 흐름을 생성하면 Red Hat Single Sign-On에 삭제,실행 추가, 흐름 추가 버튼이 표시됩니다.

비어 있는 새 흐름

New Flow

세 가지 요소는 흐름 및 하위 흐름의 동작을 결정합니다.

  • 흐름 및 하위 흐름 구조입니다.
  • 흐름 내의 실행
  • 하위 흐름 및 실행 내에 설정된 요구 사항입니다.

실행은 재설정 이메일을 OTP 검증에 보내는 것부터 다양한 작업을 수행합니다. 실행 추가 버튼을 사용하여 실행을 추가합니다. 실행에 대한 설명을 보려면 공급자 옆에 있는 물음표 위로 마우스를 가져갑니다.

인증 실행 추가

Adding an Authentication Execution

두 가지 유형의 실행, 자동 실행 및 대화형 실행이 있습니다. 자동 실행 은 10.0.0.1 실행 과 유사하며 흐름에서 자동으로 작업을 수행합니다. 대화형 실행 은 입력을 받기 위한 흐름을 중지합니다. 실행을 성공적으로 실행하면 상태가 success 로 설정됩니다. 흐름을 완료하려면 성공 상태의 실행이 하나 이상 필요합니다.

흐름 추가 버튼을 사용하여 최상위 흐름에 하위 흐름을 추가할 수 있습니다. 흐름 추가 버튼을 클릭하면 실행 흐름 만들기 페이지가 표시됩니다. 이 페이지는 최상위 양식 만들기 페이지와 유사합니다. 차이점은 흐름 유형이 일반 (기본값) 또는 형식일 수 있다는 것입니다. 양식 유형은 내장 등록 흐름과 유사하게 사용자의 양식을 생성하는 하위 흐름을 구성합니다. 하위 흐름 성공 여부는 포함된 하위 흐름을 포함하여 실행 결과를 평가하는 방법에 따라 달라집니다. 하위 흐름이 작동하는 방법에 대한 자세한 내용은 실행 요구 사항 섹션 을 참조하십시오.

참고

실행을 추가한 후 요구 사항에 올바른 값이 있는지 확인합니다.

흐름의 모든 요소에는 작업 메뉴의 Delete 옵션이 있습니다. 이 작업은 흐름에서 요소를 제거합니다. 실행에는 실행을 구성하는 Config 메뉴 옵션이 있습니다. 또한 실행 추가 및 흐름 추가 메뉴 옵션을 사용하여 실행 및 하위 흐름을 하위 흐름에 추가할 수도 있습니다.

실행 순서가 중요하므로 위 및 아래 버튼을 사용하여 흐름 내에서 실행 및 하위 흐름을 해당 이름 옆에 이동할 수 있습니다.

주의

인증 흐름을 구성할 때 구성을 올바르게 테스트하여 설정에 보안 문제가 없는지 확인합니다. 다양한 코너 케이스를 테스트하는 것이 좋습니다. 예를 들어 인증 전에 사용자 계정에서 다양한 인증 정보를 제거할 때 사용자의 인증 동작을 테스트하는 것이 좋습니다.

예를 들어 OTP Form 또는 WebAuthn Authenticator와 같은 2차 인증자가 REQUIRED로 흐름에 구성되고 사용자에게 특정 유형의 인증 정보가 없는 경우 사용자는 인증 과정에서 특정 인증 정보를 설정할 수 있습니다. 이 경우 인증 중에 사용자가 인증할 때 이 자격 증명을 인증하지 않습니다. 브라우저 인증의 경우 암호 또는 WebAuthn Passwordless Authenticator와 같은 1단계 인증 정보로 인증 흐름을 구성해야 합니다.

8.3.3. 암호 없는 브라우저 로그인 흐름 생성

흐름 생성을 설명하기 위해 이 섹션에서는 고급 브라우저 로그인 흐름 만들기에 대해 설명합니다. 이 흐름의 목적은 사용자가 WebAuthn 을 사용하여 암호 없는 방식으로 로그인하거나 암호 및 OTP를 사용한 2단계 인증 중에서 선택할 수 있도록 하는 것입니다.

절차

  1. 메뉴에서 인증을 클릭합니다.
  2. 흐름 탭을 클릭합니다.
  3. New 를 클릭합니다.
  4. browser Password-less 를 별칭으로 입력합니다.
  5. 저장을 클릭합니다.
  6. 실행 추가를 클릭합니다.
  7. 드롭다운 목록에서 10.0.0.1을 선택합니다.
  8. 저장을 클릭합니다.
  9. authentication type에 대해 Alternative 를 클릭하여 요구 사항을 alternative로 설정합니다.
  10. 실행 추가를 클릭합니다.
  11. 드롭다운 목록에서 Kerberos 를 선택합니다.
  12. 실행 추가를 클릭합니다.
  13. 드롭다운 목록에서 ID 공급자 리디렉션 을 선택합니다.
  14. 저장을 클릭합니다.
  15. Identity Provider Redirector 인증 유형으로 Alternative 를 클릭하여 요구 사항을 alternative로 설정합니다.
  16. 흐름 추가를 클릭합니다.
  17. 별칭 으로 CloudEvent를 입력합니다.
  18. 저장을 클릭합니다.

  19. forms 인증 유형으로 Alternative 를 클릭하여 요구 사항을 alternative로 설정합니다.

    브라우저 흐름의 공통 부분

    Passwordless browser login common

  20. forms 실행에 대한 작업을 클릭합니다.
  21. 실행 추가를 선택합니다.
  22. 드롭다운 목록에서 사용자 이름 양식을 선택합니다.
  23. 저장을 클릭합니다.
  24. Username Form 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.

이 단계에서 양식에는 사용자 이름만 필요하지만 암호가 필요하지 않습니다. 보안 위험을 방지하려면 암호 인증을 활성화해야 합니다.

  1. forms 하위 흐름에 대한 작업을 클릭합니다.
  2. 흐름 추가를 클릭합니다.
  3. 별칭으로 Authentication 을 입력합니다.
  4. 저장을 클릭합니다.
  5. Authentication 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.
  6. 인증 하위 흐름에 대한 작업을 클릭합니다.
  7. 실행 추가를 클릭합니다.
  8. 드롭다운 목록에서 Webauthn Passwordless Authenticator 를 선택합니다.
  9. 저장을 클릭합니다.
  10. Webauthn Passwordless Authenticator 인증 유형으로 Alternative 를 클릭하여 요구 사항을 alternative로 설정합니다.
  11. 인증 하위 흐름에 대한 작업을 클릭합니다.
  12. 흐름 추가를 클릭합니다.
  13. 별칭 으로 OTP가 포함된 Password 를 입력합니다.
  14. 저장을 클릭합니다.
  15. OTP 인증 유형으로 암호 대체 를 클릭하여 요구 사항을 alternative로 설정합니다.
  16. OTP 하위 흐름을 사용하여 암호에 대한 작업을 클릭합니다.
  17. 실행 추가를 클릭합니다.
  18. 드롭다운 목록에서 Password Form 을 선택합니다.
  19. 저장을 클릭합니다.
  20. Password Form 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.
  21. OTP 하위 흐름을 사용하여 암호에 대한 작업을 클릭합니다.
  22. 실행 추가를 클릭합니다.
  23. 드롭다운 목록에서 OTP 양식을 선택합니다.
  24. 저장을 클릭합니다.
  25. OTP Form 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.

마지막으로 바인딩을 변경합니다.

  1. 바인딩 탭을 클릭합니다.
  2. browsers flow 드롭다운 목록을 클릭합니다.
  3. 드롭다운 목록에서 generated Password-less 를 선택합니다.
  4. 저장을 클릭합니다.

암호 없는 브라우저 로그인

Passwordless browser login

사용자 이름을 입력하면 흐름은 다음과 같이 작동합니다.

사용자에게 WebAuthn 암호 없는 인증 정보가 기록된 경우 이러한 자격 증명을 사용하여 직접 로그인할 수 있습니다. 암호가 없는 로그인입니다. WebAuthn Passwordless 실행 및 OTP를 통한 암호 흐름이 Alternative 로 설정되어 있기 때문에 사용자가 OTP로 암호 를 선택할 수도 있습니다. Required 로 설정된 경우 사용자는 WebAuthn, password 및 OTP를 입력해야 합니다.

사용자가 WebAuthn 암호 없는 인증을 사용하여 다른 방법 확인 링크를 선택하면 사용자는 암호 와 보안 키 (WebAuthn 암호 없이)를 선택할 수 있습니다. 암호를 선택할 때 사용자는 계속해서 할당된 OTP로 로그인해야 합니다. 사용자에게 WebAuthn 자격 증명이 없는 경우 사용자는 암호를 입력한 다음 OTP를 입력해야 합니다. 사용자에게 OTP 인증 정보가 없는 경우 인증 정보를 기록하도록 요청합니다.

참고

WebAuthn 암호 없는 실행은 필수 가 아닌 Alternative 로 설정되어 있으므로 이 흐름은 사용자에게 WebAuthn 자격 증명을 등록하도록 요청하지 않습니다. 사용자가 Webauthn 자격 증명을 가지려면 관리자가 사용자에게 필요한 작업을 추가해야 합니다. 다음을 수행하여 수행합니다.

  1. 영역에서 Webauthn Register Passwordless 필수 작업 활성화( WebAuthn 문서 참조).
  2. 사용자의 자격 증명 관리 메뉴의 Credential Reset 부분을 사용하여 필요한 작업을 설정합니다. ???

이와 같은 고급 흐름을 만드는 것은 부작용이 있을 수 있습니다. 예를 들어 사용자의 암호를 재설정하는 기능을 활성화하면 암호 양식에서 액세스할 수 있습니다. 기본 인증 정보 재설정 흐름에서 사용자가 사용자 이름을 입력해야 합니다. 사용자가 이미 browser -less flow에서 이전에 사용자 이름을 입력했기 때문에 이 작업은 Red Hat Single Sign-On 및 사용자 경험에 대해 부적합합니다. 이 문제를 해결하려면 다음을 수행할 수 있습니다.

  • Reset Credentials flow를 복사합니다. 암호 없이 자격 증명을 재설정 하도록 이름을 설정합니다. 예를 들면 다음과 같습니다.
  • choosing user execution의 Actions 메뉴에서 Delete 를 선택합니다.
  • Bindings (바인딩) 메뉴에서 reset credential flow를 Reset Credentials 에서 암호 없이 자격 증명 재설정으로 변경합니다.

8.3.4. 단계별 메커니즘을 사용하여 브라우저 로그인 흐름 생성

이 섹션에서는 단계별 메커니즘을 사용하여 고급 브라우저 로그인 흐름을 만드는 방법에 대해 설명합니다. 단계별 인증은 사용자의 특정 인증 수준에 따라 클라이언트 또는 리소스에 대한 액세스를 허용하는 것입니다.

절차

  1. 메뉴에서 인증을 클릭합니다.
  2. 흐름 탭을 클릭합니다.
  3. New 를 클릭합니다.
  4. iPXE Incl Step up Mechanism 을 별칭으로 입력합니다.
  5. 저장을 클릭합니다.
  6. 실행 추가를 클릭합니다.
  7. 항목 목록에서 태그를 선택합니다.
  8. 저장을 클릭합니다.
  9. authentication type에 대해 Alternative 를 클릭하여 요구 사항을 alternative로 설정합니다.
  10. 흐름 추가를 클릭합니다.
  11. 별칭으로 Auth Flow 를 입력합니다.
  12. 저장을 클릭합니다.
  13. Auth Flow 인증 유형으로 대체 를 클릭하여 요구 사항을 alternative로 설정합니다.

이제 첫 번째 인증 수준에 대한 흐름을 구성합니다.

  1. Auth Flow 에 대한 작업을 클릭합니다.
  2. 흐름 추가를 클릭합니다.
  3. 별칭으로 1번째 조건 흐름을 입력합니다.
  4. 저장을 클릭합니다.
  5. 1st Condition Flow 인증 유형에 대해 Conditional 을 클릭하여 요구 사항을 Condition으로 설정합니다.
  6. 1번째 조건 흐름에 대한 작업을 클릭합니다.
  7. 실행 추가를 클릭합니다.
  8. 항목 목록에서 조건 - 인증 수준을 선택합니다.
  9. 저장을 클릭합니다.
  10. 조건 - 인증 수준 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.
  11. 조건 - 수준 인증의 작업을 클릭합니다.
  12. Config 를 클릭합니다.
  13. 별칭으로 Level 1 을 입력합니다.
  14. Level of Authentication (LoA)에 1 을 입력합니다.
  15. 최대 사용 기간을36000으로 설정합니다. 이 값은 초 단위이며 영역에 설정된 기본 SSO 세션 최대 시간 제한 시간입니다. 결과적으로 사용자가 이 수준으로 인증하면 SSO 로그인이 이 수준을 다시 사용할 수 있으며 사용자는 기본적으로 10시간인 사용자 세션이 종료될 때까지 이 수준으로 인증할 필요가 없습니다.

  16. 저장을 클릭합니다.

    첫 번째 인증 수준에 대한 조건 구성

    authentication step up condition 1

  17. 1번째 조건 흐름에 대한 작업을 클릭합니다.
  18. 실행 추가를 클릭합니다.
  19. 항목 목록에서 사용자 이름 암호 양식을 선택합니다.
  20. 저장을 클릭합니다.
  21. Username Password Form 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.

이제 두 번째 인증 수준에 대한 흐름을 구성합니다.

  1. Auth Flow 에 대한 작업을 클릭합니다.
  2. 흐름 추가를 클릭합니다.
  3. 별칭으로 2nd Condition Flow 를 입력합니다.
  4. 저장을 클릭합니다.
  5. 2nd Condition Flow 인증 유형에 대해 Conditional 을 클릭하여 요구 사항을 Condition으로 설정합니다.
  6. 2nd Condition Flow 에 대한 작업을 클릭합니다.
  7. 실행 추가를 클릭합니다.
  8. 항목 목록에서 조건 - 인증 수준을 선택합니다.
  9. 저장을 클릭합니다.
  10. 조건 - 인증 수준 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.
  11. 조건 - 수준 인증의 작업을 클릭합니다.
  12. Config 를 클릭합니다.
  13. 별칭으로 Level 2 를 입력합니다.
  14. Level of Authentication (LoA)에 2 를 입력합니다.
  15. 최대 사용 기간을 0 으로 설정합니다. 결과적으로 사용자가 인증하면 이 수준은 현재 인증에만 유효하지만 후속 SSO 인증은 아닙니다. 따라서 사용자는 이 수준이 요청될 때 항상 이 수준으로 다시 인증해야 합니다.

  16. 저장을 클릭합니다.

    두 번째 인증 수준에 대한 조건 구성

    authentication step up condition 2

  17. 2nd Condition Flow 에 대한 작업을 클릭합니다.
  18. 실행 추가를 클릭합니다.
  19. 항목 목록에서 OTP 양식을 선택합니다.
  20. 저장을 클릭합니다.
  21. OTP Form 인증 유형에 대해 Required 를 클릭하여 요구 사항을 required로 설정합니다.

마지막으로 바인딩을 변경합니다.

  1. 바인딩 탭을 클릭합니다.
  2. browser Flow 항목 목록을 클릭합니다.
  3. 항목 목록에서 generated Incl Step up Mechanism 을 선택합니다.
  4. 저장을 클릭합니다.

단계적 메커니즘으로 브라우저 로그인

authentication step up flow

특정 인증 수준 요청

단계별 메커니즘을 사용하려면 인증 요청에 요청된 LoA(인증 수준)를 지정합니다. claims 매개변수는 이러한 용도로 사용됩니다. 

https://{DOMAIN}/auth/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

claims 매개변수는 JSON 표현으로 지정됩니다. 

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

Red Hat Single Sign-On JavaScript 어댑터는 이 JSON을 쉽게 구성하고 로그인 요청으로 전송합니다. 자세한 내용은 JavaScript 어댑터 문서를 참조하십시오.

claim 매개변수 대신 더 간단한 매개변수 acr_values 를 사용하여 특정 수준을 필수가 아닌 값으로 요청할 수도 있습니다. 이는 OIDC 사양에 설명되어 있습니다.

acr_values 매개변수 또는 acr 클레임이 있는 매개변수 클레임 이 없을 때 사용되는 특정 클라이언트에 대한 기본 수준을 구성할 수도 있습니다. 자세한 내용은 클라이언트 ACR 구성을참조하십시오.

참고

숫자 값 대신 acr_values(예: gold)로 acr_values를 요청하려면 ACR과 KiA 간의 매핑을 구성합니다. 영역 수준(권장) 또는 클라이언트 수준에서 구성할 수 있습니다. 구성을 보려면 ACR to KiA Mapping 을 참조하십시오.

자세한 내용은 공식 OIDC 사양 을 참조하십시오.

흐름 논리

이전에 구성된 인증 흐름의 논리는 다음과 같습니다.
클라이언트가 인증 2(LoA 2)의 고급 인증 수준을 요청하는 경우 사용자는 전체 2 단계 인증(사용자 이름/암호 + OTP)을 수행해야 합니다. 그러나 사용자에게 이미 사용자 이름과 암호(LoA 1)로 로그인한 Keycloak에 세션이 있는 경우 사용자에게 두 번째 OTP(인증 요인)만 요청됩니다.

조건의 Max Age (최대 기간) 옵션은 후속 인증 수준의 유효 기간(초)을 결정합니다. 이 설정은 후속 인증 중에 사용자에게 인증 요소를 다시 제공하도록 요청할지 여부를 결정하는 데 도움이 됩니다. 클레임 또는 acr_values 매개변수에 의해 요청되고 레벨 X로 이미 인증된 경우(예: max age는 300으로 구성되고 310초 전에 인증한 사용자) 특정 수준으로 다시 인증하라는 요청을 받습니다. 그러나 수준이 아직 만료되지 않은 경우 사용자는 해당 수준으로 자동으로 인증된 것으로 간주됩니다.

값이 0인 Max Age 를 사용하면 특정 수준이 이 단일 인증에서만 유효합니다. 따라서 해당 수준을 요청하는 모든 재인증은 해당 수준으로 다시 인증해야 합니다. 이는 애플리케이션에서 더 높은 보안이 필요한 작업(예: 결제 전송)에 유용하며 항상 특정 수준의 인증이 필요합니다.

주의

로그인 요청이 클라이언트에서 사용자 브라우저를 통해 Red Hat Single Sign-On으로 전송될 때 클레임 또는 acr_values 와 같은 매개 변수는 URL의 사용자가 변경할 수 있습니다. 클라이언트가 PAR(Pushed Authorization Request), 요청 오브젝트 또는 사용자가 URL에서 매개변수를 다시 작성하지 못하도록 하는 기타 메커니즘을 사용하는 경우 이러한 상황을 완화할 수 있습니다. 따라서 인증 후 클라이언트는 ID 토큰을 확인하여 토큰의 acr 이 예상 수준에 해당하는지 다시 확인하는 것이 좋습니다.

매개 변수에서 명시적 수준을 요청하지 않는 경우 Red Hat Single Sign-On에는 이전 예제의 Username/Password와 같은 인증 흐름에 있는 첫 번째 KiA 조건으로 인증이 필요합니다. 사용자가 해당 수준으로 이미 인증되고 해당 수준이 만료된 경우 사용자는 다시 인증되지 않아도 되지만 토큰의 acr 값은 0입니다. 이 결과는 OIDC Core 1.0 사양의 섹션 2에 언급된 대로 수 명이 긴 브라우저 쿠키 만을 기반으로 한 인증으로 간주됩니다.

참고

충돌이 발생하는 상황은 관리자가 여러 흐름을 지정하고, 각각에 서로 다른 loA 수준을 설정하고, 다른 클라이언트에 흐름을 할당할 때 발생할 수 있습니다. 그러나 규칙은 항상 동일합니다. 사용자가 특정 수준이 있는 경우 클라이언트에 연결하는 데 해당 수준만 있으면 됩니다. 관리자는 loA가 일관성이 있는지 확인할 수 있습니다.

시나리오 예

  1. Max Age는 1단계 조건에 대해 300초로 구성됩니다.
  2. acr을 요청하지 않고 로그인 요청이 전송됩니다. 수준 1이 사용되며 사용자는 사용자 이름과 암호로 인증해야 합니다. 토큰에 acr=1 이 있습니다.
  3. 100초 후에 다른 로그인 요청이 전송됩니다. SSO로 인해 사용자가 자동으로 인증되고 토큰에 acr=1 이 반환됩니다.
  4. 또 다른 로그인 요청은 201초 후에 전송됩니다(2번 인증 이후 301초). SSO로 인해 사용자가 자동으로 인증되지만 수준 1이 만료된 것으로 간주되므로 토큰에서 acr=0 을 반환합니다.
  5. 다른 로그인 요청이 전송되었지만 이제 claim 매개변수에서 ACR의 레벨 1을 명시적으로 요청합니다. 사용자에게 사용자 이름/암호로 다시 인증하라는 메시지가 표시되고 acr=1 은 토큰에 반환됩니다.

토큰의 ACR 클레임

ACR 클레임은 acr 클라이언트 범위에 정의된 acr loa 수준 프로토콜 매퍼에 의해 토큰에 추가됩니다. 이 클라이언트 범위는 영역 기본 클라이언트 범위이므로 해당 영역의 새로 생성된 모든 클라이언트에 추가됩니다.

토큰 내에 acr 클레임을 사용하지 않거나 이를 추가하기 위한 사용자 지정 논리가 필요한 경우 클라이언트에서 클라이언트 범위를 제거할 수 있습니다.

로그인 요청이 필수 클레임으로 acr 을 요청하는 claims 매개변수를 사용하여 요청을 시작하는 경우 Red Hat Single Sign-On은 항상 지정된 수준 중 하나를 반환합니다. 지정된 수준 중 하나를 반환할 수 없는 경우(예: 요청된 수준이 인증 흐름에서 구성된 조건보다 알 수 없거나 큰 경우) Red Hat Single Sign-On에서 오류가 발생합니다.

8.3.5. 사용자 세션 제한 구성

사용자가 구성할 수 있는 세션 수에 대한 제한입니다. 세션은 영역별로 제한되거나 클라이언트별로 제한될 수 있습니다.

흐름에 세션 제한을 추가하려면 다음 단계를 수행합니다.

  1. 흐름에 대한 실행 추가 를 클릭합니다.
  2. 항목 목록에서 사용자 세션 개수 제한자를 선택합니다.
  3. 저장을 클릭합니다.
  4. User Session Count Limiter 인증 유형에 대해 필요한 것을 클릭하여 요구 사항을 required로 설정합니다.
  5. User Session Count Limiter 에 대한 작업을 클릭합니다.
  6. Config 를 클릭합니다.
  7. 이 구성의 별칭을 입력합니다.
  8. 사용자가 이 영역에 보유할 수 있는 필요한 최대 세션 수를 입력합니다. 값이 0이면 이 검사가 비활성화됩니다.
  9. 사용자가 클라이언트에 보유할 수 있는 필요한 최대 세션 수를 입력합니다. 값이 0이면 이 검사가 비활성화됩니다.

  10. 제한에 도달한 후 사용자가 세션을 만들려고 할 때 필요한 동작을 선택합니다. 사용 가능한 bahaviors는 다음과 같습니다. 

    Deny new session - when a new session is requested and the session limit is reached, no new sessions can be created.
Terminate oldest session - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created.
  11. 제한에 도달하면 표시할 사용자 정의 오류 메시지를 추가합니다.

사용자 세션 제한은 바인딩된 browsers 흐름,직접 부여 흐름 ,자격 증명 재설정 및 구성된 모든 ID 공급자의 후 로그인 흐름에 추가해야 합니다. 현재 관리자는 서로 다른 구성 간의 일관성을 유지 관리합니다.

CIBA에서는 사용자 세션 제한 기능을 사용할 수 없습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.