마이크로서비스 아키텍처의 SSO. 우리는 Keycloak을 사용합니다. 1 부

모든 대기업에서 X5 Retail Group도 예외는 아닙니다. 개발함에 따라 사용자 인증이 필요한 프로젝트의 수가 증가합니다. 시간이 지남에 따라 한 응용 프로그램에서 다른 응용 프로그램으로 사용자를 원활하게 전환해야 하며 단일 SSO(Single-Sing-On) 서버를 사용해야 합니다. 그러나 AD와 같은 ID 제공자 또는 추가 속성이 없는 기타가 이미 다양한 프로젝트에서 사용되고 있는 경우에는 어떻습니까? "식별 브로커"라고 하는 시스템 클래스가 도움이 될 것입니다. 가장 기능적인 것은 Keycloak, Gravitee 액세스 관리 등과 같은 대표입니다. 대부분의 경우 사용 사례는 기계 상호 작용, 사용자 참여 등 다를 수 있습니다. 솔루션은 모든 요구 사항을 하나로 결합할 수 있는 유연하고 확장 가능한 기능을 지원해야 합니다. 이러한 솔루션을 우리 회사는 이제 표시 브로커인 Keycloak을 보유하고 있습니다.

Keycloak은 RedHat에서 관리하는 오픈 소스 ID 및 액세스 제어 제품입니다. SSO - RH-SSO를 사용하는 회사 제품의 기초입니다.

기본 개념

솔루션과 접근 방식을 다루기 전에 프로세스의 용어와 순서를 결정해야 합니다.

신분증 식별자로 주제를 인식하는 절차입니다(즉, 이것은 이름, 로그인 또는 번호의 정의입니다).

인증 - 인증 절차입니다. (비밀번호로 이용자 확인, 전자서명으로 문자 확인 등)

권한 부여 - 리소스에 대한 액세스 제공(예: 이메일)입니다.

신원 중개인 키클록

열쇠망토 마이크로 서비스 아키텍처 패턴을 사용할 수 있는 IS에서 사용하도록 설계된 오픈 소스 ID 및 액세스 관리 솔루션입니다.

Keycloak은 SSO(Single Sign-On), 중개 ID 및 소셜 로그인, 사용자 연합, 클라이언트 어댑터, 관리 콘솔 및 계정 관리 콘솔과 같은 기능을 제공합니다.

Keycloak에서 지원하는 기본 기능:

• 브라우저 애플리케이션을 위한 단일 사인온 및 단일 사인아웃.
• OpenID/OAuth 2.0/SAML 지원.
• ID 브로커링 - 외부 OpenID Connect 또는 SAML ID 제공자를 사용한 인증.
• 소셜 로그인 - 사용자 식별을 위한 Google, GitHub, Facebook, Twitter 지원.
• 사용자 연합 - LDAP 및 Active Directory 서버와 기타 ID 공급자의 사용자 동기화.
• Kerberos 브리지 - 자동 사용자 인증을 위해 Kerberos 서버를 사용합니다.
• Admin Console - 웹을 통한 설정 및 솔루션 옵션의 통합 관리용.
• 계정 관리 콘솔 - 사용자 프로필을 자체적으로 관리합니다.
• 기업의 코퍼레이트 아이덴티티 기반 솔루션 커스터마이징
• 2FA 인증 - Google Authenticator 또는 FreeOTP를 사용한 TOTP/HOTP 지원.
• 로그인 흐름 - 사용자 자가 등록, 암호 복구 및 재설정 등이 가능합니다.
• 세션 관리 - 관리자는 단일 지점에서 사용자 세션을 관리할 수 있습니다.
• 토큰 매퍼 - 사용자 속성, 역할 및 기타 필수 속성을 토큰에 바인딩합니다.
• 영역, 애플리케이션 및 사용자 전반에 걸친 유연한 정책 관리.
• CORS 지원 - 클라이언트 어댑터에는 CORS 지원 기능이 내장되어 있습니다.
• SPI(Service Provider Interfaces) - 인증 흐름, ID 공급자, 프로토콜 매핑 등 서버의 다양한 측면을 사용자 지정할 수 있는 많은 수의 SPI입니다.
• JavaScript 애플리케이션용 클라이언트 어댑터, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• OpenID Connect Relying Party 라이브러리 또는 SAML 2.0 서비스 공급자 라이브러리를 지원하는 다양한 애플리케이션 작업을 지원합니다.
• 플러그인을 사용하여 확장 가능.

CI / CD 프로세스 및 Keycloak의 관리 프로세스 자동화를 위해 REST API / JAVA API를 사용할 수 있습니다. 문서는 전자적으로 사용할 수 있습니다.

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
자바 API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

엔터프라이즈 ID 공급자(온프레미스)

사용자 연합 서비스를 통해 사용자를 인증하는 기능.

통과 인증도 사용할 수 있습니다. 사용자가 Kerberos(LDAP 또는 AD)가 있는 워크스테이션에서 인증하는 경우 사용자 이름과 암호를 다시 입력하지 않고도 자동으로 Keycloak에 인증될 수 있습니다.

사용자의 인증 및 추가 권한 부여를 위해 프로젝트 초기 단계에서 긴 설정 및 통합이 필요하지 않기 때문에 개발 환경에 가장 적합한 관계형 DBMS를 사용할 수 있습니다. 기본적으로 Keycloak은 내장 DBMS를 사용하여 설정 및 사용자 데이터를 저장합니다.

지원되는 DBMS 목록은 광범위하며 MS SQL, Oracle, PostgreSQL, MariaDB, Oracle 등을 포함합니다. 지금까지 가장 많이 테스트된 것은 Oracle 12C Release1 RAC와 MariaDB 3.12용 Galera 10.1.19 클러스터입니다.

ID 공급자 - 소셜 로그인

소셜 네트워크에서 로그인을 사용할 수 있습니다. 사용자 인증 기능을 활성화하려면 Keycloack 관리 콘솔을 사용하십시오. 애플리케이션 코드를 변경할 필요가 없으며 이 기능은 즉시 사용할 수 있으며 프로젝트의 모든 단계에서 활성화할 수 있습니다.

사용자 인증을 위해 OpenID/SAML ID 공급자를 사용할 수 있습니다.

Keycloak에서 OAuth2를 사용하는 일반적인 인증 시나리오

인증 코드 흐름 - 서버 측 응용 프로그램과 함께 사용됩니다. 외부인이 애플리케이션의 소스 코드와 클라이언트 데이터를 사용할 수 없는 서버 애플리케이션에 적합하기 때문에 가장 일반적인 인증 권한 유형 중 하나입니다. 이 경우 프로세스는 리디렉션을 기반으로 합니다. 애플리케이션은 웹 브라우저와 같은 사용자 에이전트(사용자 에이전트)와 통신할 수 있어야 사용자 에이전트를 통해 리디렉션되는 API 인증 코드를 받을 수 있습니다.

암시적 흐름 - 모바일 또는 웹 애플리케이션(사용자 장치에서 실행되는 애플리케이션)에서 사용됩니다.

암시적 인증 권한 유형은 클라이언트 기밀성을 보장할 수 없는 모바일 및 웹 애플리케이션에서 사용됩니다. 암시적 권한 유형은 또한 사용자 에이전트 리디렉션을 사용하므로 애플리케이션에서 추가로 사용할 수 있도록 액세스 토큰이 사용자 에이전트에 전달됩니다. 이렇게 하면 사용자와 사용자 장치의 다른 응용 프로그램에서 토큰을 사용할 수 있습니다. 이 유형의 승인 권한은 애플리케이션의 ID를 인증하지 않으며 프로세스 자체는 리디렉션 URL(이전에 서비스에 등록됨)에 의존합니다.

암시적 흐름은 액세스 토큰 새로 고침 토큰을 지원하지 않습니다.

클라이언트 자격 증명 부여 흐름 — 애플리케이션이 API에 액세스할 때 사용됩니다. 이 유형의 권한 부여 권한은 일반적으로 즉각적인 사용자 상호 작용 없이 백그라운드에서 수행되어야 하는 서버 간 상호 작용에 사용됩니다. 클라이언트 자격 증명 부여 흐름을 통해 웹 서비스(기밀 클라이언트)는 다른 웹 서비스를 호출할 때 인증을 위해 사용자를 가장하는 대신 자체 자격 증명을 사용할 수 있습니다. 더 높은 수준의 보안을 위해 호출 서비스가 인증서(공유 비밀 대신)를 자격 증명으로 사용할 수 있습니다.

OAuth2 사양은 다음에 설명되어 있습니다.
RFC-6749
RFC-8252
RFC-6819

JWT 토큰과 그 이점

JWT(JSON 웹 토큰)는 개방형 표준(https://tools.ietf.org/html/rfc7519) JSON 개체로 당사자 간에 정보를 안전하게 전송하는 간결하고 독립적인 방법을 정의합니다.

표준에 따르면 토큰은 점으로 구분된 base-64 형식의 세 부분으로 구성됩니다. 첫 번째 부분은 헤더라고 하며 여기에는 토큰 유형과 디지털 서명을 얻기 위한 해시 알고리즘의 이름이 포함됩니다. 두 번째 부분은 기본 정보(사용자, 속성 등)를 저장합니다. 세 번째 부분은 디지털 서명입니다.

. .
DB에 토큰을 저장하지 마십시오. 유효한 토큰은 암호와 동일하므로 토큰을 저장하는 것은 일반 텍스트로 암호를 저장하는 것과 같습니다.
액세스 토큰 보안 서버 리소스에 대한 소유자 액세스 권한을 부여하는 토큰입니다. 일반적으로 수명이 짧고 토큰을 요청하는 당사자의 IP 주소와 같은 추가 정보를 전달할 수 있습니다.

새로 고침 토큰 클라이언트가 수명이 만료된 후 새 액세스 토큰을 요청할 수 있도록 하는 토큰입니다. 이러한 토큰은 일반적으로 장기간 발행됩니다.

마이크로 서비스 아키텍처에서 사용할 때의 주요 이점:

• XNUMX회 인증을 통해 다양한 애플리케이션 및 서비스에 접근할 수 있는 기능.
• 사용자 프로필에 필수 속성이 많지 않은 경우 페이로드에 추가할 수 있는 데이터(자동 및 즉시 포함)로 보강할 수 있습니다.
• 활성 세션에 대한 정보를 저장할 필요가 없으며 서버 응용 프로그램은 서명만 확인하면 됩니다.
• 페이로드의 추가 속성을 통해 보다 유연한 액세스 제어.
• 헤더 및 페이로드에 토큰 서명을 사용하면 솔루션 전체의 보안이 향상됩니다.

JWT 토큰 - 구성

이름 - 기본적으로 헤더에는 토큰 유형과 암호화에 사용되는 알고리즘만 포함됩니다.

토큰 유형은 "typ" 키에 저장됩니다. JWT에서 '유형' 키는 무시됩니다. "typ" 키가 있는 경우 해당 값은 이 개체가 JSON 웹 토큰임을 나타내는 JWT여야 합니다.

두 번째 키 "alg"는 토큰을 암호화하는 데 사용되는 알고리즘을 정의합니다. 기본적으로 HS256으로 설정되어야 합니다. 헤더는 base64로 인코딩됩니다.

{ "alg": "HS256", "유형": "JWT"}
페이로드(콘텐츠) - 페이로드는 확인해야 하는 모든 정보를 저장합니다. 페이로드의 각 키를 "클레임"이라고 합니다. 예를 들어 초대(비공개 프로모션)를 통해서만 애플리케이션에 입장할 수 있습니다. 우리는 누군가를 초대하고 싶을 때 초대 편지를 보냅니다. 이메일 주소가 초대를 수락한 사람의 것인지 확인하는 것이 중요하므로 이 주소를 페이로드에 포함하고 이를 위해 "email" 키에 저장합니다.

{ "이메일": "[이메일 보호]"}

페이로드의 키는 임의적일 수 있습니다. 그러나 예약된 몇 가지가 있습니다.

• iss(Issuer) - 토큰이 전송되는 애플리케이션을 식별합니다.
• sub(제목) - 토큰의 제목을 정의합니다.
• aud(대상)는 이 토큰의 수신자 목록인 대소문자 구분 문자열 또는 URI의 배열입니다. 수신 측에서 주어진 키가 있는 JWT를 수신하면 수신자에 JWT가 있는지 확인해야 합니다. 그렇지 않으면 토큰을 무시합니다.
• exp(만료 시간) - 토큰이 만료되는 시기를 나타냅니다. JWT 표준은 모든 구현이 만료된 토큰을 거부하도록 요구합니다. exp 키는 유닉스 형식의 타임스탬프여야 합니다.
• nbf(Not Before)는 토큰이 유효해지는 순간을 결정하는 유닉스 형식의 시간입니다.
• iat(Issued At) - 이 키는 토큰이 발행된 시간을 나타내며 JWT의 수명을 결정하는 데 사용할 수 있습니다. iat 키는 Unix 형식의 타임스탬프여야 합니다.
• Jti(JWT ID) — 이 토큰의 고유 식별자를 정의하는 문자열이며 대소문자를 구분합니다.

페이로드가 암호화된 형태로 전송되지 않는다는 점을 이해하는 것이 중요합니다(토큰을 중첩할 수 있고 그런 다음 암호화된 데이터를 전송할 수 있음). 따라서 비밀 정보를 저장할 수 없습니다. 헤더와 마찬가지로 페이로드는 base64로 인코딩됩니다.
서명 - 제목과 페이로드가 있으면 서명을 계산할 수 있습니다.

Base64 인코딩: 헤더와 페이로드를 가져오고 점을 통해 문자열로 결합합니다. 그런 다음 이 문자열과 비밀 키가 헤더에 지정된 암호화 알고리즘("alg" 키)에 입력됩니다. 키는 모든 문자열이 될 수 있습니다. 픽업하는 데 시간이 더 오래 걸리므로 더 긴 문자열이 가장 선호됩니다.

{"alg":"RSA1_5","페이로드":"A128CBC-HS256"}

Keycloak 장애 조치 클러스터 아키텍처 구축

모든 프로젝트에 단일 클러스터를 사용하는 경우 SSO 솔루션에 대한 요구 사항이 증가합니다. 프로젝트 수가 적은 경우 이러한 요구 사항은 모든 프로젝트에서 눈에 띄지 않지만 사용자 및 통합 수가 증가함에 따라 가용성 및 성능에 대한 요구 사항이 증가합니다.

단일 SSO 실패의 위험이 증가하면 솔루션 아키텍처에 대한 요구 사항과 중복 구성 요소에 사용되는 방법이 증가하고 매우 엄격한 SLA로 이어집니다. 이와 관련하여 솔루션 구현의 개발 또는 초기 단계에서 더 자주 프로젝트에는 자체 내결함성이 없는 인프라가 있습니다. 개발이 진행됨에 따라 개발 및 확장을 위한 기회를 마련해야 합니다. 컨테이너 가상화 또는 하이브리드 접근 방식을 사용하여 장애 조치 클러스터를 구축하는 것이 가장 유연합니다.

활성/활성 및 활성/수동 클러스터 모드에서 작업하려면 관계형 데이터베이스에서 데이터 일관성을 보장해야 합니다. 두 데이터베이스 노드는 서로 다른 지역에 분산된 데이터 센터 간에 동기식으로 복제되어야 합니다.

내결함성 설치의 가장 간단한 예입니다.

단일 클러스터를 사용하면 어떤 이점이 있습니까?

• 고가용성 및 성능.
• 작동 모드 지원: 활성/활성, 활성/수동.
• 동적으로 확장하는 기능 - 컨테이너 가상화를 사용할 때.
• 중앙 집중식 관리 및 모니터링 가능성.
• 프로젝트에서 사용자 식별/인증/권한 부여를 위한 통합 접근 방식.
• 사용자 개입 없이 서로 다른 프로젝트 간의 보다 투명한 상호 작용.
• 다양한 프로젝트에서 JWT 토큰을 재사용할 수 있는 기능.
• 단일 신뢰 지점.
• 마이크로서비스/컨테이너 가상화를 사용하여 프로젝트를 더 빠르게 시작합니다(추가 구성 요소를 들어 올리고 구성할 필요 없음).
• 공급업체로부터 상업적 지원을 구매할 수 있습니다.

클러스터를 계획할 때 찾아야 할 사항

DBMS

Keycloak은 데이터베이스 관리 시스템을 사용하여 영역, 클라이언트, 사용자 등을 저장합니다.
MS SQL, Oracle, MySQL, PostgreSQL과 같은 광범위한 DBMS가 지원됩니다. Keycloak은 자체 내장 관계형 데이터베이스와 함께 제공됩니다. 개발 환경과 같이 로드되지 않은 환경에서 사용하는 것이 좋습니다.

활성/활성 및 활성/수동 클러스터 모드에서 작업하려면 관계형 데이터베이스의 데이터 일관성이 필요하며 두 데이터베이스 클러스터 노드는 데이터 센터 간에 동기식으로 복제됩니다.

분산 캐시(Infinspan)

클러스터가 올바르게 작동하려면 JBoss Data Grid를 사용하여 다음 유형의 캐시에 대한 추가 동기화가 필요합니다.

인증 세션 - 특정 사용자를 인증할 때 데이터를 저장하는 데 사용됩니다. 이 캐시의 요청에는 일반적으로 애플리케이션이 아닌 브라우저와 Keycloak 서버만 포함됩니다.

작업 토큰은 사용자가 비동기적으로(이메일을 통해) 작업을 확인해야 하는 시나리오에 사용됩니다. 예를 들어 비밀번호 분실 흐름 중에 actionTokens Infinispan 캐시는 이미 사용된 연결된 작업 토큰에 대한 메타데이터를 추적하는 데 사용되므로 재사용할 수 없습니다.

영구 데이터의 캐싱 및 무효화 - 데이터베이스에 대한 불필요한 쿼리를 방지하기 위해 영구 데이터를 캐시하는 데 사용됩니다. Keycloak 서버가 데이터를 업데이트하면 모든 데이터 센터의 다른 모든 Keycloak 서버가 이에 대해 알아야 합니다.

작업 - 클러스터 노드와 데이터 센터 간에 유효하지 않은 메시지를 보내는 데만 사용됩니다.

사용자 세션 - 사용자의 브라우저 세션 기간 동안 유효한 사용자 세션에 대한 데이터를 저장하는 데 사용됩니다. 캐시는 최종 사용자와 애플리케이션의 HTTP 요청을 처리해야 합니다.

무차별 대입 보호 - 실패한 로그인에 대한 데이터를 추적하는 데 사용됩니다.

부하 분산

로드 밸런서는 keycloak에 대한 단일 진입점이며 고정 세션을 지원해야 합니다.

애플리케이션 서버

구성 요소 간의 상호 작용을 제어하는 ​​데 사용되며 기존 자동화 도구 및 인프라 자동화 도구의 동적 확장을 사용하여 가상화하거나 컨테이너화할 수 있습니다. OpenShift, Kubernates, Rancher에서 가장 일반적인 배포 시나리오.

이것으로 첫 번째 부분인 이론적 부분을 마칩니다. 다음 기사 시리즈에서는 다양한 ID 공급자와의 통합 예 및 설정 예를 분석합니다.

출처 : habr.com