2.0.2의 관리 권한 부여는 canonical permission path + action code를 사용합니다. canonical path는 안정적인 권한 부여 리소스 식별자이며 Admin UI route나 HTTP mount path가 아닙니다. 예를 들어 /runtime/db-management와 /auth/role은 내비게이션이나 controller URL 구성이 달라져도 같은 권한 ID를 뜻합니다.
같은 canonical identifier는 서로 배타적인 두 관리 권한 부여 모드에서 사용됩니다. 내장 identity를 사용하면 HsSqlAgent member / role이 permission/action template을 해석합니다. host authorization을 사용하면 HsSqlAgent가 요청된 canonical permission key를 HsSqlAgentPermissionResource.Permissions로 호스트에 전달하고, 호스트 애플리케이션이 이를 자체 policy model에 매핑합니다. 별도 설명이 없으면 아래 role / template 내용은 내장 identity 모드를 기준으로 합니다.
런타임 예시
| 보호 작업 | 필요한 pair |
|---|---|
| Database Management 조회 | /runtime/db-management → view |
| Database Management 항목 생성 | /runtime/db-management → create |
| semantic metadata 수정 | /runtime/db-management/semantic → edit |
| MCP 키 발급/관리 | /runtime/mcp-keys + 해당 action |
| 사용자 조회 | /auth/user → view |
| 역할 수정 | /auth/role → edit |
| 감사 조회 | /runtime/audit → view |
| 감사 export | /runtime/audit → export |
| 보안 정책 수정 | /runtime/security → edit |
| 외부 전송 재시도 | /runtime/operability → edit |
따라서 인증만으로는 충분하지 않습니다. 필요한 path/action pair가 사용자의 역할을 통해 해석되어야 합니다.
Permission-action template이 기준입니다
Role API는 permission-action-templates inventory를 제공합니다. 각 template에는 다음이 들어 있습니다.
- permission ID, name, path
- action ID, code, name
Role payload는 { PermissionId, ActionId } pair를 제출합니다. Role service는 중복을 정규화하고 template inventory에 존재하는 pair만 저장합니다.
역할이 할당 단위입니다
멤버는 역할을 할당받고, 역할에는 permission/action selection이 들어갑니다. 이 구조는 사용자 수명 주기와 재사용 가능한 접근 정책을 분리합니다.
Member
└─ Role(s)
└─ Permission path + Action한 멤버가 여러 역할을 가질 수 있으며, 실제 Admin 접근 권한은 할당된 역할들의 permission surface를 합친 결과입니다.
Authorization 변경은 오래된 상태를 무효화합니다
역할 수정은 보안에 민감한 작업입니다. 역할의 permission이 변경되면 role service는 영향받는 멤버를 찾고 security version을 증가시키며 auth runtime-state cache barrier를 통해 변경을 수행합니다.
이는 이미 인증된 세션이 변경 전 authorization을 계속 사용하는 문제를 막기 위한 설계입니다.
보호된 SuperUser 역할
SuperUser는 2.0.2의 내장 보호 역할입니다. 일반 역할 관리로 수정하거나 삭제할 수 없습니다. Bootstrap/full-control 역할이 다른 permission set으로 조용히 재정의되는 것을 막습니다.