인가 기능을 이용한 RBAC
위 제목의 이름으로 시연 영상을 준비중입니다.
제목 그대로, 이전의 Code 구현을 이용하여 Keycloak Role에 따라 Client의 권한을 지정하고 동작시키는 방식이 아니고,
Keycloak의 인가 기능 중 역할 기반 정책(Role Based Policy)만을 이용하여 접근을 통제하는 방식입니다.
Client(Legacy Application)의 권한을 고려하지 않고, 어떤 Resource에 접근하려는 사용자가 접근하기에 충분한 Role을 보유하고 있는지를 보고 접근 여부를 판단합니다.
요구사항의 변경에 따라 특정 정책을 변경할 때, 전통적인 Code 방식에 비해 Client의 Code 수정이 줄어들 것으로 예상합니다만, 대신 인가 질의에 대한 오버헤드가 발생합니다.
이 오버헤드를 줄이기 위해 RPT Cache가 구현되어 있습니다만, 처음에 제가 영상으로 보여드렸던 전통적인 RBAC에 비해서 인가 질의 트래픽의 추가는 불가피합니다.
이 Trade-off가 잘 고려되었으면 합니다.
여기서 정책만 속성 기반 정책들로 바꾸면 ABAC가 되겠네요.
제목 그대로, 이전의 Code 구현을 이용하여 Keycloak Role에 따라 Client의 권한을 지정하고 동작시키는 방식이 아니고,
Keycloak의 인가 기능 중 역할 기반 정책(Role Based Policy)만을 이용하여 접근을 통제하는 방식입니다.
Client(Legacy Application)의 권한을 고려하지 않고, 어떤 Resource에 접근하려는 사용자가 접근하기에 충분한 Role을 보유하고 있는지를 보고 접근 여부를 판단합니다.
요구사항의 변경에 따라 특정 정책을 변경할 때, 전통적인 Code 방식에 비해 Client의 Code 수정이 줄어들 것으로 예상합니다만, 대신 인가 질의에 대한 오버헤드가 발생합니다.
이 오버헤드를 줄이기 위해 RPT Cache가 구현되어 있습니다만, 처음에 제가 영상으로 보여드렸던 전통적인 RBAC에 비해서 인가 질의 트래픽의 추가는 불가피합니다.
이 Trade-off가 잘 고려되었으면 합니다.
여기서 정책만 속성 기반 정책들로 바꾸면 ABAC가 되겠네요.
하지만 그 전에 Keycloak의 인가(Authorization) 기능을 동작시키는 데 있어서 고민해야 할 사안이 좀 있네요.
인가 패키지는 이미 작성되었으나, 좀 더 나은 기능을 수행할수 있도록 개선중입니다.
제가 이미 업로드한 OIDC Template Code-Client가 먼저 적용되어야만 이 인가 패키지를 사용할수 있습니다.
OIDC Session 측면에서 공유하는 Bean이 조금 있기 때문입니다.
Client를 기동 시, Keycloak에서 Resource의 속성 정보를 받아와 적재해야(Cache) 합니다.
그렇게 해야 Client에서 요청 URL을 보고 그와 매칭되는 Resource 명을 확인하여 Keycloak에 질의할수 있기 때문이지요.
이 방법은 Keycloak 인가 UI의 Resource 탭에서 입력된, URI 속성을 사용하는 것입니다.
정석적인 방법이라고 생각하지만, URI속성이 입력되지 않은 Resource에 대해서는 동작이 되지 않는다는 단점이 있습니다.
URI 속성은 필수 항목이 아니니까요.
또한 Keycloak의 Resource 정보가 매우 많다면 첫 기동 시 수많은 데이터를 적재해야 하니 메모리 Cache 용량 이슈도 있을것 같습니다.
Cache를 사용하게 된다면, 이 이슈가 인프라 영역까지 연결되겠네요.
많이 사용되는 K8S 환경이라면 Redis등의 공유 저장소를 사용할 확률도 높다고 생각되니까요.
의도치는 않았지만, 인가 기능에 Resource 정보, RPT 두가지의 Cache를 사용해야 하는 꼴이 되어버렸습니다.
현재는 첫 동작 시 Resource 정보를 Cache하는 기능을 Bean 설정으로 세팅할수 있게 구현한 상황입니다.
Cache를 사용할지, Cache를 사용하되 Resource 정보의 초기 Cache를 수행할지는 Bean 설정 시 설정하도록 구현하였습니다.
또한, 이 기능을 사용하지 않아도, Client 내부적으로 인가 기능이 적용된 메서드들에 접근할 때마다 Cache가 동작하게 구현하였습니다.
이 Cache기능 또한 Bean을 인가 처리 Bean에 설정해줘야만 동작하도록 했고, Cache를 적용해주지 않으면 오로지 Client에서 인가 기능이 적용된 메서드에 접근할 때마다 Keycloak에 질의하도록 구현하였습니다.
조금 무식한 방법이지만, 요청 URI의 Endpoint를 Resource 명으로 박아넣고 동작시켜도 잘 동작하게 했습니다.
이것이 올바른 방향인지는 확신할수 없습니다만, AI는 맞다고는 하네요. "진짜야?" 하고 되물어보면 바로 다른 답변이 나올것 같습니다.
이 이슈에 대해 조금 더 코드를 개선한 후 "Keycloak 인가 기능을 이용한 RBAC" 영상을 제작하여 업로드할 예정입니다.
Kakao Provider는 이번 이슈 처리 이후의 작업이 되겠네요.
이번 인가 기능 이슈와 무관한 인가 질의 동작은 이미 구현이 되어있기에, 접근 시각 또는 사용자 속성을 정책에 적용하는 ABAC 및 Java Policy 동작도 시연할수 있습니다만, 그 시연 영상은 조금 시일이 걸릴 것 같습니다.
인가 패키지는 이미 작성되었으나, 좀 더 나은 기능을 수행할수 있도록 개선중입니다.
제가 이미 업로드한 OIDC Template Code-Client가 먼저 적용되어야만 이 인가 패키지를 사용할수 있습니다.
OIDC Session 측면에서 공유하는 Bean이 조금 있기 때문입니다.
Client를 기동 시, Keycloak에서 Resource의 속성 정보를 받아와 적재해야(Cache) 합니다.
그렇게 해야 Client에서 요청 URL을 보고 그와 매칭되는 Resource 명을 확인하여 Keycloak에 질의할수 있기 때문이지요.
이 방법은 Keycloak 인가 UI의 Resource 탭에서 입력된, URI 속성을 사용하는 것입니다.
정석적인 방법이라고 생각하지만, URI속성이 입력되지 않은 Resource에 대해서는 동작이 되지 않는다는 단점이 있습니다.
URI 속성은 필수 항목이 아니니까요.
또한 Keycloak의 Resource 정보가 매우 많다면 첫 기동 시 수많은 데이터를 적재해야 하니 메모리 Cache 용량 이슈도 있을것 같습니다.
Cache를 사용하게 된다면, 이 이슈가 인프라 영역까지 연결되겠네요.
많이 사용되는 K8S 환경이라면 Redis등의 공유 저장소를 사용할 확률도 높다고 생각되니까요.
의도치는 않았지만, 인가 기능에 Resource 정보, RPT 두가지의 Cache를 사용해야 하는 꼴이 되어버렸습니다.
현재는 첫 동작 시 Resource 정보를 Cache하는 기능을 Bean 설정으로 세팅할수 있게 구현한 상황입니다.
Cache를 사용할지, Cache를 사용하되 Resource 정보의 초기 Cache를 수행할지는 Bean 설정 시 설정하도록 구현하였습니다.
또한, 이 기능을 사용하지 않아도, Client 내부적으로 인가 기능이 적용된 메서드들에 접근할 때마다 Cache가 동작하게 구현하였습니다.
이 Cache기능 또한 Bean을 인가 처리 Bean에 설정해줘야만 동작하도록 했고, Cache를 적용해주지 않으면 오로지 Client에서 인가 기능이 적용된 메서드에 접근할 때마다 Keycloak에 질의하도록 구현하였습니다.
조금 무식한 방법이지만, 요청 URI의 Endpoint를 Resource 명으로 박아넣고 동작시켜도 잘 동작하게 했습니다.
이것이 올바른 방향인지는 확신할수 없습니다만, AI는 맞다고는 하네요. "진짜야?" 하고 되물어보면 바로 다른 답변이 나올것 같습니다.
이 이슈에 대해 조금 더 코드를 개선한 후 "Keycloak 인가 기능을 이용한 RBAC" 영상을 제작하여 업로드할 예정입니다.
Kakao Provider는 이번 이슈 처리 이후의 작업이 되겠네요.
이번 인가 기능 이슈와 무관한 인가 질의 동작은 이미 구현이 되어있기에, 접근 시각 또는 사용자 속성을 정책에 적용하는 ABAC 및 Java Policy 동작도 시연할수 있습니다만, 그 시연 영상은 조금 시일이 걸릴 것 같습니다.
감사합니다