VPN SSO가 사용자를 내부 앱에 자동으로 로그인시키나요?

ID 공급자를 통해 인증하는 VPN 게이트웨이가 증명하는 것은 한 가지입니다. 공급자가 게이트웨이 앞에서 한 사용자를 보증했다는 것입니다. 그 게이트웨이가 그 사용자에게 인트라넷 위키, 모니터링 대시보드, 빌드 서버용 자격 증명을 건네는 것은 아닙니다. 그 서비스들은 자체 페더레이션으로 사람을 로그인시키고 자체 권한 부여를 적용하며, 터널은 어떤 패킷이 그곳에 도달할 수 있는지만 결정합니다.

세 개의 세션, 세 개의 별도 판단

상태를 분리해 두십시오. 각각 자체 일정에 따라 만료되기 때문입니다. VPN 세션은 게이트웨이가 ID를 수락한 것과 그것이 부여한 네트워크 접근입니다. ID 공급자의 브라우저 세션은 브라우저가 그 공급자에 대해 아직 보유하고 있으며 정책에 따라 재사용할 수 있는 것입니다. 애플리케이션 세션은 자신에게 보낸 응답을 검증한 하나의 서비스에 속합니다.

이 상태들을 혼동하면 잘못된 질문이 나옵니다. 보통 터널이 왜 사용자를 모든 곳에서 로그인시키지 않느냐는 형태입니다. 질문을 바꾸십시오. 어느 앱에 페더레이션 항목이 없는지, 어느 앱이 사용자를 거부하는지, 어느 앱에 경로가 없는지입니다. 인트라넷 앱을 여는 한 번의 로그인 프롬프트도 공급자로 되돌아갈 수 있습니다. 두 번째 리디렉션은 다른 대상 그룹을 위한 새 권한 부여 요청이기 때문입니다.

게이트웨이를 자체 애플리케이션으로 연결

VPN을 공급자의 승인된 애플리케이션으로 등록하고 자체 식별자, 리디렉션 URI, 사용자 할당을 두십시오. 그다음 그 로그인이 어떤 네트워크 권한을 부여하는지 정하십시오. 이는 공급자 기능이 아니라 VPN 정책이기 때문입니다. 모니터링 서브넷에만 도달해야 하는 사용자는 다른 게이트웨이 정책을 받지, 다른 비밀번호를 받지 않습니다.

터널의 인증 응답은 재사용 가능한 자격 증명이 아닙니다. OIDC ID 토큰은 어느 클라이언트를 위해 발급되었는지 밝히는 대상 그룹 클레임을 가지며, SAML 베어러 어서션은 대상 그룹을 수신하는 서비스 공급자로 제한합니다. 첫 번째 서비스의 응답을 받아들이는 두 번째 서비스는 설정이 잘못된 것이며, 토큰을 다른 앱으로 복사하는 것은 통합이 아닙니다.

내부 앱을 각각 등록한 다음 브라우저 컨텍스트를 설정

각 서비스에는 지원되는 SAML 또는 OIDC 값이 필요합니다. 발급자, 클라이언트 식별자, 콜백 또는 어서션 컨슈머 URL, 필요한 클레임, 할당입니다. 도달성은 그 위에 붙습니다. ID 검사는 경로나 DNS 응답을 제공하지 않기 때문입니다.

1. 애플리케이션 항목을 만들고 엔터티 또는 클라이언트 ID가 앱이 보내는 것과 일치하는지 확인하십시오.
2. 스킴과 포트를 포함한 정확한 콜백 URL을 등록하십시오. 조금만 틀려도 사용자가 인증한 뒤 실패합니다.
3. 사용자나 그룹을 할당한 다음 필요한 클레임이 발급되는지 확인하십시오.
4. 비공개 앱과 함께 ID 공급자의 엔드포인트도 허용하십시오. 그렇지 않으면 리디렉션이 완료될 수 없습니다.

브라우저 컨텍스트가 기존 공급자 세션을 재사용할지 결정합니다. 시스템 브라우저를 여는 네이티브 클라이언트는 그 상태를 공유할 수 있지만, 자체 쿠키 저장소를 가진 임베디드 뷰는 보통 공유할 수 없습니다. 새 브라우저, 시크릿 창, 두 번째 프로필은 모두 아무것도 없는 상태에서 시작하며, 이는 예상된 일이지 고장 난 SSO 구성이 아닙니다.

흐름을 실행하고 어디서 멈추는지 읽기

브라우저의 네트워크 패널로 재현하고 리디렉션 체인을 관찰하십시오. 유용한 점검은 한 번에 한 홉씩 따라갑니다. 게이트웨이에서 공급자로, 공급자에서 코드나 어서션과 함께 앱으로, 앱에서 공급자의 토큰 엔드포인트로, 앱 세션이 발급됩니다. 체인이 멈추는 홉이 고쳐야 할 구성 요소를 알려줍니다.

명령줄 점검 두 가지면 흔한 의문이 풀리며, 둘 다 관리 호스트에서 실행해도 안전합니다.

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

메타데이터에 한 번도 등록하지 않은 엔드포인트가 나오면 앱이 다른 테넌트나 발급자를 가리키는 것입니다. 앱에 대한 첫 요청이 예상치 못한 호스트로 302를 응답하면, 살펴볼 곳은 앱의 페더레이션 구성이지 VPN 프로필이 아닙니다.

누가 요청했는지 찾아 프롬프트를 고치기

두 번째 비밀번호 프롬프트가 자동으로 결함은 아닙니다. 앱이 더 높은 보증 수준을 요구하거나, 공급자가 최대 세션 기간과 새 챌린지를 강제할 수 있습니다. 흐름을 조용하게 만들려고 그 요구 사항을 없애면 의도된 통제가 약해지므로, 정책을 바꾸기 전에 어느 구성 요소가 요청했는지 확인하십시오.

그다음 무엇을 개선할지 정하십시오. 프롬프트가 앱에서 나오면 그 페더레이션 항목을 고치십시오. 정책에 따라 공급자에서 나오면 요구 사항을 문서화하십시오. 로그인에 성공한 뒤에도 앱에 도달할 수 없다면 터널 라우팅이 의심 대상입니다. 왜냐하면 ID와 패킷 전달은 서로 다른 곳에서 실패하며 사용자 자리에서는 비슷해 보이기 때문입니다.