Viya 4 의 로그인은 sas-logon-app(SASLogon) 이 담당한다. 이 컴포넌트는 CloudFoundry UAA 계열이라 SAML 2.0 서비스 공급자(SP) 로 동작할 수 있다. Microsoft Entra ID(구 Azure AD) · Keycloak · ADFS 같은 IdP 를 붙이면 브라우저 로그인이 그쪽으로 넘어간다.
여기서 인증과 사용자 정보는 별개다.
| 축 | 담당 | 설정 위치 |
|---|---|---|
| 인증 (누가 로그인했는가) | SAML IdP | SASLogon 의 SAML 설정 |
| 신원 (그 사용자가 어떤 그룹인가, UID 는 무엇인가) | Identities 서비스 | LDAP 또는 SCIM |
SAML 만 붙이고 신원 공급을 맞추지 않으면 로그인은 되지만 권한이 비어 있거나 홈 디렉터리 UID 가 어긋난다. 파일시스템 권한이 필요한 CAS · compute 작업에서는 POSIX 속성(uid · gid) 이 필요하므로 이 축을 반드시 함께 설계한다.
IdP 에 애플리케이션을 등록할 때 넣는 값이다.
| 항목 | 값 |
|---|---|
| Entity ID (Identifier) | cloudfoundry-saml-login |
| Reply URL (ACS) | https://<SAS_DOMAIN>/SASLogon/saml/SSO/alias/cloudfoundry-saml-login |
| Sign-on URL | https://<SAS_DOMAIN>/SASLogon/login |
| 메타데이터 | https://<SAS_DOMAIN>/SASLogon/saml/metadata |
<SAS_DOMAIN> 은 Ingress 에 잡힌 실제 호스트 이름이다. 위 값은 기본 배포 기준이며 login.serviceProviderEntityId 를 바꿨다면 alias 도 함께 달라진다 (확인 필요 — 배포본의 메타데이터 URL 을 직접 열어 대조한다).
kustomize 오버레이로 넣는다. site-config 아래에 SAML 설정 조각을 두고 kustomization.yaml 의 transformers 또는 configMapGenerator 에 연결한 뒤 재배포한다.
넣어야 할 값은 대체로 다음과 같다.
NameID 를 이메일 또는 UPN 으로 받는다IdP 가 사설 CA 인증서를 쓰면 SASLogon 이 그 CA 를 신뢰해야 한다. Viya 의 신뢰 인증서 주입 경로(sas-certframe 에 넘기는 사용자 CA 목록) 에 넣는다. 이것을 빠뜨리면 메타데이터 조회 단계에서 실패한다.
설정 후 순서대로 본다.
kubectl -n <VIYA_NS> rollout status deployment/sas-logon-app
kubectl -n <VIYA_NS> logs deployment/sas-logon-app --tail=200 | grep -i saml
브라우저에서 https://<SAS_DOMAIN>/SASLogon/login 을 열면 IdP 로 넘어가야 한다. 로그인 후 되돌아오지 못하면 Reply URL 이 IdP 등록값과 한 글자라도 다른 경우가 가장 많다.
SSO 설정 중에 잠글 수 있으므로 로컬 관리자 계정 하나는 남겨 둔다. SASLogon 에는 기본 관리자로 로그인할 수 있는 경로가 있으니 SSO 를 켜기 전에 그 접속 방법을 확인해 둔다.