위에 정의한 각 프로토콜들의 엔드포인트는 서비스 브로커의 call
, publish
, subscribe
커넥터를 호출합니다. 이 때 호출되는 각 커넥터들에 대해서 접근 제어 정책을 정의 할 수 있습니다.
접근 제어 정책은 먼저 호출하는 커넥터에 따라서 action
이나 event
의 이름으로 필터링됩니다. 연관된 정책들은 순서대로 모두 적용됩니다. 모든 정책을 통과하는 경우에 해당 커넥터가 호출될 수 있습니다.
접근 제어 정책을 평가하는 방식은 플러그인 형태로 제공됩니다. 기본적으로 OAuth scope 방식(scopes
)과 Inline JavaScript Function String를 활용한 FBAC 방식(filter
) 두가지가 제공됩니다.
Caching: TODO
또한 접근 제어 정책의 평가는 Gateway의 메모리에 LRU 방식으로 캐시되며 한 요청에서 중복 수행되지 않습니다. 캐시 키를 생성 할 때 요청을 정확히 구분하기 위해서 컨텍스트(인증 정보) 및 호출 페이로드 등의 정보가 반영됩니다.
Scopes
위 정책은 player.**
패턴(player.get
, player.list
, player.message.list
등과 일치)의 액션을 호출하는 call
커넥터가 사용되는 모든 엔드포인트가 수행되기 전에 공통적으로 평가됩니다. 우선 scopes
접근 제어 플러그인에 따라 context
에 주입된 (moleculer-iam
같은 컨텍스트 플러그인을 통해) OAuth 토큰이 획득한 스코프를 확인하고 일치되는 스코프가 하나라도 있는 경우 통과합니다.
Filter
다음으로 filter
접근 제어 플러그인에 따라 action
|event
, params
, context
, util
을 주입하여 함수를 실행하며, true
값이 반환되는 경우 통과합니다. FBAC은 ACL이나 RBAC처럼 대중화되지는 않았으나, ABAC의 확장 모델로 이해할 수 있습니다. 매우 유연하여 분산 환경에 적합하며 프로덕션에서 검증된 방식입니다.
filter
접근제어 플러그인 역시 map
커넥터처럼 Gateway의 Node.js VM 샌드박스에서 실행됩니다. filter
함수를 평가하는 중에 에러가 발생하는 경우 디버그 메시지가 Gateway에서 출처 노드로 전달되며 접근이 거부됩니다.
위처럼 player
서비스의 API 스키마는 꼭 player
서비스의 액션만 호출하지 않습니다. 따라서 player
API에서 노출하는 team
서비스의 액션에 대한 접근 제어 역시 player
스키마에서 정의하게 됩니다.
publish
, subscribe
커넥터의 정책에는 actions
대신 events
필드가 작성됩니다.
위처럼 filter
가 생략된 경우 scopes
만 적용되며 filter
는 통과한 것처럼 평가됩니다.
접근제어 플러그인을 비활성화하는 것은 위 정책을 작성하는 것과 동일합니다.
디버깅 중에 Inline JavaScript Function String에서 console
객체를 사용해 메세지를 출력하는 경우, 그 메세지는 Gateway의 VM 안에서 출력되지 않고 Gateway가 출처 노드로 전달합니다.