Knox 가 발급한 JWT 를 Bearer 토큰으로 써서 CDW 의 Hue REST API 를 호출한다. Hue 는 Custom JWT 인증을 지원하므로 발급자·대상과 JWKS 주소만 맞추면 되는 구조다.
Knox KNOXTOKEN 으로 JWT 발급
-> 클라이언트가 Authorization: Bearer <jwt> 로 Hue API 호출
-> Hue 가 Knox 의 JWKS 로 서명 검증
-> API 응답
발급한 토큰을 디코딩해 클레임을 본다. Hue 설정의 발급자·대상과 정확히 일치해야 한다.
echo "<jwt>" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
Hue 의 Custom JWT 설정에서 맞춰야 하는 값은 iss, aud, 그리고 key_server_url 이다. key_server_url 은 Knox 의 JWKS 엔드포인트를 가리킨다.
https://<knox-host>:8443/gateway/<topology>/knoxtoken/api/v2/jwks.json
Hue 는 서버 애플리케이션이므로 JWKS 를 인증 없이 받아 갈 수 있어야 한다. 그런데 기본 토폴로지에서는 이 엔드포인트가 SSO 뒤에 있어 302 로 KnoxSSO 로그인 페이지로 넘어가거나, 별도 토폴로지를 만들면 401 Basic 을 돌려준다.
curl -ki 'https://<knox-host>:8443/gateway/<topology>/knoxtoken/api/v1/jwks.json'
TLS 는 붙었는데 302 나 401 이 돌아온다면 인증서 문제가 아니다. 인증서를 신뢰 저장소에 넣는 것으로 302 가 200 이 되지는 않는다. 원인을 인증서로 오인하면 시간을 크게 낭비한다.
Cloudera Manager 의 cdp-resources.xml 안전 밸브에서 providerConfigs:<provider-name> 프로퍼티로 provider 를 정의한다. 값은 # 으로 구분된 한 줄이다.
익명 필터를 쓰려면 필터를 등록하고 URL 규칙을 건다.
role=authentication#authentication.name=ShiroProvider#authentication.enabled=true#
authentication.param.main.knoxAnonFilter=org.apache.knox.gateway.filter.AnonymousAuthFilter#
authentication.param.urls./knoxtoken/api/v2/jwks.json=knoxAnonFilter#
authentication.param.urls./knoxtoken/**=authcBasic
기존 규칙을 지우려면 authentication.param.remove 를 쓴다. 여러 번 반복해 쓸 수 있다.
authentication.param.remove=urls./**#
authentication.param.remove=urls./knoxtoken/**
삭제와 재등록을 한 번에 하지 말고, 먼저 삭제만 적용해 Refresh 하고 결과를 확인한 뒤 새 규칙을 넣는다.
적용 결과는 생성된 provider JSON 과 배포된 토폴로지의 shiro.ini 에서 확인한다.
grep -n '"urls\.' /var/lib/knox/gateway/conf/shared-providers/<provider>.json
LATEST=$(ls -dt /var/lib/knox/gateway/data/deployments/<topology>.topo.* | head -1)
find "$LATEST" -name shiro.ini -exec cat {} \;
필터 이름은 대소문자까지 정확해야 한다. 틀리면 토폴로지 배포 자체가 실패한다.
Failed to deploy topology <topology>
There is no filter with name 'KnoxAnonFilter'
이 작업은 대화 기록 안에서 끝나지 않았고 Cloudera 기술지원으로 넘어갔다. 남은 쟁점은 다음과 같다.
[urls] 규칙은 위에서부터 먼저 맞는 것이 적용된다. 일반 규칙(/knoxtoken/**)이 특정 규칙(/knoxtoken/api/v2/jwks.json)보다 앞에 생성되면 익명 허용이 먹지 않는다. 생성 순서를 제어하는 공식 방법이 확인되지 않았다 (확인 필요).homepage)를 직접 고치는 것과 JWKS 전용 토폴로지를 따로 만드는 것 중 어느 쪽이 권장인지 확인되지 않았다 (확인 필요).SSOCookieProvider 의 sso.unauthenticated.path.list 로 JWKS 만 SSO 를 우회시키는 방법은 검토만 하고 적용하지 않았다 (확인 필요).기술지원에 문의할 때는 "인증서 오류" 가 아니라 "JWKS 요청이 302 로 리다이렉트된다" 는 점을 명시해야 같은 답변이 반복되지 않는다.