예비 지식
이 문서에서는 마이크로서비스 아키텍처를 기반으로 한 신원 인증 및 사용자 권한 부여를 위한 기술 솔루션에 대해 설명합니다. 다음 지식 사항을 숙지하고 이해하는 것이 가장 좋습니다.
- 마이크로서비스 아키텍처 관련 개념: 서비스 등록, 서비스 검색, API 게이트웨이
- 신원 인증 및 권한 부여 기술: SSO, CAS, OAuth2.0, JWT
다음과 같은 기본 개념:
- 인증
- 승인하다
- 입증
- 권한 제어
전제조건 배경
기업용 애플리케이션 시스템의 수가 점차 증가함에 따라 각 시스템은 자체 사용자 데이터를 독립적으로 관리하고 쉽게 정보의 섬이 되고 있으며, 분산형 사용자 관리 모델은 기업용 애플리케이션이 플랫폼으로 진화하는 것을 방해합니다. 기업의 인터넷 비즈니스가 어느 정도 규모로 발전하면 통일되고 표준화된 계정 관리 시스템을 구축하는 것이 필수적입니다. 왜냐하면 이는 기업 인터넷 클라우드 플랫폼의 중요한 인프라이고 통일된 계정 관리, 신원 인증, 사용자 관리를 가져올 수 있기 때문입니다. 인증과 같은 기본 기능은 시스템 간 Single Sign-On 및 제3자 인증 로그인과 같은 기본 기능을 기업에 제공하여 개방형 플랫폼 및 비즈니스 생태계 구축에 필요한 조건을 제공합니다.
모드 소개
마이크로서비스 아키텍처 하에서 기업의 플랫폼 생태계는 합리적으로 비즈니스로 분할되어야 하며, 각 비즈니스 부문은 자체 시스템을 형성해야 합니다. 이러한 시스템 비즈니스는 상대적으로 독립적이므로 독립적으로 분할되어야 합니다. 각 시스템은 자체 비즈니스 모델에 따라 세분화될 수 있으며, 비즈니스 모델과 사용자 요구 사항을 종합적으로 분석하여 독립적인 서비스를 형성한 후 적절한 도메인 모델을 구축할 수 있습니다.
또한 엔터프라이즈 플랫폼의 고객 범위는 2B 비즈니스, 2C 비즈니스, 2G(거버넌스) 등 상대적으로 복잡하므로 플랫폼 수준의 통합 ID 관리에는 조직 주체와 개인 주체가 포함되어야 합니다. 조직 주체에는 대행사(G)가 포함됩니다. ), 기업 단위(B), 그룹 조직(B) 등. 이는 다중 테넌트 아키텍처의 개념과 유사하지만 기존 다중 테넌트 아키텍처보다 더 복잡합니다.
마이크로서비스 아키텍처의 로그인 인증 문제
과거의 모놀리식 애플리케이션 아키텍처부터 분산 애플리케이션 아키텍처, 현재의 마이크로서비스 아키텍처에 이르기까지 애플리케이션 보안 액세스는 지속적으로 테스트되고 있습니다. 아키텍처와 요구 사항의 변화에 적응하기 위해 신원 인증 및 인증 솔루션은 지속적으로 업데이트되고 개편되고 있습니다. 수십 또는 수백 개의 마이크로서비스 간의 호출이 발생할 때 효율적이고 안전한 신원 인증을 보장하는 방법은 무엇입니까? 외부 서비스 접근을 위한 세분화된 인증 솔루션을 제공하는 방법은 무엇입니까? 이 문서에서는 마이크로서비스 아키텍처의 보안 인증 및 인증 체계에 대해 설명합니다.
통합 ID 관리자
UIM(Unified Identity Management)은 전체 플랫폼에 대한 계정 및 권한 제어의 기반이며, 이를 기반으로 구축된 시스템을 UIMS(Unified Identity Management System)라고 합니다. 계정 관리, 신원 인증, 사용자 권한 부여, 권한 제어 및 기타 모든 동작 플랫폼 하의 시스템은 UIMS 처리를 통해 계정 비밀번호 관리, 기본 데이터 관리, 역할 권한 관리 등의 기능을 제공합니다.
UIMS는 "통합 ID 거버넌스" 개념을 기반으로 하며 2단계 계정 시스템, 기본 권한 모듈 및 기본 정보 모듈의 세 가지 주요 모듈로 나눌 수 있습니다. 그 중 2단계 계정 시스템은 계정을 조직 엔터티 계정과 개인 엔터티 계정의 두 가지 범주로 구분하는데, 개인 엔터티는 조직 엔터티에 종속되거나 어떤 조직 엔터티에도 종속되지 않을 수 있으며, 개인 엔터티는 여러 조직에 종속될 수 있습니다. 조직 개체를 동시에 기본 권한 모듈 각 비즈니스 시스템의 리소스 권한에 대한 관리 및 승인을 일원화합니다.
기본정보 모듈은 조직개체의 이름, 주소, 법인, 이름, 전화번호, 성별, 기타 기본정보 등 조직개체 및 개별개체의 기본정보를 기술하는 데 사용됩니다. UIMS는 다양한 하위 시스템과 연결하기 위한 통합 API를 제공합니다. 많은 시스템과 많은 서비스가 UIMS에 의존하게 될 것입니다.
본 글에서는 UIMS의 2단계 계정 시스템과 기본 권한 모듈의 두 가지 모듈만을 다루며, 이를 기반으로 계정 관리 서비스와 권한 관리 서비스를 독립적으로 제공할 수도 있고, 하나의 계정 권한 관리로 통합할 수도 있다. 서비스. 계정 관리 서비스에는 비즈니스 시스템 개체, 조직 개체 및 개인 개체 관리가 포함되며 권한 관리 서비스에는 인증, 권한 부여 및 인증의 세 부분이 포함됩니다.
싱글 사인온(SSO)
엔터프라이즈 플랫폼에는 많은 하위 시스템이 포함되어 있으며, 각 하위 시스템의 사용자 관리를 단순화하고 사용자 경험을 향상시키기 위해 SSO를 실현하는 것은 통합 ID 인증(1회 로그인, 모든 액세스)의 중요한 목표입니다.
- 내부 엔터프라이즈 애플리케이션의 경우 SSO는 엔터프라이즈 OA, HR, CRM 및 기타 내부 시스템과 같은 필수 옵션입니다.
- 외부 애플리케이션의 경우 SSO는 선택 사항이며 SSO 시스템에 어떤 애플리케이션을 추가해야 하는지는 비즈니스 시스템에 따라 결정됩니다.
예를 들어 외부 쇼핑몰, 부동산 시스템 등의 외부 서비스 시스템이 있습니다. 애플리케이션이 SSO를 사용하는지 여부에 관계없이 UIMS에는 기술적으로 SSO 기능이 있어야 합니다.
승인된 로그인
플랫폼 비즈니스가 점진적으로 성장함에 따라 플랫폼에 의존하는 제조사, 고객 등의 자원이 플랫폼을 크게 풍요롭게 하므로, 비즈니스의 추가적인 발전을 지원하기 위한 개방형 생태계가 구축되어야 합니다. 플랫폼 수준 인증 로그인 기능을 열어 타사 애플리케이션 접근을 허용할 수 있습니다. 제3자 인증 로그인을 통해 플랫폼의 서비스 기능을 제3자에게 전개할 수 있으며, 제3자 서비스 및 기능을 플랫폼에 연결하여 번영, 공생, 공동 발전을 도모할 수 있습니다.
서비스 간 인증
비즈니스 시스템은 다양한 서비스로 나누어져 있으며, 다양한 세부성과 비즈니스 요구 사항에 따라 서비스 수와 권한 요구 사항도 다릅니다. 마이크로서비스 아키텍처에서의 신원 인증 및 권한 부여는 두 가지 유형으로 나눌 수 있습니다.
- 내부 서비스의 인증 및 승인
- 내부 서비스는 BFF(Backend For Frontend Layer) 계층의 제품 서비스, 주문 서비스 등 안전한 인트라넷 환경에 있으며 보안 요구 사항이 높지 않은 경우 인증 과정을 수행할 필요가 없으며 서비스는 상호 배타적입니다. 신뢰하다.
- 외부 서비스에 대한 인증 및 승인.
- 외부 서비스의 인증 및 권한 부여는 일반적으로 역방향 프록시 또는 게이트웨이를 통해 보안 경계 내의 서비스에 대한 요청을 시작하는 외부 애플리케이션에 의해 시작되므로 엄격한 인증 프로세스를 구현해야 합니다. 무선 APP, 웹 클라이언트, 데스크톱 클라이언트 등 외부 애플리케이션의 다양한 서비스는 모두 외부 서비스입니다.
기술 솔루션
옵션
UIMS(Unified Identity Management System)에 따른 신원 인증 및 권한 부여에 대한 주요 요구 사항이 제시되어 있으며, 현재 통합 신원 인증 및 권한 부여를 달성하기 위한 많은 기술적 수단이 있으며 이는 다음 두 가지 범주로 요약될 수 있습니다.
- 기존 쿠키 + 세션 솔루션, 상태 저장 세션 모드;
- 토큰/티켓 기반 솔루션, 무상태 상호작용 모드.
구체적으로:
- 분산 세션
- OAuth2.0
- 카스
위의 각 옵션에는 장단점이 있습니다.
분산 세션
Distributed Session은 오래되고 성숙한 솔루션이지만 Stateful 통신 특성과 마이크로서비스가 옹호하는 API 중심의 Stateless 통신으로 인해 서로 충돌하고 공유 스토리지에는 보안 위험이 있으므로 마이크로서비스는 일반적으로 사용되지 않습니다.
분산 세션
OAuth2.0은 업계에서 성숙한 인증 로그인 솔루션이지만 OAuth2.0은 다양한 시나리오에 적응할 수 있는 4가지 인증 모드를 제공합니다. 토큰 기반 보안 프레임워크로서 통합이 필요한 시나리오에서 널리 사용할 수 있습니다. 신원 인증 및 권한 부여.
JWT는 일반적으로 토큰의 주요 표준으로 사용됩니다. JWT(JSON Web Token)는 분산형 저장 및 자체 복호화 특성으로 인해 비중앙화 인증/권한 부여 시나리오에서 널리 사용되는 간결한 자체 포함 JSON 선언 사양입니다.
JWT 정보는 서명되므로 보낸 사람의 진위를 보장하고 정보가 변조되거나 위조되지 않았는지 확인할 수 있습니다. 그러나 클라이언트측 서명 검증 기능이 자체적으로 구현되어 한번 발행된 토큰은 취소가 불가능하므로 단순히 JWT를 통합 신원 인증 및 승인 솔루션으로 사용하는 것만으로는 통합 계정 로그아웃 및 파기 요구 사항을 충족할 수 없습니다. 계정 금지 및 해제 요구 사항이므로 일반적으로 OAuth2.0과 함께 사용됩니다.
JWT 도입과 관련하여 CAS는 CAS 서버 및 CAS 클라이언트를 포함하여 현재 가장 성숙한 오픈 소스 싱글 사인온 솔루션입니다.
- CAS 서버는 독립적으로 배포되어야 하며 사용자 인증을 담당하는 war 패키지입니다.
- CAS 클라이언트는 클라이언트의 보호되는 리소스에 대한 액세스 요청을 처리하고 인증이 필요할 때 이를 CAS 서버로 리디렉션합니다.
CAS는 유연하고 완전한 인증 프로세스를 정의하는 인증 프레임워크이지만 OAuth2, SAML, OpenID 등과 같은 주류 인증 및 권한 부여 프로토콜과 호환되므로 일반적으로 CAS + OAuth2 솔루션이 사용됩니다. SSO 및 인증된 로그인을 구현합니다.
CAS에 대한 소개는 apereo.github.io/cas/를 참조하세요 . 마이크로서비스 아키텍처에서는 ID 인증과 사용자 인증이 일반적으로 독립적인 IDP(Identity Provider) 서비스로 분리됩니다. 기술을 선택할 때 다음 사항을 고려해야 합니다.
- SSO의 기술적 요구 사항을 충족합니다.
- 단순성과 보안에 대한 요구 사항을 충족합니다.
- 개방성과 확장성에 대한 요구 사항을 충족합니다.
- 종합적으로 고려한 후 Stateless API 모드를 채택하는 것이 좋습니다. 그 중 OAuth2.0 기반 솔루션은 완전히 만족할 수 있습니다.
클라이언트 토큰 솔루션
토큰은 클라이언트 측에서 생성되고 인증 서비스에 의해 서명되며 모든 마이크로서비스에서 사용자의 ID를 설정할 수 있도록 충분한 정보를 포함해야 합니다. 토큰은 모든 요청에 첨부되어 마이크로 서비스에 대한 사용자 인증을 제공합니다. 이 솔루션의 보안은 비교적 좋지만 인증 로그아웃이 큰 문제입니다. 이를 완화하는 방법은 수명이 짧은 토큰을 사용하고 인증 서비스를 자주 확인하는 등이 있습니다. . 클라이언트 토큰의 인코딩 체계를 위해 Borsos는 충분히 간단하고 상대적으로 우수한 라이브러리 지원을 제공하는 JWT(JSON 웹 토큰)를 사용하는 것을 선호합니다.
클라이언트 토큰과 API 게이트웨이의 조합
이 체계는 모든 요청이 게이트웨이를 통과하여 마이크로서비스를 효과적으로 숨긴다는 것을 의미합니다. 요청 시 게이트웨이는 원시 사용자 토큰을 내부 세션 ID 토큰으로 변환합니다. 이 경우 로그아웃 시 게이트웨이가 사용자의 토큰을 취소할 수 있으므로 로그아웃은 문제가 되지 않습니다.
