소개
웹 계층 싱글 사인 온
    싱글 사인 온 확장
    도메인 간 싱글 사인 온
웹 계층 확장
    기존 시스템에서의 싱글 사인 온
    다른 J2EE 애플리케이션 서버에서의 싱글 사인 온
주변 인증 지원
요약

소개

현재 웹 상에서 사용할 수 있는 애플리케이션의 숫자가 점점 더 많아지고 있습니다. 이러한 애플리케이션은 일반적으로 자체 인증 체계나 사용자 등록 기능이 있는 여러 구성 요소로 구성됩니다. 그 결과 개발 및 운영 직원은 사용자가 인증되거나 한 번만 "사인 온(sign-on)"된 다음 각 애플리케이션 구성 요소에 액세스할 수 있도록 만들어야 하는 문제를 해결해야 합니다. 사용자가 애플리케이션에 한 번만 사인 온하도록 하는 기능은 일반적으로 "싱글 사인 온(Single Sign-On)" 또는 SSO라고 합니다.

BEA WebLogic Platform™ 8.1은 SSO 지원과 관련한 여러 문제를 일련의 접근 방식을 통해 해결합니다. 이러한 각 접근 방식은 각 애플리케이션 계층에 초점을 둡니다. 또한 BEA WebLogic Platform 8.1 보안 아키텍처는 다른 업체의 보안 솔루션을 통합하고 이러한 솔루션을 BEA WebLogic Platform 8.1 애플리케이션 보안 인프라스트럭처를 통해 보안 서비스로 제공하는 "SSPI(Security Service Provider Interfaces)"(또는 일반적으로 공급자라고 함)라는 본질적인 통합 지점을 제공합니다. 이러한 다른 업체의 솔루션에는 인증 솔루션, 웹 액세스 관리 솔루션, 감사 솔루션 등이 포함될 수 있습니다.

웹 계층 싱글 사인 온

애플리케이션의 웹 사용자 인터페이스에 대한 관심이 증가함에 따라 웹 계층은 SSO에 대한 요구가 가장 많은 일반적인 분야가 되고 있습니다. 웹 계층에서 브라우저 사용자에게는 애플리케이션을 인증(자신의 ID assertion)하라는 메시지가 표시됩니다. 이러한 ID는 애플리케이션 서버로 전달되어 사용자를 인증하는 데 사용됩니다. 사인 온이 성공하면 애플리케이션 서버가 상주하는 DNS 도메인에 해당하는 쿠키가 생성됩니다. 그런 다음 이 쿠키는 각 요청에 따라 애플리케이션 서버로 전송된 브라우저로 반환됩니다. 기본적으로 쿠키의 수명은 사용자가 애플리케이션을 종료하거나 브라우저를 닫을 때 종료됩니다.

J2EE 1.3 호환 애플리케이션 서버인 BEA WebLogic Server™ 8.1은 인증에 필요한 모든 J2EE 1.3 메커니즘을 지원합니다. 여기에는 다음이 포함됩니다. (1) 기본 인증 - 사용자의 자격 증명이 base64 인코딩으로만 보호됩니다. (2) 폼 기반 - 자격 증명이 보호되지 않고 일반 텍스트로 전송됩니다. (3) 인증서 기반 - 클라이언트의 X.509 인증서가 SSL이나 TLS 보안 프로토콜과 함께 사용되어 사용자의 ID를 구성합니다. 첫 번째의 두 인증 형식에서는 자격 증명 보호에 다소 취약한 보안 구성을 보호하기 위해 일반적으로 SSL이나 TLS와 같은 보안 전송을 사용해야 합니다.

앞에서 설명한 메커니즘인 J2EE 1.3 외에도 BEA WebLogic Server 8.1은 보안 인프라스트럭처 및 관련 보안 서비스 공급자를 통한 인증 사용을 지원하도록 구성될 수 있습니다. 보안 인프라스트럭처를 사용하면 클라이언트가 브라우저이든 애플리케이션이든 상관없이 인증 정책을 일관적으로 적용할 수 있습니다. 또한 애플리케이션에서는 인증을 수행하기 위해 자체 서블릿 필터를 제공할 필요가 더 이상 없습니다. 또 다른 장점은 애플리케이션을 변경할 필요 없이 인증 메커니즘을 다른 종류로 변경할 수 있다는 점입니다. 예를 들어 기업은 단순히 새로운 인증 방법에 대한 보안 서비스 공급자를 구현함으로써 기본 사용자 이름/암호 인증 방식을 토큰과 같은 보다 강력한 인증 방법으로 변경할 수 있습니다.

싱글 사인 온 확장

BEA WebLogic Server 8.1은 각 클러스터 구성원에 대해 재인증할 필요 없이 한 클러스터의 다른 구성원들에 대한 SSO, 장애 조치, 로드 밸런싱에 대한 지원에 있어서 J2EE 1.3 사양을 능가합니다. 또한 파일 또는 JDBC persistence에 대한 세션이 구성되면 동일한 DNS 도메인 내의 다른 논-클러스터(non-clustered) 서버까지 SSO 솔루션이 확장됩니다.

마지막으로, SSO를 비활성화할 수 있을 뿐 아니라 쿠키의 범위를 제어하기 위해 사용되는 이름을 지정함으로써 SSO 그룹에 참여하는 다른 애플리케이션 또는 웹 컴포넌트를 만들 수도 있습니다. SSO 그룹을 사용하면 단일 DNS 도메인이 여러 애플리케이션의 홈이 될 수 있으며, 각각은 어떤 다른 애플리케이션 또는 웹 컴포넌트가 특정 SSO 환경의 일부로 참여할지를 제어할 수 있습니다.

도메인 간 싱글 사인 온

BEA WebLogic Server 8.1은 각 클러스터 구성원에 대해 재인증할 필요 없이 한 클러스터의 다른 구성원들에 대한 SSO, 장애 조치, 로드 밸런싱에 대한 지원에 있어서 J2EE 1.3 사양을 능가합니다. 또한 파일 또는 JDBC persistence에 대한 세션이 구성되면 동일한 DNS 도메인 내의 다른 논-클러스터(non-clustered) 서버까지 SSO 솔루션이 확장됩니다.

마지막으로, SSO를 비활성화할 수 있을 뿐 아니라 쿠키의 범위를 제어하기 위해 사용되는 이름을 지정함으로써 SSO 그룹에 참여하는 다른 애플리케이션 또는 웹 컴포넌트를 만들 수도 있습니다. SSO 그룹을 사용하면 단일 DNS 도메인이 여러 애플리케이션의 홈이 될 수 있으며, 각각은 어떤 다른 애플리케이션 또는 웹 컴포넌트가 특정 SSO 환경의 일부로 참여할지를 제어할 수 있습니다.

웹 계층 확장

엔터프라이즈 애플리케이션의 경우에는 애플리케이션을 구성하는 모든 구성 요소가 웹 계층에 포함되거나 동일 애플리케이션 서버에서 호스팅되는 경우가 드뭅니다. 그 결과 SSO 솔루션은 모든 구성 요소에 대한 통합을 지원해야 합니다.

BEA WebLogic Server 8.1은 웹 계층을 넘어서 표준 제품 기능의 일부인 기존 시스템과 기타 J2EE 애플리케이션 서버를 통합하는 확장 성능을 제공합니다. 또한 이러한 기능을 지원하는 데 사용되는 메커니즘은 고객, 보안 벤더 또는 ISV에 의해 더욱 확장되어 향상된 성능을 제공할 수 있습니다.

기존 시스템에서의 싱글 사인 온

BEA WebLogic Server 8.1에서 제공되는 SSO 솔루션의 일부이며, J2EE 커넥터 아키텍처에서 정의된 애플리케이션 어댑터는 비즈니스 솔루션을 구성하는 다른 구성 요소를 인증하는 데 필요한 자격 증명을 가져올 수 있습니다. 이러한 자격 증명 취득 기능은 BEA WebLogic Server 8.1에서 제공되는 보안 인프라스트럭처의 일부로 제공됩니다. 커넥터 컨테이너는 배포 기술자의 정보에 따라 대상에 대한 적합한 자격 증명 집합을 검색하고 자격 증명 매핑 공급자 중 하나에 포함된 매핑을 검색할 수 있습니다. 그런 다음 자격 증명 정보는 어댑터로 전달되어 대상을 인증하는 데 사용됩니다.

자격 증명 매핑 공급자는 요청자가 원하는 리소스를 인증하기 위해 요청자의 ID 및 필요한 리소스를 적합한 자격 증명 집합으로 매핑하는 역할을 수행합니다. 매핑에 사용된 요청자의 ID가 인증된 요청자의 사용자 이름이거나 또는 요청자가 구성원인 그룹의 이름인 경우 더욱 쉽게 관리할 수 있습니다.

각 자격 증명 매핑 공급자는 하나 이상의 자격 증명 형식과 연결될 수 있습니다. 특정 자격 증명 매핑 공급자에서 지원되는 자격 증명의 형식은 공급자가 인스턴스화되는 시점에 BEA WebLogic Server에 등록됩니다. BEA WebLogic Server 8.1은 사용자 이름 및 암호의 형식으로 자격 증명을 관리할 수 있는 기본 자격 증명 매핑 공급자를 제공합니다. Kerberos 티켓 및 SAML assertion과 같은 자격 증명 형식을 지원하려면 추가 자격 증명 매핑 공급자를 사용자 지정하여 구현할 수 있습니다.

다른 J2EE 애플리케이션 서버에서의 싱글 사인 온

CSIv2(Common Secure Interoperability v2) 사양의 레벨 0을 준수할 경우, BEA WebLogic Server 8.1은 IIOP(Internet Inter-ORB Protocol)를 통해 다른 호환되는 J2EE 애플리케이션 서버에서 호스팅되는 EJB(Enterprise Java Bean)로 보안 SSO 환경에 참여할 수 있습니다.

BEA WebLogic Server 8.1은 다른 호환되는 J2EE 애플리케이션 서버로 인증할 수 있는 필수 GSSUP(Generic Security Services Username Password) 인증 메커니즘을 지원하며 이러한 인증의 대상 역할을 수행할 수 있는 기능을 지원합니다. 또한 두 컨테이너 간의 트러스트 관계로 구성된 경우 Common Secure Interoperability v2 사양의 설명에 따라 ID 토큰 사용을 지원할 수 있습니다.

J2EE 애플리케이션 서버 간에 발생할 수 있는 또 다른 SSO의 속성은 애플리케이션에서 IBM MQSeries와 같은 외부 JMS(JAVA Messaging Service) 공급자와 함께 Message Driven Bean을 사용하는 경우입니다. 이 경우에 EJB 컨테이너는 애플리케이션 코드가 전달하는 대기열에 있는 메시지를 검색하기 위해서 컨테이너 자체를 외부 JMS 구현으로 인증해야 합니다. J2EE 연결 어댑터에서와 같이 BEA WebLogic Server 8.1은 자격 증명 매핑 공급자를 사용하여 외부 JMS 공급자를 인증하는 데 필요한 자격 증명을 가져옵니다.

자격 증명 매핑 공급자는 BEA WebLogic Server 관리자 콘솔을 통해 외부 JMS 공급자와 요청자의 ID를 적합한 자격 증명 집합으로 매핑하도록 구성될 수 있습니다. 또한 자격 증명 매핑 공급자는 고객 및 외부 벤더에 의해 작성될 수 있으므로, 향상된 매핑이 포함된 사용자 지정 구현도 가능합니다.

주변 인증 지원

웹 서비스와 같은 새로운 통합 패러다임이 등장하고 기업 전반의 확장 SSO에 대한 요구가 증가함에 따라 애플리케이션 서버와는 별도로 존재하는 인증 지원에 대한 요구가 점차 증가하고 있습니다. 주변 인증이란 원격 사용자의 ID 인증 처리가 애플리케이션 또는 기업의 주변부에서 수행되는 경우를 나타내는 용어입니다. 이러한 주변 인증은 일반적으로 assertion된 ID와 확인을 수행하기 위해 일정 형식의 해당 증명 자료를 지정하는 원격 사용자에 의해 수행됩니다. 실제로 ID의 진위성을 보장하는 엔티티인 인증 에이전트는 VPN(Virtual Private Network), 방화벽, SSO 솔루션 또는 기타 다른 형식의 글로벌 ID 서비스와 같은 여러 형식을 사용할 수 있습니다.

각 인증 에이전트는 다음과 같은 공통된 속성을 갖고 있습니다. 에이전트는 인증 절차를 수행하고 그 결과 아티팩트 또는 토큰을 생성합니다. 이러한 아티팩트 또는 토큰은 인증된 사용자에 대한 정보를 확인하기 위해 제공되어야 합니다. 토큰의 형식은 벤더별로 다르지만, OASIS에서는 XML을 사용한 표준 토큰 형식을 정의하기 위해 노력하고 있습니다. 하지만 이런 모든 노력에도 불구하고, 토큰이 작성된 애플리케이션 및 인프라스트럭처가 이러한 개념을 지원하도록 디자인되지 않으면 기업들은 네트워크 내부의 각 애플리케이션에 대해 원격 사용자가 재인증을 거치도록 해야 할 것입니다.

BEA WebLogic Server 8.1은 ID assertion 지원을 통해 SSO 개념을 주변부로까지 확장하도록 디자인되었습니다. 보안 인프라스트럭처의 핵심 요소로 제공되는 ID assertion 개념을 통해 고객 및 파트너는 OPSEC(Checkpoint Open Platform for Security), SAML(Security Assertion Markup Language)과 같은 주변 인증 체계나 Common Secure Interoperability v2와 같은 프로토콜에 대한 향상된 기능으로 제공되는 인증 메커니즘을 사용하여 이러한 기능을 달성할 수 있도록 BEA WebLogic Server 8.1을 사용자 지정할 수 있습니다.

주변 인증에 대한 지원을 위해서는 하나 이상의 토큰 형식을 지원하도록 디자인된 Identity Asserter Provider를 사용해야 합니다. 언제라도 서로 다른 여러 Identity Asserter Provider를 등록하여 사용할 수 있습니다. BEA WebLogic Server 8.1은 지원되는 여러 프로토콜에서 제공되는 메커니즘을 사용하여 일반적인 비즈니스 요청의 일부로 토큰을 전송할 수 있습니다. 요청이 수신되면 프로토콜 메시지 처리를 담당하는 엔티티가 메시지에 토큰이 있는지 여부를 확인합니다. 이 정보는 보안 인프라스트럭처에 대한 호출에 사용되어 토큰의 유효성을 검사하는 데 적합한 Identity Asserter Provider를 호출합니다. Identity Asserter 구현에서는 토큰에서 유효성과 트러스트를 구성하는 데 필요한 모든 기능을 수행해야 하며 사용자가 애플리케이션에 대한 재인증을 거치지 않고 합리적인 수준으로 사용자 ID를 제공해야 합니다.



위에서와 같이 가장 일반적인 시나리오 중 하나는 다른 업체의 제품 통합을 통해 제공되는Web SSO(Single Sign-On)입니다. 이 예에서 기업은 다른 업체의 Web SSO 솔루션을 활용하여 WebLogic 인프라스트럭처에 대한 SSO를 달성할 수 있습니다.

1 단계: 인증되지 않은 사용자가 리소스에 액세스하려고 합니다.
2 단계: 요청이 웹 서버에서 Web SSO 솔루션으로 리디렉션됩니다.
3 단계: Web SSO 솔루션이 사용자에게 자격 증명을 요구하고 사용자를 인증합니다.
4 단계: 인증 토큰과 함께 요청이 WebLogic 리소스로 전달됩니다.
5 단계: 사용자가 액세스하려는 리소스가 포함된 컨테이너가 액세스 요청을 WebLogic 애플리케이션 보안 인프라스트럭처로 위임합니다.
6 단계: WebLogic 보안 서비스는 다른 업체의 Web SSO 솔루션에서 제공된 토큰을 수용하고 이를 Identity Asserter로 전달할 수 있습니다.
7 단계: Identity Asserter는 다른 업체의 Web SSO 솔루션을 통해 제공된 토큰의 유효성을 검사합니다.
8 단계: Identity Asserter는 토큰과 관련된 사용자 정보를 Login Module에 전달합니다.
9 단계: LogIn Module은 사용자를 재인증할 필요 없이 사용자를 WebLogic 환경에 로그인합니다.

요약

BEA WebLogic Server 8.1은 엔터프라이즈 애플리케이션이 구축할 수 있는 리치 SSO 환경을 지원합니다. SSO 기능은 다른 J2EE 애플리케이션 서버에서 제공하는 기능 범위를 벗어나 현재 엔터프라이즈 환경의 문제를 해결합니다. 개방형의 보안 프레임워크에서는 이러한 SSO 기능을 다른 업체의 보안 솔루션에 통합할 수 있으며 변화하는 요구에 맞게 기업 환경을 변화할 수 있습니다. BEA WebLogic 8.1 보안에 대한 자세한 내용을 보려면 http://edocs.bea.com/wls/docs81/security.html을 방문하십시오..