SiteMinder에 대한 올바른 디자인

Question

Site Minder를 사용하여 SSO 용 아키텍처에 대한 권장 사항을 제시해야합니다. 몇 가지 J2EE 응용 프로그램이 있습니다. 이 J2EE 응용 프로그램은 http 헤더에 SSO 공급자가 인증 한 후 정보가있는 경우 작동하도록 설계되었습니다. 우리는 애플리케이션 SSO 제공자를 불가지론 자로 유지했습니다. 즉, SSO 공급자의 헤더에만 의존합니다. 이것은 RSA와 SSO 공급자로서 잘 작동했습니다.

지금 SiteMinder와 함께 제안 된 또 다른 아키텍처가있다. 요청 방식의 흐름은

IIS가있는 SiteMinder -> Apache 역방향 프록시 -> Tomcat 응용 프로그램 -> 백엔드 응용 프로그램입니다.

우리가

A) IIS (공공 직면 사이트)와 SiteMinder를

B) 라우팅을위한 아파치 역방향 프록시()

C) 톰캣 응용 프로그램 (라우팅 및 들어있을 것이다 분해하려면 시간에 기초하여 사이트 액세스)

D)의 논리 백엔드 애플리케이션

새 아키텍처를 가져 오는 이유는 모든 백 엔드 응용 프로그램에 사이트 액세스 코드가 있기 때문입니다. 사이트는 얼마 동안 속성 파일에 의해 제어되는 동안 다운 될 수 있습니다.

이 아키텍처가 잘못되었습니다. Apache Reverse Proxy가 필요한 이유를 모르겠습니다. 나는 흐름이있는 간단한 아키텍처로 여전히 으로 갈 것이다. a) IIS가 라우팅 -> 백엔드 애플리케이션 (사이트에 액세스 할 수 있는지 여부를 확인하기 위해 공통 서비스에 액세스)을 사용하는 SiteMinder

내가 누락 된 것이 있습니까?

Answer 1

Apache 역방향 프록시를 사용하면 여러 IIS 인스턴스간에로드 균형을 쉽게 조정할 수 있습니다. 지금까지 내가 IIS에서 비슷한 것을하려고한다면 톰캣 등에서 작동하도록 최적화되지 않은 ARR (응용 프로그램 요청 라우팅) 모듈을 사용해야 할 것입니다.

그러나 IIS가있는 SiteMinder는 추가 된 것 같습니다 아키텍처의 오버 헤드. Apache 역방향 프록시는 SiteMinder 에이전트도 지원합니다. Apache 프록시에서 SiteMinder 에이전트를 설정하고 그림에서 IIS를 완전히 제거하지 않는 이유는 무엇입니까? 나는 다음과 같은 이점을 생각할 수 있습니다

1. 여분의 네트워크 홉
2. 정리 스택을 제거 아키텍처
3. 에서 하나 개의 추가 레이어를 제거합니다. Apache + Tomcat은 기업에서 매우 표준이지만 IIS + Apache + Tomcat은 그렇지 않습니다.

희망이 내가 두 번째 아키텍처 뒤에있는 근거 중 하나가 표시되지

Answer 2

을하는 데 도움이됩니다. 첫 번째 시나리오는 훨씬 일반적인 Siteminder 배포입니다.

이러한 종류의 아키텍처는 잠재적으로 취약점 (로그온 우회)을 열 수 있음을 알고 있어야합니다.내 대답은 this question에 있습니다. 이러한 언급은 두 아키텍처 모두에 해당됩니다.