49 lines
4.5 KiB
JSON
49 lines
4.5 KiB
JSON
{
|
|
"kind": "QUESTION",
|
|
"title": "Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가",
|
|
"slug": "edge-authorization-scope",
|
|
"summary": "지금 edge는 user와 email만 전달하고 upstream은 role 판단을 하지 않는다. 다음 요구가 들어왔을 때 role까지 헤더로 보낼지, 아니면 인가를 애플리케이션으로 되돌릴지 정하지 않았다.",
|
|
"questionStatus": "OPEN",
|
|
"options": [
|
|
{
|
|
"title": "현재 — 인증만 edge에 둔다",
|
|
"description": "헤더가 user와 email 둘로 고정돼 있어서 계약이 가장 작고 크기 상한 문제도 생기지 않는다. 인가는 upstream이 자기 저장소로 해결한다. 서비스마다 권한 조회를 따로 붙여야 한다."
|
|
},
|
|
{
|
|
"title": "다음 후보 — role 전달까지 edge에 둔다",
|
|
"description": "공통 role을 한 곳에서 주면 서비스마다 권한을 조회하지 않아도 된다. 이 선택을 하면 다중 값 직렬화와 크기 상한, 갱신 시점 계약을 먼저 정해야 한다. upstream은 그 값을 검증할 수단이 없어서 edge가 틀리면 그대로 틀린다."
|
|
},
|
|
{
|
|
"title": "보류 — tenant와 인가 판단까지 edge에 둔다",
|
|
"description": "tenant는 잘못 들어간 값 하나가 다른 조직의 데이터를 그대로 열어 준다. 이 값만은 upstream이 다시 확인할 수단을 함께 설계해야 해서 지금 구성으로는 감당할 수 없다. 인가 판단까지 옮기면 edge가 애플리케이션 도메인을 알아야 하고 정책이 바뀔 때마다 edge를 배포하게 된다."
|
|
},
|
|
{
|
|
"title": "경계가 커지면 — BFF로 되돌린다",
|
|
"description": "role·tenant 정보를 edge header로 계속 확장하지 않고 BFF가 필요한 정보를 조회해 인가와 API 조합을 처리하는 선택지도 있다. 이 경우 BFF session, CSRF 검증, shared store 운영이 다시 필요하다."
|
|
}
|
|
],
|
|
"nextValidation": "upstream이 실제로 요구하는 claim을 먼저 적는다. 그 목록을 놓고 아래를 본다.\n\n1. 전달하려는 claim이 계속 늘어나는가.\n2. role이나 tenant 변경이 즉시 반영돼야 하는가.\n3. 정책이 애플리케이션 도메인을 알아야 하는가.\n4. 헤더 값이 인가 판단의 근거가 되는가.\n5. 서비스별 정책 차이가 커지는가.\n\n2번부터 5번 중 하나라도 그렇다면 헤더를 늘리는 방향이 아니라 되돌리는 방향을 본다.\n\nrole을 헤더로 실은 구성을 먼저 만들어 다중 값과 크기 상한을 넣고 무엇이 먼저 깨지는지 확인한다. role을 바꾼 뒤 몇 번째 요청부터 반영되는지도 잰다.",
|
|
"facts": [
|
|
"지금 edge 응답은 user와 email만 전달한다. role과 groups, tenant, 인증 방식, token 만료는 전달하지 않는다.",
|
|
"upstream의 identity endpoint는 role 판단을 하지 않고 누가 왔는지만 응답에 담는다.",
|
|
"internal token 검사가 controller 한 곳에 있고 security 설정은 그 경로 전체를 permitAll로 둔다. 새 endpoint에는 보호가 따라오지 않는다.",
|
|
"Nginx는 client가 보낸 동명 헤더를 merge하지 않고 덮어쓴다. 늘리는 헤더도 같은 처리를 받아야 한다.",
|
|
"upstream은 JWT를 입력으로 받지 않아서 헤더로 온 값을 스스로 검증할 수단이 없다."
|
|
],
|
|
"assumptions": [
|
|
"헤더 종류가 늘어나면 정해야 할 계약도 함께 늘어난다.",
|
|
"role이 바뀌는 시점과 요청이 오는 시점이 달라서 그 사이에 들어온 요청은 옛 값을 본다."
|
|
],
|
|
"unknowns": [
|
|
"다중 값 role을 어떤 구분자와 escaping으로 보낼지. 값 안에 그 구분자가 들어오면 어떻게 되는지.",
|
|
"헤더 크기 상한을 넘으면 무엇이 먼저 깨지는지. proxy가 자르는지 요청 자체가 거부되는지.",
|
|
"role이 바뀌었을 때 proxy session과 downstream 인가가 언제 따라가는지. 권한 회수가 몇 분 뒤에 반영되는지.",
|
|
"upstream이 헤더 존재만 볼지 값과 service identity까지 볼지."
|
|
],
|
|
"constraints": [
|
|
"전달할 헤더는 allowlist로 고정해야 하고 client가 보낸 동명 헤더는 언제나 덮어써야 한다.",
|
|
"internal token 검사가 controller 한 곳에만 있다. 헤더를 늘리기 전에 이 검사를 공통 경계로 옮기는 것이 먼저다.",
|
|
"upstream을 고칠 수 없어서 이 구조를 골랐다면 BFF로 되돌리는 선택지는 없다."
|
|
]
|
|
}
|