APM 포털 액세스: 애플리케이션 세션은 누구의 것인가

BIG-IP APM Portal Access로 인트라넷 애플리케이션을 게시하는 것은 가상 서버를 복사하는 일이 아니라 세션에 관한 결정이다. 포털은 사용자를 들여보내고, 다시 쓰기 프로파일은 선택된 요청을 게이트웨이 경로에 유지하며, 애플리케이션은 여전히 자체 세션을 가진다. 다섯 가지 점검이 예측 가능하게 동작하는 설계와 헬프데스크가 사용자 한 명씩 타임아웃을 알게 되는 설계를 구분한다. 순서대로 수행하고 처음으로 맞지 않는 점검에서 멈춘다.

점검 1: 리소스는 게시되었는가, 단지 링크되었는가

webtop의 북마크는 사용자가 항목을 본다는 것을 증명한다. 애플리케이션이 게시되었다는 것은 증명하지 않는다. 액세스 프로파일, 다시 쓰기 프로파일, 이들을 결합하는 가상 서버를 찾고, 리소스 할당이 생각하는 애플리케이션을 가리키는지 확인한다. 셋 중 하나라도 없거나 일관되지 않으면 나머지 목록은 의미가 없다.

절반만 게시된 경우는 진입점에서 건강해 보인다. 가상 서버가 액세스 프로파일을 갖는 동안 다시 쓰기 프로파일은 다른 리소스 URI로 제한되어, webtop 항목이 나타나고 첫 페이지가 로드된 뒤 하위 경로 요청이 게이트웨이 경로를 떠나 백엔드에 직접 도달한다. 반대 모습은 잘못된 애플리케이션에 할당된 리소스이다. 북마크는 열리고, 아무도 승인하지 않은 것을 연다.

점검 2: 백엔드 세션은 별개의 상태이다

APM이 사용자를 로그인한 것으로 보더라도 백엔드는 자체 인증을 요구할 수 있다. 지원되는 SSO 통합이 그 관계를 대신 설정하지만, 포털 로그인을 받아들였다고 해서 모든 애플리케이션이 같은 자격 증명이나 같은 세션 쿠키를 받아들이는 것은 아니다. 리소스에 SSO가 구성되지 않았다면 애플리케이션은 이미 인증된 포털 안에서 자체 로그인을 요구한다.

보이는 프롬프트를 바꾸려고 SSO를 끄는 것은 흔하고 나쁜 지름길이다. 프롬프트를 만든 수명 주기에 손대지 않고 인증 설계를 바꾼다. 대신 백엔드 로그인이 애초에 표시되어야 하는지 결정하고, 표시되어야 한다면 게시된 흐름의 명시적 일부로 만든다.

점검 3: 시계가 두 개 있고, 같은 시계가 아니다

APM의 액세스 프로파일은 비활동 타임아웃과 최대 세션 수명을 가진다. 애플리케이션은 자체 유휴 타이머와 쿠키 만료를 가진다. 포털 타이머를 늘려도 애플리케이션 세션은 늘지 않고, 애플리케이션 세션을 줄여도 사용자는 포털에서 로그아웃되지 않는다.

전형적인 지원 전화는 맞지 않는 짝에서 나온다. 포털은 아직 유효하고 애플리케이션 세션은 아니며, 사용자는 포털과 모순되는 것처럼 보이는 로그인 양식을 본다. 이는 오류가 아니라 올바른 동작이며, 해결책은 이 애플리케이션에서 어느 시계가 먼저 만료되어야 하는지 선택하는 것이다.

점검 4: 로그아웃에는 정의된 범위가 있다

애플리케이션의 로그아웃 버튼이 무엇을 끝내야 하는지 적는다. 그 애플리케이션만인지, 전체 APM 세션인지, 아니면 더 넓은 ID 공급자 세션인지. 액세스 프로파일은 선택적 지연이 있는 로그아웃 URI 목록을 지원하며, 요구 사항이 그것이라면 이렇게 애플리케이션 로그아웃이 포털 세션을 끝내게 한다. 그것이 없으면 애플리케이션 로그아웃은 포털을 살려 두고, 다음 요청이 사용자를 조용히 다시 로그인시킬 수 있다.

같은 포털의 다른 리소스에 미치는 영향을 계산한다. 한 애플리케이션에서 로그아웃하면 다른 여섯 개의 세션이 끝난다면, 그 동작을 애플리케이션 소유자와 미리 합의하지 않는 한 사용자는 버그라고 부를 것이다. 탭을 닫고 webtop으로 돌아오는 것은 무언가가 끝났다는 증거가 아니다.

점검 5: 애플리케이션은 다시 쓰기를 견딘다

Portal Access는 선택된 웹 콘텐츠를 다시 쓰며, 다시 쓰기에는 한계가 있다. 최신 클라이언트 측 기능, 백그라운드 작업자, 업로드 흐름, 페더레이션 로그인은 특정 릴리스가 처리하는 범위를 벗어날 수 있다. F5의 버전별 호환성 매트릭스는 약속하기 전에 읽어야 할 문서이다. 한계가 릴리스마다 다르기 때문이다.

방문 페이지가 아니라 중요한 흐름을 시험한다. 로그인하고, 필요한 각 기능을 탐색하고, 애플리케이션이 업로드한다면 업로드하고, 의도한 세션이 만료되게 두고, 모든 로그아웃 경로를 따른다. 한 번 렌더링된 페이지는 애플리케이션이 동작한다는 증거가 아니다.

필요한 흐름을 다시 쓸 수 없으면 문서화된 페더레이션, 역방향 프록시, 네트워크 액세스 설계로 옮긴다. 일반 터널처럼 동작하라고 요구받은 브라우저 포털은 데모는 통과하고 감사에서는 실패한다.