2013-07-16 3 views
1

IT 직원은 응용 프로그램의 IIS 6.0 웹 서버에 SiteMinder 에이전트 설치를 거부합니다. 이는 타사 소프트웨어이므로 보안 문제와 그 가능성 응용 프로그램 성능에 영향을주는 높은 자원 활용도웹 응용 프로그램 서버에 에이전트를 설치하지 않고 SiteMinder Single-Sign-On

우리는 기본 IIS, SiteMinder 에이전트 및 로그인 시도를 인증하는 "shim"만 포함 된 독립적 인 분리 웹 서버를 설정하는 것이 좋습니다.

이 심은 에이전트에 의해 보호되도록 표시된 단일 ASPX 페이지입니다. SiteMinder 에이전트를 사용하여 사용자 ID를 인증하고 응용 프로그램의 데이터베이스에서 사용자 ID를 조회 한 다음 사용자의 ID와 암호를 사용자의 브라우저로 반환합니다. JavaScript 함수는 사용자 ID와 암호를 마치 응용 프로그램의 기존 로그인 페이지에 입력 한 것처럼 POST합니다.

우려가 있습니까? 그 이유는 무엇?

비슷한 아키텍처를 구현 한 사람에 대해 들어 본 적이 있습니까?

제안 된 솔루션이 좋고, 좋지 않거나, 못생긴가요?

답변

2

에이전트가 초기 로그인뿐만 아니라 응용 프로그램에 대한 후속 호출, 즉 인증 된 세션을 관리하기 때문에 작동하지 않는 것처럼 보입니다. 에이전트는 쿠키를 검사하고 유효성 검사 등을합니다. 시나리오에는 그러한 상황이 어떻게 발생하는지 설명되어 있지 않습니다.

우리의 환경에서 모든 인터넷 트래픽은 IIS를 시작하기 전에 Apache 역방향 프록시를 통과합니다. IIS가 방화벽 뒤에 있습니다. Apache 역방향 프록시에는 트래픽이 IIS로 리다이렉트되는 SM 에이전트가 있습니다. 역방향 프록시 역할을하는 IIS와 유사한 설정을 수행하는 것이 가능할 것으로 생각됩니다.

그런데 IT 담당자에게 그의 제안 된 신발 끈 및 버블 검 로그인 솔루션은 IIS에 SiteMinder를 설치하는 것보다 훨씬 더 큰 보안 문제가 있다고 말하십시오.

+0

맞습니까? 답장을 보내 주셔서 감사합니다; 이것은 필자가 필요로했던 비 편향적 인 제 3 자 의견이지만, 응용 프로그램의 ID/암호를 클라이언트로 다시 보내는 아이디어와 관련된 보안 문제에 대해서도 언급했으면 좋겠습니다. (!!!) 그들의 시나리오에서 세션은 응용 프로그램의 내장 ID/암호 인증에 의해 처리되며 SSO는 단일 보호 자원 (사용자에게 응용 프로그램 암호를 보내는 "shim")에 대해서만 알고 있습니다. "신발 끈 및 거품 껌", 권자 권위 있는. – ryandenki

1

아파치 리버스 프록시 솔루션은 확실히 작동하지만 SiteMinder r12.51을 사용하면 SiteMinder의 리버스 프록시 버전 (기본적으로 더 많은 기능이 있음) 인 Secure Proxy Server가 기본적으로 제공됩니다.

SPS를 사용하면 SiteMinder 에이전트를 설치할 수 없거나 설치하지 않을 모든 응용 프로그램에 대해 단일 서버를 "게이트웨이"로 구성 할 수 있습니다. 웹 에이전트는 SPS에 내장되어 있으며 독자적인 Java 응용 프로그램이 많은 어려움을 겪습니다. SPS에는 r12 WAMUI의 모양과 느낌을 따르는 GUI가있어서 매우 간단하게 구성 할 수 있습니다.

보안 프록시 서버에는 페더레이션 게이트웨이 기능도 있으므로 SAML 연합을 수행하는 경우 웹 에이전트 옵션 팩을 설치할 필요가 없습니다. 모든 fcc 페이지는 SPS에서 제공 할 수 있으므로 SSO 환경을 지원하는 데 필요한 웹 서버의 수를 줄일 수 있습니다.