개념
사용자가 Backstage 안에서 수행하는 모든 액션은 권한(permission)으로 나타낼 수 있어요. 소프트웨어 템플릿 실행 같은 더 복잡한 액션은 흐름 전반에 걸쳐 여러 권한에 대한 인가를 요구할 수 있어요. 권한은 고유한 이름으로 식별되며, 필요에 따라 해당 액션을 설명하는 일련의 속성을 포함할 수 있어요. 플러그인은 자신이 시행하는 권한을 정의·노출하고 권한 프레임워크의 제한을 시행할 책임이 있어요.
출처: 문서
본문
권한 (Permission)
사용자가 Backstage 안에서 수행하는 모든 액션은 권한으로 나타낼 수 있어요. 소프트웨어 템플릿 실행 같은 더 복잡한 액션은 흐름 전반에 걸쳐 여러 권한에 대한 인가를 요구할 수 있어요. 권한은 고유한 이름으로 식별되며, 필요에 따라 해당 액션을 설명하는 일련의 속성을 포함할 수 있어요. 플러그인은 자신이 시행하는 권한을 정의·노출하고 권한 프레임워크의 제한을 시행할 책임이 있어요.
정책 (Policy)
사용자 권한은 중앙의 사용자 정의 권한 정책에 의해 인가돼요. 높은 수준에서 정책은 Backstage 사용자와 권한을 받아 허용 또는 거부 결정을 반환하는 함수예요. 정책은 코드로 표현되며, 이는 프레임워크를 역할 기반 접근 제어(RBAC)나 속성 기반 접근 제어(ABAC) 같은 특정 인가 모델에서 분리해요.
정책 결정과 시행
어떤 인가 시스템이든 두 가지 중요한 책임은 사용자가 무언가를 할 수 있는지 결정하는 것과 그 결정을 시행하는 것이에요. Backstage 권한 프레임워크에서 정책은 결정을 담당하고, 플러그인(보통 백엔드)은 그것을 시행할 책임이 있어요.
리소스와 규칙
많은 경우 권한은 사용자가 다른 객체와 상호작용하는 것을 나타내요. 이 객체에는 정책 작성자가 더 세분화된 접근을 정의하는 데 사용할 수 있는 정보가 있을 가능성이 높아요. 권한 프레임워크는 이를 설명하기 위해 리소스(resource)와 규칙(rule)이라는 두 가지 추상화를 도입해요. 예를 들어 catalog 플러그인은 카탈로그 엔티티에 대한 리소스와 엔티티가 주어진 어노테이션을 갖는지 확인하는 규칙을 정의해요.
조건부 결정 (Conditional decisions)
규칙은 결정에 사용되기 전에 추가 데이터가 필요해요. 규칙이 관련 정보에 바인딩되면 조건(condition)을 형성해요. 조건부 결정은 권한 프레임워크가 해당 리소스를 소유한 플러그인에 평가를 위임하도록 지시해요. 조건부 결정으로 이어지는 권한 요청은 제공된 모든 조건이 참으로 평가되면 허용돼요.
좋은 예는 catalog 플러그인의 "has annotation" 규칙으로, 주어진 엔티티에서 어떤 어노테이션을 찾아야 하는지 알아야 해요. 이 경우 권한 프레임워크는 catalog 플러그인의 요청에 조건 결정으로 응답해요. 그러면 catalog 플러그인은 "has annotations" 조건과 일치하는 엔티티를 올바르게 필터링해야 해요. 이 조건부 동작은 정책과 리소스 스키마 사이의 결합을 피하고, 플러그인이 복잡한 규칙을 효율적으로 평가할 수 있게 해줘요. 예를 들어 플러그인은 조건부 결정을 메모리에서 객체를 로드하고 필터링하는 대신 데이터베이스 쿼리로 변환할 수 있어요.