인증 및 권한 부여는 항상 좋은 주제입니다
현재 진행중인 현재 다중 테넌트 서비스에서 권한 부여를 처리하는 방법을 설명하려고합니다. 인증 및 권한 부여는 JSON 웹 토큰 공개 표준을 사용하는 토큰 기반입니다. 이 서비스는 모든 종류의 클라이언트 (웹, 모바일 및 데스크톱 애플리케이션)가 액세스 할 수있는 REST API를 제공합니다. 사용자가 성공적으로 인증되면 서비스는 각 요청에서 서버로 전송해야하는 액세스 토큰을 제공합니다.
서버 응용 프로그램에서 데이터를 인식하고 처리하는 방법에 따라 사용하는 몇 가지 개념을 소개하겠습니다.
리소스 : 클라이언트가 서비스를 통해 액세스 할 수있는 모든 단위 또는 데이터 그룹입니다. 제어하려는 모든 리소스에 단일 이름을 할당합니다. 예를 들어, 다음 엔드 포인트 규칙이 있으면 다음과 같이 이름을 지정할 수 있습니다.
product
/products
/products/:id
payment
/payments/
/payments/:id
order
/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id
지금까지 서비스에 3 가지 리소스 가 있다고 가정 해 봅시다 . product, payment및 order.
조치 : 읽기, 작성, 업데이트, 삭제 등과 같은 자원에서 수행 할 수있는 조작입니다. 클래식 CRUD 조작 일 필요는 없습니다. follow예를 들어, WebSocket을 사용하여 어떤 종류의 정보를 전파하는 서비스를 공개하려고합니다.
능력 : 수행 할 수있는 능력 action켜짐 resource. 예를 들어; 제품 읽기, 제품 만들기 등 기본적으로 리소스 / 액션 쌍입니다. 그러나 이름과 설명도 추가 할 수 있습니다.
역할 : 사용자가 소유 할 수있는 능력. 예를 들어, 역할에 Cashier"지불 읽기", "지불 작성"기능이 있거나 역할에 Seller"제품 읽기", "주문 읽기", "업데이트 주문", "주문 삭제"기능이있을 수 있습니다.
마지막으로 사용자는 자신에게 다양한 역할을 할당 할 수 있습니다.
설명
앞에서 말했듯이 JSON 웹 토큰을 사용하며 사용자가 보유한 기능은 토큰의 페이로드에 선언됩니다. 따라서 소규모 소매점에서 출납원과 판매자 역할을 동시에 수행하는 사용자가 있다고 가정하십시오. 페이로드는 다음과 같습니다.
{
"scopes": {
"payment": ["read", "create"],
"order": ["read", "create", "update", "delete"]
}
}
scopes클레임 에서 볼 수 있듯이 역할 (직원, 판매자)의 이름을 지정하지 않고 관련 리소스와 작업 만 지정합니다. 클라이언트가 엔드 포인트에 요청을 보낼 때 서비스는 액세스 토큰에 필요한 자원 및 조치가 포함되어 있는지 확인해야합니다. 예를 들어, GET엔드 포인트에 대한 요청 /payments/88은 성공하지만 DELETE동일한 엔드 포인트에 대한 요청은 실패해야합니다.
물론, 토큰을 발행 한 사용자 및 고객 (테넌트)을 식별하기 위해 페이로드에 추가 특성을 추가해야합니다.
{
"scopes": {
...
},
"tenant": "acme",
"user":"coyote"
}
이 방법을 사용하면 서비스에 대한 모든 사용자 계정 액세스를 미세 조정할 수 있습니다. 그리고 가장 중요한 것은 질문에서 지적한대로 관리자, 에이전트 및 최종 사용자와 같은 다양한 사전 정의 된 정적 역할을 만들 필요가 없습니다 . 슈퍼 사용자는 소유 사용자가 될 것입니다 role모든과 resources와 actions할당 된 서비스를.
이제 100 개의 리소스가 있고 모든 리소스 또는 거의 모든 리소스에 액세스 할 수있는 역할을 원한다면 어떻게해야합니까? 우리의 토큰 페이로드는 엄청납니다. 이는 리소스를 중첩하고 액세스 토큰 범위에 상위 리소스를 추가함으로써 해결됩니다.
권한 부여는 각 응용 프로그램의 요구에 따라 해결해야하는 복잡한 주제입니다.
payment:[read]판매자가payment: [create]있습니다. 이 경우 사용 권한을 집계합니까?