배경
전통적인 모 놀리 식 애플리케이션에서 스프링 클라우드로 전환 한 친구들은 Spring Cloud 에서 마이크로 서비스 권한을 관리하는 방법을 묻습니다. 더 합리적으로 디자인하는 방법? 큰 관점에서,이를 서비스 권한이라고하며, 이는用户认证,用户权限및服务校验세 부분으로 나뉩니다.
사용자 인증
전통적인 모 놀리 식 응용은 세션의 존재에 익숙 할 수 있습니다. Spring Cloud의 마이크로 서비스 후, 분산 세션으로 세션을 해결할 수 있지만 결국 최상의 전략은 아닙니다. 어떤 사람들은 OAuth2 와 잘 어울리는 스프링 클라우드 보안을 구현하기 시작했습니다. 나중에 OAUTH 2에서 Access Token 의 저장 문제를 최적화하고 백엔드 서비스의 가용성 및 확장 성을 향상시키기 위해 더 나은 토큰 검증 방법 JWT (JSON Web Token)가 있습니다. 여기서 강조해야 할 한 가지는 OAuth2 와 JWT 전혀 비교할 수 없으며 완전히 다른 두 가지라는 것입니다.
OAuth2是一种授权框架이며 JWT 인증 프로토콜입니다.
OAUTH2 인증 프레임 워크 OAUTH2는 네 가지 역할을 포함합니다.
OAUTH2에는 4 개의 승인 모드가 포함되어 있습니다
그중에서도 OAUTH2의 작동 과정은 아래 그림에 나와 있으며 RFC 6749에서 발췌.
+--------++--------------------------- | |-(a)-승인 요청-> | 자원 || | | | | 소유자 || | <-(b)-승인 보조금 --- | || | +-----------------------+| || | +--------------------+| |-(c)-승인 보조금-> | 승인 || 클라이언트 | | | 서버 || |<-(D)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----->| 자원 || | | 서버 || <-(f) --- 보호 자원 --- | |+--------+ +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Spring Cloud Oauth2에서는 마이크로 서비스 리소스에 액세스하는 모든 요청이 HTTP 헤더에 토큰을 전달합니다. 그런 다음 액세스 서비스는 권한 부여 서버에 토큰의 유효성을 확인하도록 요청합니다. 이런 식으로两次或者更多次요청이 필요합니다. 모든 토큰 유효성 검증은 인증 서버에 속하며, 이는 시스템의 수평 확장에 매우 큰 병목 현상이되었습니다.
JWT 인증 프로토콜
授权服务器사용자 정보 및 인증 범위를 연속화하고 JSON 문자열을 넣은 다음 Base64를 사용하여 인코딩 한 다음 마지막으로 인증 서버의 개인 키로 문자열에 서명하여 JSON Web Token 얻습니다.
다른 모든 리소스 서버에 RSA 공개 키가 있다고 가정합니다. 리소스 서버가 HTTP 헤더에 토큰이있는 요청을 수신 할 때 리소스 서버는 토큰을 가져 와서 올바른 개인 키 서명을 사용하는지 확인할 수 있습니다 (승인 된 서버, 즉 서명 확인). 확인을 전달한 후, Toekn에 포함 된 유효한 검증 정보는 사막화 후에 얻을 것입니다.
그중에서도 주요 작동 흐름도는 다음과 같습니다.
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
위의 방법을 통해 서비스 기반 사용자 인증을 잘 완료 할 수 있습니다.
사용자 권한
모든 사람은 전통적인 단일 바디 응용 프로그램의 허가 차단을 위해 shiro 좋아하며 사용하기가 매우 쉽습니다. 그러나 일단 분할되면, 권한은 다양한 API에 흩어지기 시작합니다. shiro 여전히 일하고 있습니까? 이 프로젝트에서 나는 shiro 사용하지 않았다. 전면 및 후면이 분리 된 후, 상호 작용은 토큰이며, 백엔드 서비스는 무국적이며, 프론트 엔드 버튼은 자원이며 권한을 어디에서 관리 할 수 있습니까?
초록과 디자인
Flexible Core Design을 도입하기 전에 RBAC (역할 기반 액세스 제어, 역할 기반 액세스 제어)에게 초보자 개념을 소개하겠습니다. 이는 사용자가 역할을 통해 권한과 관련이 있음을 의미합니다. 간단히 말해서, 사용자는 몇 가지 역할을 가지고 있으며 각 역할에는 몇 가지 권한이 있습니다.
RBAC는 실제로 기본 모델 RBAC0 (Core RBAC), 역할 계층 모델 RBAC1 (Hierarchal RBAC), 역할 제한 모델 RBAC2 (구속 조건 RBAC) 및 통합 모델 RBAC3 (RBAC 결합)으로 나뉘어져 있습니다.
핵심 UML
여러 비즈니스 시나리오 이후의 저자의 추상 RBAC 관계 다이어그램입니다.
수업 설명
그룹
특정 수의 권한이있는 컬렉션 인 그룹 또는 그룹은 또한 권한의 운송 업체가 될 수 있습니다.
子类: 사용자 (사용자), 역할 (역할), 위치 (Post), Unit (Department). 사용자의 특정 구성을 통해 다른 비즈니스 시나리오의 그룹 또는 그룹이 형성되며, 그룹 또는 그룹의 상위 클래스에 대한 승인을 통해 사용자의 권한이 얻어집니다.
허가
권한, 특정 수의 리소스와의 통합은 자원의 운송 업체가 될 수 있습니다.
자원
권한 아래에 리소스가 있으며 리소스 소스에는 메뉴 (메뉴), 버튼 (조치 권한), 페이지 요소 (버튼, 탭 등), 데이터 권한 등이 있습니다.
프로그램
관련 권한 제어를위한 렌더링 캐리어 인 프로그램은 여러 메뉴에 장착 할 수 있습니다.
일반적인 웹 프로그램의 기본 구성
모델과 마이크로 서비스의 관계
스프링 클라우드 서비스 이후의 모든 API 인터페이스가 위의 Resources 로 정의되면 그러한 상황을 볼 수 있습니다.
예를 들어, 사용자가 추가, 삭제, 수정 및 확인하면 페이지가이를 수행합니다.
| 페이지 요소 | 리소스 인코딩 | 자원 URI | 리소스 요청 방법 |
|---|---|---|---|
| 질문 | user_btn_get | /api/user/{id} | 얻다 |
| 증가하다 | user_btn_add | /API/사용자 | 우편 |
| 편집하다 | user_btn_edit | /api/user/{id} | 놓다 |
| 삭제 | user_btn_del | /api/user/{id} | 삭제 |
위의 매핑 관계를 추상화 한 후 프론트 엔드 및 백엔드 리소스를 참조하여 사용자 그룹 권한을 더 쉽게 승인 할 수 있습니다. 예를 들어, 추가 및 삭제할 수있는 사용자 권한을 부여합니다.前端에서는资源编码존재하는지 여부를 확인하면 단추의 디스플레이를 제어하고 버튼을 숨기지 않아도되면后端에서는 사용자가 URI 및 해당请求方式가지고 있는지 균일하게 차단하고 결정하면됩니다.
통합 권한 차단이 Zuul 게이트웨이에 배치되는지 또는 특정 백엔드 서비스 (필터, Inteceptor)의 인터셉터에 배치되는지 여부는 쉽게 구현할 수 있습니다. 코드의 침습성에만 국한되지 않습니다. Zuul을 배치하는 흐름도는 다음과 같습니다.
Zuul 에 통일 된 권한 차단이 배치되면, 백엔드 서비스가 안전하고 서비스는 등록 센터를 통해서만 호출되면 문제가 있습니다. 여기에는 세 번째 모듈, 서비스 간 인증이 포함됩니다.
서비스 간 인증
우리는 모두 등록 센터를 통해 고객을 찾은 후에 서비스가 원격으로 직접 호출된다는 것을 알고 있기 때문입니다. 생산에서 각 서비스와 민감한 인터페이스를 보호해야합니다. 주제의 과정은 다음과 같습니다.
저자의 구현 방법은 Spring Cloud의 FeignClient Inteceprot (자동으로 서비스 토큰에 자동으로 적용, 현재 컨텍스트를 전달) 및 Mvc Inteceptor (서비스 토큰 확인, 현재 컨텍스트 업데이트)를 기반으로하여 서비스의 보안을 더욱 보호합니다.
스프링 클라우드의 기능을 결합한 후 전체 흐름도는 다음과 같습니다.
최적화 지점
API 인터페이스의 보안은 위에서 언급 한 사용자 합법성 검증, 사용자 권한 차단 및 서비스 간 인증을 통해 보장되지만 Http访问频率비교적 높습니다. 요청 횟수가 증가하면慢는 문제가 특히 분명합니다. 사용자 권한 캐시, 배포 및 서비스 승인 정보의 혼합 저장 및 서비스 인증 토큰의 정기적 인 새로 고침과 같은 특정 최적화 전략을 고려할 수 있습니다.
결론
위는 프로젝트에서 나의 일반적인 아이디어입니다. 관심있는 친구들은 오픈 소스 프로젝트에서 배울 수 있습니다. 스타에 오신 것을 환영합니다 :
-Gitchina : https://gitee.com/minull/ace-security (JWT, 사용자 권한)
-github : https://github.com/wxiaoqi/ace-security
-Gitchina : http://git.oschina.net/geek_qi/ace-gate (서비스 인증)
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.