Consolidate data access control backoffice updates
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
# 사용자 페이지 리뷰
|
||||
|
||||
- URL: `/users`
|
||||
- 현재 목적: 백오피스 권한 모델의 사용자 생성, 목록 확인, 사용자 역할 부여를 수행한다.
|
||||
- VPD/ASO 관련성: 사용자는 VPD 필터가 읽는 역할·권한의 출발점이며, ASO 원문 허용 설정의 대상이 된다.
|
||||
|
||||
## 페르소나 의견
|
||||
|
||||
- 일반 사용자: 여기의 사용자가 실제 보험 설계사/지점장인지, 백오피스 계정인지 구분하기 어렵다.
|
||||
- 운영 관리자: 사용자 선택 후 “이 사용자가 최종적으로 어떤 역할과 보호 객체를 갖는지”를 바로 보고 싶다.
|
||||
- 적용 담당자: `KB_STAKEHOLDERS`와 토큰 주체의 관계가 사용자 화면에서 보이지 않으면 업무 사용자 매핑을 놓칠 수 있다.
|
||||
- DB 관리자: 사용자 추가가 DB 계정 생성이 아니라 애플리케이션 권한 데이터 추가라는 점이 필요하다.
|
||||
|
||||
## 가벼운 개선
|
||||
|
||||
1. 사용자 상세에 “직접 역할, 그룹 상속 역할, 원문 허용 컬럼, 발급 가능 토큰” 요약을 추가한다.
|
||||
2. VPD 데모 사용자라면 `KB_STAKEHOLDERS.USER_ID` 매핑 상태를 배지로 표시한다.
|
||||
3. 역할 부여 후 바로 “사용자별 접근 확인”과 “접근 검증”으로 이동하는 버튼을 둔다.
|
||||
|
||||
## Advanced로 둘 내용
|
||||
|
||||
- 내부 테이블명 `CB_APP_USER`, `CB_USER_ROLE`
|
||||
- 그룹 상속 SQL
|
||||
- DB 계정과 애플리케이션 사용자의 차이 상세
|
||||
|
||||
## 우선순위
|
||||
|
||||
P1. 권한 주체를 이해해야 접근 규칙과 토큰 검증의 혼동이 줄어든다.
|
||||
Reference in New Issue
Block a user