SAML 사용 시나리오

SAML 기능을 네 개의 기본 사용 시나리오를 통해 설명합니다. 처음 세 개의 시나리오는 정책 세트를 사용하여 구성된 웹 서비스 싱글 사인온을 설명합니다. 네 번째 시나리오는 SAML API 및 신뢰 클라이언트 API를 사용하여 빌드할 수 있는 사용자 정의 SAML 싱글 사인온을 설명합니다. 시나리오는 비즈니스 서비스에 액세스하기 위해 SAML 구성 요소와 API를 사용하여 보안 토큰 서비스(STS)에 인증하고, SAML 토큰을 요청하며, SAML 토큰을 구현하는 방식을 보여줍니다.

개요

WebSphere® Application Server는 SAML을 통해 SAML 토큰을 사용하여 싱글 사인온 및 ID 연합 비즈니스 솔루션을 작성할 수 있는 구성 요소와 API를 제공합니다. SAML 정책 세트는 SAML 토큰을 요청하고, SAML 토큰을 SOAP 메시지로 전파하며, SAML 토큰을 유효성 검증 및 인증하도록(모두 아무런 프로그래밍 없이) 웹 서비스 애플리케이션을 구성하기 위한 구성 요소입니다.

SAML 및 WS-Trust 클라이언트 API를 사용하여 프로그래밍 방식으로 SAML 토큰을 작성하고, SAML 토큰을 구문 분석 및 유효성 검증하며, 웹 서비스 SOAP 메시지 이외의 프로토콜에서 수신된 SAML 토큰을 인증할 수 있습니다. 특히, SAML API를 사용하여 사용자 정의 SAML 토큰 속성을 처리하고, 개인화된 애플리케이션 인터페이스를 작성하며, 청구 기반 권한을 수행하십시오. WS-Trust 클라이언트 API를 사용하여 STS로부터 SAML 토큰이나 다른 유형의 토큰을 요청하고 STS로 보안 토큰을 유효성 검증 및 교환하십시오.

WebSphere Application Server 제품에는 SAML이나 다른 유형의 보안 토큰을 발행하기 위한 STS가 포함되어 있지 않습니다. 하지만 WebSphere Application Server는 SAML을 통해 Tivoli® Federated Identity Manager 및 기타 써드파티 STS 구현과 상호 운용합니다.

시나리오 1: 웹 서비스 싱글 사인온(SSO)

이 싱글 사인온(SSO) 사용 시나리오에서는 사용자가 STS에 인증하고 전달 확인 메소드를 사용하여 SAML 토큰을 요청합니다. 사용자는 그런 다음 SAML 토큰을 사용하여 비즈니스 서비스 제공자에 액세스합니다. 비즈니스 서비스 제공자는 SAML 토큰의 유효성을 검증하고 제공자와 발행 STS 사이의 신뢰 관계를 기반으로 하여 사용자의 ID와 속성을 어설션합니다. 수신된 SAML 토큰은 토큰 서명 인증서가 비즈니스 서비스 제공자에서 신뢰되는 경우 및 토큰의 만기 시간이 비즈니스 서비스 제공자 로컬 시간과 구성 가능한 클럭 오차를 더한 값 미만인 경우에 유효하다고 간주됩니다.

비즈니스 서비스 제공자는 서비스의 정책 구성을 기반으로 SAML 토큰을 사용하여 사용자를 대신해서 다운스트림 서비스에 액세스할 수 있습니다. 비즈니스 서비스 제공자는 정책 구성을 사용해서 원래 SAML 토큰을 전파하거나 원래 사용자 속성을 기반으로 하여 자체 발행한 SAML을 생성할 수 있습니다. 이 시나리오의 정책 세트 및 바인딩 구성 방법에 대한 자세한 설명은 SAML 전달 토큰의 클라이언트 및 제공자 바인딩 구성에 대한 정보를 참조하십시오.

SAML은 업계 표준 보안 토큰이고 다수의 벤더 제품에서 지원되기 때문에 SAML 전달 토큰을 사용한 싱글 사인온이 SSO 기술보다 유익합니다. 또한 SAML 기능의 WebSphere Application Server 구현은 Tivoli Federated Identity Manager, DataPower®, 기타 벤더 제품과 상호 운용됩니다.

다음 다이어그램은 웹 서비스 싱글 사인온 사용 시나리오의 STS와 비즈니스 서비스 제공자 간의 상호작용을 보여줍니다.
그림 1. 웹 서비스 싱글 사인온 사용 시나리오
SAML 전달 토큰을 통한 싱글 사인온(SSO) 시나리오

호출자 바인딩을 SAML 제공자 샘플 바인딩에 추가하여 호출자 ID를 나타내는 수신된 SAML 토큰을 선택할 수 있습니다. 웹 서비스 보안 런타임 환경은 SAML NameId를 사용하여 클라이언트 ID를 표시하고 기본 system.wss.caller JAAS 로그인 구성을 사용할 때 구성된 사용자 레지스트리에서 사용자 보안 이름 및 그룹 멤버십을 검색합니다.

이 시나리오가 실행되고 나면 WS-Security 런타임 환경은 SAML 토큰을 저장하고 토큰이 여전히 유효한 경우 이를 재사용하여 동일한 비즈니스 서비스 제공자에 액세스할 수 있습니다. 토큰은 토큰 만기 시간이 캐시 기간 미만이면(구성 가능함) 유효합니다. 비즈니스 서비스 제공자가 수신된 SAML 토큰을 유효성 검증 및 인증하고 나면 JAAS 주제가 해당 SAML 토큰과 함께 인증 캐시에 저장됩니다. SAML 토큰은 토큰 만기 시간에 상관 없이 호스팅하는 애플리케이션 서버에서 유효하게 유지됩니다. 이는 토큰이 인증 캐시에 있는 한 SAML 토큰이 애플리케이션 서버 프로세스에서 유효하므로, WS-Security 런타임 환경이 동일한 프로세스 내에서는 SAML 토큰 만기 시간을 확인하지 않음을 의미합니다.

SAML 토큰 만기 시간은 비즈니스 서비스 제공자가 다운스트림 서비스를 호출하기 위해 SAML 토큰을 사용할 때 점검됩니다. SAML 토큰 만기 시간이 캐시 기간에 현재 시간을 더한 값 미만이 아니면 아웃바운드 요청이 실패합니다. 이 제한사항은 정책 구성상 원래 SAML 토큰을 사용해야 할 때에도 적용됩니다. 하지만 예를 들어, 비즈니스 서비스 제공자가 원래 SAML 토큰의 복제를 작성하고 서명한 경우처럼 정책 구성이 자체 발행한 SAML 토큰을 대신 사용하는 경우에는 제한사항이 적용되지 않습니다.

시나리오 2: HoK(holder-of-key) 유효성 검증을 통한 웹 서비스 싱글 사인온(SSO)

HoK(holder-of-key) 유효성 검증을 통한 웹 서비스 싱글 사인온 사용 시나리오는 이전의 SSO 사용 시나리오와 유사합니다. HoK(holder-of-key)를 통한 SSO 시나리오는 전달 확인 메소드 대신 HoK(holder-of-key) 확인 메소드로 SAML 토큰을 사용합니다. SAML HoK 토큰은 클라이언트가 키의 소유권 및 토큰의 소유권을 증명하기 위해 사용하는 키를 포함합니다. 이 임베디드 키는 공유 키(대칭 키라고도 함) 또는 공개 키(비대칭 키라고도 함)를 포함한 X.509 인증서일 수 있습니다. 공유 키의 경우 의도한 비즈니스 서비스만 SOAP 메시지를 이용할 수 있도록 대상 비즈니스 서비스 제공자의 공개 키를 사용하여 키가 암호화됩니다.

클라이언트가 STS로부터 HoK 공유 키가 있는 SAML 토큰을 요청하면 STS는 SAML 토큰의 키를 암호화하여 요청한 클라이언트에 WS-Trust 응답으로 동일한 키의 사본을 전송합니다. 이렇게 하지 않으면 클라이언트가 SAML 토큰의 암호화된 키를 읽을 수 없으므로 이 과정이 필요합니다. SAML 토큰의 소유권을 증명하기 위해 클라이언트는 공유 키를 사용하여 SOAP 요청 메시지를 서명하고 암호화합니다. 비즈니스 서비스는 암호화된 공유 키를 추출하고 이를 사용하여 디지털 서명을 확인해서 HoK 토큰 소유권의 유효성을 검증해야 합니다.

다음 다이어그램은 웹 서비스가 시나리오의 SAML 토큰을 요청하는 방법을 보여줍니다.
그림 2. 외부 서비스로부터 SAML 토큰을 요청하는 웹 서비스 1
HoK(holder-of-key) 유효성 검증을 통한 싱글 사인온(SSO) 시나리오

 1  사용자가 SPNEGO를 사용하여 웹 브라우저에 로그온하고 인증됩니다. JAAS 주제가 작성됩니다.

 2  SPNEGO 토큰의 신임 정보는 WS-Trust를 사용하여 SAML 토큰을 요청하는 데 사용됩니다. 신뢰 서버 개인 키로 토큰에 서명합니다.

 3  SAML 토큰의 서명은 신뢰 관계를 기반으로 하여 유효성이 검증됩니다. SAML 토큰의 속성을 사용하여 보안 신임 정보가 작성됩니다. SAML 토큰의 암호 키는 SOAP 메시지를 복호화하는 데 사용됩니다.

다이어그램에 표시된 대로, 브라우저 클라이언트는 Kerberos 신임 정보(SPNEGO 토큰에 표시됨)를 사용하여 웹 애플리케이션에 액세스합니다. Kerberos 신임 정보를 위임할 수 있다는 가정 하에, 웹 애플리케이션은 위임된 클라이언트 Kerberos 신임 정보를 사용하여 클라이언트 대신 STS로부터 SAML 토큰을 요청할 수 있습니다. 예를 들어, 웹 애플리케이션은 클라이언트를 대신하여 키 분배 센터(KDC)에서 클라이언트 승인 요청(APREQ) Kerberos 토큰을 얻을 수 있습니다. 웹 애플리케이션은 그런 다음 클라이언트 APREQ 토큰을 사용하여 STS에 인증하고 클라이언트 대신 STS로부터 클라이언트 SAML 토큰을 요청합니다.

이 예제에서, SAML 토큰은 대칭 키를 사용한 HoK(holder-of-key) 확인 메소드를 필요로 합니다. 웹 애플리케이션은 클라이언트를 대신하여 다운스트림 비즈니스 서비스에 액세스하기 위해 SAML 토큰을 사용하므로, SAML 토큰은 클라이언트를 다운스트림 서비스에 인증하고 디지털 서명 및 암호화를 사용하여 요청 메시지도 보호합니다. HoK 토큰의 바인딩을 설정하는 방법에 대한 자세한 정보는 SAML HoK(holder-of-key) 대칭 키 토큰의 클라이언트 및 제공자 바인딩 구성 주제를 참조하십시오.

시나리오가 정상적으로 실행되면 대상 비즈니스 서비스는 다운스트림 비즈니스 서비스가 임베디드 키를 추출할 수 있는 경우 SAML 토큰을 사용하여 시나리오에 설명된 동일한 프로시저에 따라 다른 다운스트림 서비스에 액세스할 수 있습니다. 또는 개인 키 분배를 피하기 위해 자체 발행한 SAML 토큰을 사용하여 다운스트림 서비스에 액세스하도록 비즈니스 서비스를 구성할 수 있습니다.

시나리오 3: 웹 서비스 연합 ID 관리

연합 ID 관리 사용 시나리오에서는 브라우저 클라이언트가 회사 포털 웹 애플리케이션에 액세스합니다. 이 시나리오는 사용자 이름 및 비밀번호와 같은 기본 사용자 인증 데이터를 사용하여 STS로부터 SAML 토큰을 요청한 후 SAML 토큰을 사용하여 보안 도메인에서 비즈니스 서비스에 액세스합니다. 받는 비즈니스 서비스 제공자는 제공자와 발행 STS 사이의 신뢰 관계를 기반으로 하여 SAML 토큰의 유효성을 검증하며, 제공자가 사용자의 ID 및 속성을 어설션하기도 합니다. 이는 이전에 대상 비즈니스 서비스의 사용자 디렉토리에 사용자를 정의할 필요가 없음을 의미합니다. 이 시나리오의 장점은 여러 사용자를 하나의 사용자 디렉토리 서비스로 통합할 필요 없이 많은 비즈니스 파트너의 비즈니스 서비스를 연합할 보다 관리 가능한 방법을 제공한다는 점입니다.

그림 3. 사용자가 회사 포털에 로그온하고 연합 ID 관리를 사용하여 비즈니스 서비스에 액세스함
연합
ID 관리 시나리오

 1  사용자가 사용자 이름 및 비밀번호로 로그온하고 회사 포털에 인증됩니다. JAAS 주제가 작성됩니다.

 2  사용자 이름과 비밀번호를 사용하여 STS에 인증하고 사용자를 나타내는 SAML 토큰을 요청합니다.

 3  SAML 토큰의 서명은 신뢰 관계를 기반으로 하여 유효성이 검증됩니다. SAML 토큰의 속성을 사용하여 보안 신임 정보가 작성됩니다. SAML 토큰의 암호 키는 SOAP 메시지를 복호화하는 데 사용됩니다.

기본 시스템 로그인 구성, wss.caller는 SAML 토큰에 표시된 사용자 ID를 구성된 사용자 디렉토리의 사용자 ID로 맵핑합니다. 사용자 정의 로그인 모듈을 wss.caller 로그인 구성에 추가하여 SAML 토큰 사용자 ID를 다른 보안 도메인에서 애플리케이션 서버로 어설션해야 합니다. 이 사용자 정의 로그인 모듈은 SAML 토큰 사용자 ID 및 기타 속성을 추출하여 애플리케이션 서버에 사용되는 어설션 특성을 구성합니다. 이 중 두 개의 특성인 사용자 이름 및 사용자 ID가 애플리케이션 서버에 필요합니다. 두 특성이 ID 어설션에서 제공되므로 애플리케이션 서버가 로컬 사용자 디렉토리에 대해 사용자 이름의 유효성을 검증할 필요가 없습니다.

사용자 그룹 멤버십에 대한 정보가 애플리케이션 서버에 제공될 수도 있습니다. 이 정보는 사용자의 애플리케이션 서버 보안 신임 정보를 나타내는 WSCredential 오브젝트를 구성하는 데 사용됩니다. JAAS LoginContext 공유 상태를 사용하여 사용자 특성이 애플리케이션 서버 WSWSSLoginModule로 전달됩니다. 이 특성에 대한 자세한 정보는 인바운드 ID 맵핑 구성에 대한 주제를 참조하십시오.

시나리오 4: 사용자 정의 싱글 사인온(SSO) 솔루션

사용자 정의 싱글 사인온(SSO) 사용 시나리오는 SAML 토큰 라이브러리 API, WS-Trust 클라이언트 API, 기타 애플리케이션 서버 API, SPI를 사용하여 사용자 정의한 SSO 솔루션을 특정 비즈니스 컴퓨팅 환경에 맞게 빌드합니다. 이 시나리오에 대한 다이어그램은 사용자가 인증된 후 회사 서버와 신뢰 관계가 있는 ID 제공자로부터 SAML 토큰을 발행한 예제를 보여줍니다. 이 시나리오에서 회사는 사용자에게 추가 인증을 요구하지 않은 채 신뢰 관계를 바탕으로 사용자에게 보호 웹 애플리케이션에 대한 액세스를 부여하려 합니다.

웹 브라우저와 같은 웹 애플리케이션 클라이언트는 웹 서비스 프로토콜을 사용하는 대신 HTTPS 프로토콜을 사용하여 애플리케이션 서버로 SAML 토큰을 전달합니다. 이 요청을 인터셉트하고 전달하기 위해 회사는 애플리케이션 서버 TAI(Trust Association Interceptor) API를 구현하는 SAML TAI를 빌드합니다. SAML TAI는 SAML 토큰 라이브러리 API를 사용하여 SAML 토큰을 유효성 검증 및 인증합니다. 또는 SAML TAI가 WS-Trust 클라이언트 API를 사용하여 외부 STS에 대해 SAML 토큰을 유효성 검증 및 인증할 수 있습니다. TAI 인터페이스에 대한 자세한 정보는 신뢰 연관에 대한 사용자 정의 인터셉터 개발 주제를 참조하십시오. 사용자 정의 SAML TAI는 WebSphere Application Server와 함께 제공되지 않습니다.

그림 4. 사용자가 HTTPS 프로토콜을 사용하여 웹 브라우저가 있는 회사 서버에 로그온하고 SAML TAI를 사용하여 인증됨
사용자 정의 싱글 사인온(SSO) 시나리오

 1  사용자가 사용자 이름 및 비밀번호를 사용하여 ID 제공자에 로그온합니다. ID 제공자는 사용자에게 SAML 토큰을 발행합니다.

 2  SAML TAI는 SAMLTokenFactory API를 사용하여 SAML 토큰의 유효성을 검증하고 SAML 토큰을 인증해서 사용자 신임 정보를 작성합니다. SAML TAI는 WS-Trust 클라이언트 API를 사용하여 외부 STS에 대해 SAML 토큰의 유효성을 검증할 수도 있습니다.

SAML API에 대한 자세한 정보는 WS-Trust 클라이언트 API 및 SAML 토큰 라이브러리 API 주제를 참조하십시오.

보다 복잡한 솔루션: 다중 보안 도메인

이 문서의 이전 섹션에서는 네 개의 기본 사용 시나리오를 설명합니다. 하지만 다중 보안 도메인 경계에 SAML 토큰을 어설션하려는 경우도 있습니다. 이 솔루션에 대한 자세한 정보는 WebSphere Application Server 보안 도메인의 SAML 어설션에 관한 문서를 참조하십시오.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_samlusagescenarios
파일 이름:cwbs_samlusagescenarios.html