Liberty: 인증
Liberty 보안에서 인증은 사용자의 ID를 확인하기 위한 것입니다.
보호된 웹 자원에 액세스하려면 사용자가 신임 데이터(예: 사용자 ID 및 비밀번호)를 제공해야 합니다. 인증 프로세스는 이 사용자 신임 정보 수집(이 데이터를 수집하기 위한 웹 애플리케이션의 구성 방법에 따라) 및 구성된 레지스트리에 대한 유효성 검증과 관련됩니다. 신임 정보가 확인된 경우, JAAS 주제가 해당 사용자에 대해 작성됩니다. 주제에는 사용자가 속한 그룹, 해당 사용자에 대해 작성된 토큰과 같이 사용자에 관한 자세한 정보가 포함되어 있습니다. 이 주제의 정보는 권한 부여 프로세스 중 사용되어 사용자가 자원에 액세스할 수 있는지 여부를 판별하는 데 사용됩니다.
다음 다이어그램은 웹 자원에 대한 일반 인증 프로세스 플로우를 설명합니다.

인증 프로세스는 사용자로부터 신임 정보 데이터를 수집하고, 캐시를 검사하여 주제가 해당 사용자에 대해 존재하는지 여부를 확인하고 부재 시 JAAS 서비스를 호출하여 인증을 수행하고 주제를 작성하는 것과 관련됩니다. JAAS 서비스는 로그인 모듈 세트를 호출하여 인증을 처리합니다. 하나 이상의 로그인 모듈은 신임 정보 데이터에 따라 주제를 작성합니다. 로그인 모듈은 신임 정보의 유효성을 검증하기 위해 구성된 레지스트리를 호출합니다. 유효성 검증이 성공한 경우, 인증 프로세스는 사용자가 속한 그룹, 싱글 사인온(SSO) 기능을 위해 사용된 SSO 토큰을 포함한 해당 사용자에 대한 관련 정보를 수집하고 작성하며 관련 신임 정보로 주제에 저장합니다. 이 프로세스 중 사용자 정의 로그인 모듈에 연결하여 주제에 저장한 정보를 사용자 정의할 수도 있습니다.
사용자 레지스트리
사용자의 인증 데이터의 유효성을 검증하는 경우, 로그인 모듈은 사용자 정보의 유효성을 검증하도록 구성된 사용자 레지스트리를 호출합니다. Liberty는 단순 구성 기반 사용자 레지스트리와 보다 강력한 LDAP 기반 레지스트리를 모두 지원합니다. 자세한 정보는 Liberty에서 사용자 레지스트리 구성의 내용을 참조하십시오.
LDAP 레지스트리를 사용할 때, 여러 저장소를 연합하고 두 개 이상의 레지스트리에서 LDAP 조작을 실행할 수도 있습니다. Liberty 사용자는 server.xml 파일에서 직접 LDAP 레지스트리 연합 기능을 구성하거나, 개발자 도구의 LDAP 레지스트리 연합 섹션에서 이를 구성할 수 있습니다. 연합 저장소 구성 후에, 수행하려고 하는 조작에 대해 연합 저장소의 통합 결과를 확보할 수 있습니다. 예를 들어, test로 시작하는 모든 사용자 이름에 대해 검색 조작을 수행하려는 경우, LDAP 레지스트리 세트에서 검색을 수행하고, 호출하는 프로그램으로 다시 발송될 수 있는 통합 검색 결과를 가져올 수 있습니다.
인증 캐시
주제 작성은 상대적으로 과도한 비용을 요구하므로, Liberty는 사용자의 인증이 성공한 후에 주제를 저장할 수 있도록 인증 캐시를 제공합니다. 캐시의 기본 만기 시간은 10분입니다. 사용자가 10분 이내에 다시 로그인하지 않는 경우, 주제가 제거되며 인증 프로세스가 반복되어 해당 사용자의 주제를 작성합니다. 주제 작성에 영향을 미치는 구성을 변경하면(예: 로그인 모듈 추가 또는 LTPA 키 변경) 인증 캐시가 지워집니다. 주제가 캐시되고 레지스트리의 정보가 변경되면 캐시가 레지스트리의 정보로 업데이트됩니다. 캐시 제한시간과 캐시 크기를 구성할 수 있으며 캐싱을 사용하거나 사용하지 않도록 설정할 수도 있습니다. 자세한 정보는 Liberty에서 인증 캐시 구성의 내용을 참조하십시오.
JAAS 구성
- system.WEB_INBOUND
- 서블릿 및 JSP와 같은 웹 자원에 액세스할 때 사용됩니다.
- WSLogin
- 애플리케이션이 프로그래밍 방식 로그인을 사용할 때 사용됩니다. 이는 애플리케이션 클라이언트 컨테이너에서 실행 중인 애플리케이션에 의해서도 사용됩니다. 그러나 ClientContainerJAAS 구성과는 달리, 이는 클라이언트 애플리케이션 모듈의 배치 디스크립터에 지정된 CallbackHandler 핸들러를 인식하지 않습니다.
- system.DEFAULT
- 지정된 JAAS 구성이 없는 경우 로그인에 사용됩니다.
- system.DESERIALIZE_CONTEXT
- 보안 컨텍스트를 역직렬화할 때 사용됩니다. 이 JAAS 구성은 보안 컨텍스트가 직렬화될 때 스레드에서 활성 상태였던 주제를 다시 작성하기 위해 인증을 처리합니다. 이 JAAS 구성을 지정하고 server.xml 파일에서 JAAS 구성 항목을 편집하여 자체 사용자 정의 JAAS 로그인 모듈을 추가하여 전파된 주제에 사용자 정의 정보가 포함되도록 할 수 있습니다.
- ClientContainer
- 애플리케이션 클라이언트 컨테이너에서 실행 중인 애플리케이션에 의해 사용됩니다. 이 JAAS 로그인 구성은 클라이언트 애플리케이션 모듈의 배치 디스크립터에 지정된 CallbackHandler 핸들러를 인식합니다(지정된 경우).
사용자 정의 로그인 모듈로 사용자 정의하지 않으려면 명시적 구성이 필요하지 않습니다. 요구사항에 따라, 특정 로그인 구성을 사용자 정의할 수 있습니다. 예를 들어, 모든 웹 자원 로그인을 사용자 정의하려면, 사용자 정의 로그인 모듈만 system.WEB_INBOUND 구성에 추가해야 합니다. Liberty에 대한 JAAS 사용자 정의 로그인 모듈 구성을 확인하십시오.
JAAS 로그인 모듈
JAAS 구성이 로그인 모듈 세트를 사용하여 주제를 작성합니다. Liberty는 각 로그인 구성에서 로그인 모듈 세트를 제공합니다. 인증 데이터에 따라, 특정 로그인 모듈은 주제를 작성합니다. 인증 데이터는 JAAS 스펙에 지정된 대로 콜백 핸들러를 사용하여 로그인 모듈에 전달됩니다. 예를 들어, 사용자 ID와 비밀번호 콜백 핸들러가 인증에 사용되면, userNameAndPassword 로그인 모듈은 인증을 처리합니다. SingleSignonToken 신임 정보가 인증 데이터로 표시된 경우, 토큰 로그인 모듈만 인증을 처리합니다.
- userNameAndPassword
- 사용자 이름 및 비밀번호가 인증 데이터로 사용된 경우 인증을 처리합니다.
- certificate
- X509 인증서가 상호 SSL의 인증 데이터로 사용된 경우 인증을 처리합니다.
- token
- SSO 토큰이 인증 데이터로 표시된 경우 인증을 처리합니다. 인증 프로세스 중, SSO 토큰이 작성되며 쿠키를 통해 HTTP 클라이언트(브라우저)로 다시 발송됩니다. 후속 요청에서, 이 쿠키를 브라우저에서 다시 보내고 서버는 토큰을 쿠키에서 추출하여 싱글 사인온이 사용되는 경우 사용자를 인증합니다.
- hashtable
- 인증된 데이터가 사전 정의된 해시 테이블을 통해 발송되는 경우에 사용됩니다. 해시 테이블 로그인에 대한 자세한 정보는 해시 테이블 로그인 모듈의 내용을 참조하십시오. 인증이 ID만을 사용하여 수행되는 경우(예: runAs의 경우) 이 로그인 모듈은 보안 런타임에서도 사용됩니다.
- proxy
- WSLogin의 기본 로그인 모듈입니다. 프록시 로그인 모듈을 확인하십시오.
로그인 모듈은 구성되는 순서대로 호출됩니다. 기본 순서는 hashtable, userNameAndPassword, certificate, token입니다. 사용자 정의 로그인 모듈을 사용하여 로그인 프로세스를 사용자 정의해야 하는 경우, 필요한 순서대로 제공하고 구성할 수 있습니다. 일반적으로, 사용자 정의 로그인 모듈은 로그인 모듈의 목록에서 첫 번째 모듈이며 처음으로 호출됩니다. 사용자 정의 로그인 모듈이 사용되는 경우, 필요한 순서대로 사용자 정의 로그인 모듈과 함께 구성에서 모든 로그인 모듈 정보를 지정해야 합니다.
로그인 모듈이 인증을 처리할 수 있다고 판별한 경우, 먼저 전달된 인증 데이터가 유효한지 확인해야 합니다. 예를 들어, 사용자 이름 및 비밀번호 인증의 경우, 구성된 사용자 레지스트리가 호출되어 해당 정보를 확인합니다. 토큰 인증의 경우, 토큰이 복호화되고 유효해야 검증에 성공할 수 있습니다.
인증 데이터 유효성이 검증되면, 로그인 모듈은 그룹 및 SSO 토큰을 포함한 사용자에 대한 추가 데이터로 신임 정보를 작성합니다. 사용자 정의 로그인 모듈은 고유 신임 정보를 작성하여 추가 데이터를 주제에 추가할 수 있습니다. Liberty 권한이 작동되려면 주제에 WSCredential, WSPrincipal 및 SingleSignonToken 신임 정보가 포함되어야 합니다. WSCredential 신임 정보에는 그룹 정보와 보안 런타임 환경에 필요한 추가 정보가 포함되어 있습니다.
콜백 핸들러
Liberty는 JAAS 인증 프로세스 중에 로그인 모듈에 데이터를 제공하기 위한 다양한 콜백 핸들러를 지원합니다. 사용자 정의 로그인 모듈은 콜백 핸들러 정보를 사용하여 고유 인증을 수행할 수 있습니다. 예를 들어, 콜백 핸들러가 HttpServletRequest 오브젝트의 일부 정보에 액세스해야 하는 경우 특정 콜백 핸들러를 사용하여 액세스할 수 있습니다.
- com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
- com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
시스템 로그인 구성의 JAAS 사용자 정의 로그인 모듈 개발을 확인하십시오.
신임 정보와 토큰
loginModule 절에서 언급한 대로 신임 정보는 주제 작성 프로세스의 일부로 작성됩니다. Liberty는 WSCredential, SingleSignonToken 및 WSPrincipal 신임 정보를 작성합니다. SingleSignonToken 신임 정보는 SSO가 작동하도록 쿠키를 통해 브라우저로 다시 보내는 토큰을 포함합니다. 이 토큰은 사용자 정보와 만기 시간을 포함합니다. 처음 서버 시작 중 생성되는 LTPA(Lightweight Third Party Authentication) 키를 사용하여 서명되고 암호화됩니다. 기본 만기 시간은 2시간이며 사용자 활동을 기준으로 하지 않은 절대 시간입니다. 2시간 후, 토큰이 만기되고 자원에 액세스하려면 사용자는 다시 로그인해야 합니다.
LTPA
LTPA는 분산 다중 애플리케이션 서버 환경이어야 합니다. Liberty에서 LTPA는 암호화를 통해 분산 환경에서 SSO 및 보안을 지원합니다. 이 지원으로 LTPA 암호화, 디지털 서명, 인증 관련 데이터의 안전한 전송, 차후 복호화, 서명 확인이 가능합니다.
애플리케이션 서버는 LTPA 프로토콜을 사용하여 안전하게 통신할 수 있습니다. 또한 프로토콜은 SSO 기능을 제공하므로, 사용자는 DNS(Domain Name System)에 연결할 때만 인증해야 합니다. 그리고 사용자는 프롬프트 없이 동일한 도메인에 있는 다른 Liberty 서버의 자원에 액세스할 수 있습니다. DNS 도메인에 있는 각 시스템의 영역 이름은 대소문자를 구분하며 동일하게 일치되어야 합니다.
LTPA 프로토콜은 암호화 키를 사용하여 서버 간 전달되는 사용자 데이터를 암호화하고 복호화합니다. 관련된 모든 서버가 동일한 사용자 레지스트리를 사용한다는 전제하에 한 서버의 자원이 다른 서버의 자원에 액세스하도록 다른 서버 간에 이 키를 공유해야 합니다. LTPA를 사용하려면 구성된 사용자 레지스트리가 중앙 집중식으로 공유된 저장소여야 하므로 서버와 상관 없이 사용자와 그룹이 동일합니다.
LTPA 사용 시, 토큰은 사용자 정보와 만기 시간으로 작성되며 키로 서명됩니다. LTPA 토큰은 시간에 민감합니다. 참여하는 모든 서버는 시간과 날짜가 동기화되어 있어야 합니다. 그렇지 않은 경우, LTPA 토큰은 너무 빨리 만기되어 인증 또는 유효성 검증이 실패합니다. 협정 세계시(UTC)가 기본적으로 사용되며 기타 모든 서버는 동일 UTC 시간을 가져야 합니다. 서버 간 동일한 UTC 시간을 확인하는 방법에 관한 정보는 운영 체제 문서를 참조하십시오.
SSO가 사용되는 경우 LTPA 토큰은 웹 자원의 쿠키를 통해 다른 서버로 전달됩니다.
수신 서버가 동일한 키를 원래 서버로 사용하는 경우, 사용자 정보를 얻기 위해 토큰을 복호화할 수 있습니다. 이를 통해 유효성을 검증하여 토큰이 만료되지 않았으며 토큰의 사용자 정보가 해당 레지스트리에서 유효한지를 확인할 수 있습니다. 유효성 검증에 성공하면 권한 검사 후 수신 서버의 자원에 액세스 가능합니다.
각 서버에는 유효한 신임 정보가 있어야 합니다. 신임 정보가 만기되면, 사용자 레지스트리와 통신하여 인증해야 합니다. LTPA 토큰이 캐시된 상태로 유지되는 시간을 늘리면 보안 정책을 정의할 때 고려해야 할 보안 위험이 다소 증가하는 것으로 나타납니다.
서로 다른 Liberty 서버 간에 키 공유가 필요한 경우에는 키를 한 서버에서 다른 서버로 복사하십시오. 보안 용도로, 키는 랜덤으로 생성된 키로 암호화되며 사용자 정의된 비밀번호가 사용되어 키를 보호합니다. 키를 다른 서버로 가져오는 경우 동일한 이 비밀번호가 필요합니다. 비밀번호는 키를 보호하는 데만 사용되며 키를 생성하는 데는 사용되지 않습니다.
보안이 사용되는 경우, LTPA는 기본적으로 Liberty 서버 시작 시간 중에 구성됩니다. LTPA 지원에 관한 자세한 정보는 Liberty에서 LTPA 구성의 내용을 참조하십시오.
OpenID
OpenID는 사용자가 여러 계정 또는 신임 세트를 관리하지 않고 자신을 여러 엔티티에 대해 인증할 수 있는 개방형 인증 표준입니다. Liberty는 신뢰 당사자로 기능하여 OpenID Authentication 2.0 표준을 지원합니다. 이 표준에서 신뢰 당사자는 OpenID 제공자로부터 인증 확인을 받아야 합니다. 신뢰 당사자에게 신임 정보를 제공하는 대신, 사용자가 신임 정보를 제출하도록 OpenID 제공자로 경로 재지정됩니다. OpenID 제공자는 신뢰 당사자를 통해 인증 결과를 확인하고 사용자 이름 또는 이메일 주소와 같이 사용자가 승인한 개인 정보의 서브세트와 함께 사용자가 소유한 고유 ID를 리턴합니다. 그러면 신뢰 당사자는 이 정보를 사용하여 사용자의 신임 정보를 처리하지 않고도 인증을 완료할 수 있습니다. 또한 사용자는 OpenID 제공자에서 단일 계정을 사용하여 각 엔티티에 대한 고유한 계정을 작성하거나 관리하지 않는 신뢰 당사자 역할을 수행하는 엔티티로 사용자를 인증할 수 있습니다.
OpenID에 대한 자세한 정보는 OpenID의 내용을 참조하십시오.Liberty 서버에 OpenID를 구성하는 데 관한 정보는 Liberty에서 OpenID 신뢰 당사자 구성의 내용을 참조하십시오.
OpenID Connect
OpenID Connect는 OAuth 2.0 프로토콜에 빌드되는 단순 ID 프로토콜 및 개방형 표준입니다. OpenID Connect를 통해 클라이언트 애플리케이션이 사용자의 ID를 확인하기 위해 OpenID Connect 제공자가 수행하는 인증에 의존할 수 있게 합니다.
클라이언트 애플리케이션은 OpenID Connect 제공자로부터 상호 운용 가능한 REST와 비슷한 방식으로 일반 사용자에 대한 기본 프로파일 정보를 얻을 수도 있습니다. OpenID Connect 지원은 OpenID Connect 표준 v1.0에 기반합니다.
OpenID Connect에 대한 자세한 정보는 OpenID Connect를 참조하십시오. Liberty 서버에서 OpenID Connect 클라이언트 또는 신뢰 당사자 구성에 대한 정보는 Liberty에 OpenID Connect 클라이언트 구성의 내용을 참조하십시오. Liberty 서버에서 OpenID Connect 제공자 구성에 대한 정보는 Liberty에서 OpenID Connect 제공자 구성의 내용을 참조하십시오.
SPNEGO
SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)를 사용하면 사용자가 Microsoft 도메인 제어기에 한 번 로그인한 후 프롬프트를 다시 표시하지 않고 Liberty 서버의 보호된 애플리케이션에 액세스할 수 있습니다.
SPNEGO 웹 인증이 사용으로 설정되어 있을 때 브라우저 클라이언트가 Liberty 서버의 보호된 자원에 액세스하는 경우 SPNEGO는 HTTP 요청에서 식별되는 보안 설정된 자원에 대한 액세스의 인증을 처리합니다. 브라우저 클라이언트는 SPNEGO 토큰을 작성한 후에 이를 HTTP 요청의 일부로 Liberty 프로파일 서버에 전송합니다. WebSphere Application Server는 SPNEGO 토큰으로부터 사용자 ID를 유효성 검증하고 검색합니다. 이 ID는 사용자와 애플리케이션 서버 간 보안 컨텍스트를 설정하는 데 사용됩니다.
SPNEGO에 대한 자세한 정보는 SPNEGO 웹 인증을 사용한 HTTP 요청에 대한 싱글 사인온의 내용을 참조하십시오. Liberty 서버에서 SPNEGO 구성에 대한 자세한 정보는 Liberty에서 SPNEGO 인증 구성의 내용을 참조하십시오.
SPNEGO에 대한 Kerberos 강제 위임
Kerberos 강제 위임 기능은 .NET 서버 및 기타 Liberty 서버 등의 SPNEGO 인증을 지원하는 백엔드 서비스에 대한 아웃바운드 SPNEGO 토큰을 작성하는 데 사용되는 두 개의 API를 제공합니다.
- S4U2self
Liberty 서버가 사용자 대신 자신에 대한 서비스 티켓을 가져올 수 있도록 허용합니다. 이는 Liberty에서 지원하는 인증 양식과 함께 사용될 수 있습니다. S4U2self는 Kerberos 프로토콜 상태 전이 확장기능입니다.
- S4U2proxy
Liberty 서버가 사용자 대신 신뢰 서비스에 대한 서비스 티켓을 가져올 수 있도록 허용합니다. 이 서비스 티켓은 Liberty 서비스에 대한 사용자의 서비스 티켓을 사용하여 가져옵니다. 이 서비스는 KDC(Kerberos Key Distribution Center) 관리자에 의해 강제됩니다. S4U2proxy는 Kerberos 제한 위임 확장기능입니다.
싱글 사인온(SSO)
SSO를 사용하면 사용자가 한 위치(예: 한 서버)에 로그인하여 다시 프롬프트를 표시하지 않고 다른 서버의 애플리케이션에 액세스할 수 있도록 합니다. SSO를 작동하려면, LTPA 키가 서로 다른 Liberty 서버에서 교환되어야 하며 사용자 레지스트리가 동일하고 토큰이 만료되지 않아야 합니다. LTPA 키를 교환하려면, ltpa.keys 파일을 한 서버에서 다른 서버로 복사하고 서버를 다시 시작하여 새 LTPA 키를 사용할 수 있습니다. SSO 도메인에 참여 중인 모든 서버에서 사용된 레지스트리가 동일해야 합니다.
사용자가 하나의 Liberty 서버에서 인증된 경우, 인증 프로세스 중에 사용자에 대해 작성된 SSO 토큰은 브라우저와 같은 HTTP 클라이언트에 전송된 쿠키에 배치됩니다. 첫 번째 서버에서 SSO 구성의 일부로 구성되었던 동일 DNS이지만 다른 서버에 있는 다른 애플리케이션 세트에 액세스하기 위한 해당 클라이언트로부터의 다른 요청이 있는 경우, 쿠키가 요청과 함께 발송됩니다. 수신 서버는 쿠키의 토큰을 사용하여 사용자를 인증하려고 하고 두 조건 모두 충족되는 경우, 수신하는 서버는 토큰의 유효성을 검증하고 사용자가 다시 로그인하도록 프롬프트를 표시하지 않고 이 서버의 사용자를 기반으로 주제를 작성합니다. 토큰의 유효성을 검증할 수 없는 경우(예를 들어, LTPA 키 불일치로 토큰을 복호화 또는 확인할 수 없는 경우), 사용자가 신임 정보를 다시 입력하도록 프롬프트가 표시됩니다.
Form-login 속성을 사용하도록 구성된 애플리케이션에서는 해당 서버에 대해 SSO를 구성해야 합니다. 사용자가 form-login에 대해 인증된 경우, 토큰은 자원 액세스 시 사용자에게 권한 부여하는 데 사용될 브라우저로 다시 발송됩니다.
Liberty에서 LTPA 쿠키를 사용하여 SSO 구성 사용자 정의의 내용을 확인하십시오.
SAML 웹 브라우저 SSO
SAML 웹 브라우저 싱글 사인온(SSO)을 사용하여 웹 애플리케이션은 구성된 사용자 레지스트리 대신 SAML ID 제공자에 사용자 인증을 위임할 수 있습니다.
Liberty 서버에서 SAML 웹 브라우저 SSO 구성에 대한 자세한 정보는 SAML 2.0 웹 브라우저 싱글 사인온의 내용을 참조하십시오.
연결 가능한 인증
- 사용자 정의 로그인 모듈을 제공하십시오. 대부분의 인증 프로세스가 주로 JAAS 로그인 모듈에 기반하여 빌드되므로, Liberty에서 제공하는 로그인 모듈의 앞, 뒤 또는 그 사이에서 사용자 정의 로그인 모듈을 플러그인할 수 있습니다. Liberty에 대한 JAAS 사용자 정의 로그인 모듈 구성을 확인하십시오.
- 모든 웹 자원 기반 인증을 처리하도록 신뢰 연관 인터셉터(TAI)를 구현하십시오. Liberty에 대한 사용자 정의 TAI 개발을 확인하십시오.
JAAS 로그인 모듈 및 TAI에 대한 자세한 정보는 WebSphere Application Server의 고급 인증을 참조하십시오.
ID 어설션
요청 엔티티가 자체 ID를 입증하도록 요구하는 인증 이외에도 Liberty는 ID 어설션도 지원합니다. ID 교정이 필요하지 않은 느슨한 양식의 인증이지만 어설션 ID를 보증하는 엔티티와의 신뢰 관계에 기반하여 ID를 수락합니다.
- 해시 테이블 로그인을 사용하십시오. 시스템 로그인 구성의 JAAS 사용자 정의 로그인 모듈 개발을 확인하십시오.
- IdentityAssertionLoginModule을 사용하십시오. 애플리케이션이나
시스템 제공업체가 신뢰 유효성 검증으로 ID 어설션을
수행할 수 있습니다. IdentityAssertionLoginModule을 사용하려면,
JAAS 로그인 프레임워크를 사용할 수 있습니다. 여기서, 신뢰 유효성 검증은
하나의 사용자 정의 로그인 모듈에 함께 제공되며 신임 정보 작성은
IdentityAssertionLoginModule에서 수행됩니다. 두 로그인 모듈을 사용하여
ID 어설션을 수행하는 데 사용될 수 있는 JAAS 로그인 구성을 작성할 수 있습니다. 다음 두 사용자 정의 로그인 모듈이 필요합니다.JAAS를 사용하여 ID 어설션을 수행하도록 애플리케이션 로그인 사용자 정의의 내용을 확인하십시오.
- 사용자가 구현한 로그인 모듈(신뢰 유효성 검증)
- 사용자가 필요로 하는 신뢰 검증에 관계없이
사용자가 구현한 로그인 모듈이 수행됩니다. 신뢰가 확인된 경우, 신뢰 검증 상태 및
로그인 ID가 로그인 모듈의 공유 상태 맵에 배치되어야 신임 정보 작성 로그인
모듈이 해당 정보를 사용할 수 있습니다. 이 맵을 다음 특성에 저장하십시오.
이 특성은 다음 특성으로 구성됩니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
신뢰되는 경우 이 특성은 true로 설정되며 그렇지 않은 경우 false로 설정됩니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
이 특성은 ID의 프린시펄을 포함합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
이 특성은 ID의 인증서를 포함합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
- ID 어설션 로그인 모듈(신임 정보 작성)
- 다음 모듈은 신임 정보를 작성합니다.
이 모듈은 로그인 컨텍스트의 공유 상태에 있는 신뢰 상태 정보를 사용합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
ID 어설션 로그인 모듈은 공유 상태 특성의 신뢰 정보를 찾습니다.
이 특성은 로그인할 때 사용되는 ID 및 신뢰 상태를 포함하며 다음 특성을 포함해야 합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
신뢰되는 경우 이 특성은 true로 설정되며 그렇지 않은 경우 false로 설정됩니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
프린시펄 사용 시 이 특성은 로그인할 때 사용되는 ID의 프린시펄을 포함합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
이 특성은 인증서 사용 시 로그인할 때 사용되는 ID를 포함하는 인증서 체인의 배열을 포함합니다.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
상태, 신뢰 또는 ID 정보가 누락된 경우 WSLoginFailedException 메시지가 리턴됩니다. 그런 다음 로그인 모듈은 ID로 로그인하고 주제는 새 ID를 포함합니다.
RunAs() 인증
- 기본 동작인 호출자 ID를 전파합니다.
- RunAs 스펙을 사용하여 지정할 수 있는 RunAs ID로 위임합니다.
서버가 원래 사용자를 인증한 후, 서버는 RunAs 사용자를 인증합니다. 이 인증이 실패하면 서버는 호출자 ID 전파로 다시 후퇴합니다.
RunAs 스펙을 사용하기 위해서는 run-as 요소 또는 @RunAs 어노테이션을 포함하도록 애플리케이션의 배치 디스크립터를 업데이트해야 합니다. 이 요소를 위임하려는 보안 역할로 설정하십시오.
Liberty에서 RunAs 인증 구성을 확인하십시오.
프록시 로그인 모듈
프록시 로그인 모듈 클래스는 애플리케이션 서버 로그인 모듈을 로드하며 모든 조작을 실제 로그인 모듈 구현에 위임합니다. 실제 로그인 모듈 구현은 옵션 구성의 위임 옵션으로 지정됩니다. 애플리케이션 클래스 로더에서 애플리케이션 서버 제품의 공유 라이브러리 클래스 로더를 볼 수 없으므로 프록시 로그인 모듈이 필요합니다. JAAS 로그인 컨텍스트 항목 WSLogin을 포함한 LoginContext 클래스의 Login() 메소드를 사용하는 애플리케이션 프로그래밍 방식 로그인으로, 프록시 로그인 모듈은 모든 작업을 JAAS 로그인 컨텍스트 항목 system.DEFAULT에 위임합니다.
인증서 로그인
인증서 로그인 기능을 사용하여 사용자 ID와 비밀번호를 제공하는 대신 클라이언트 측 X509 인증서를 사용하는 서블릿과 같은 웹 요청을 인증할 수 있습니다.
식별 이름이 있는 사용자 레지스트리의 사용자를 웹 요청의 클라이언트 인증서의 식별 이름과 연관시켜 인증 작업을 인증하십시오. 신뢰는 서버에서 신뢰한 클라이언트 인증서로 설정됩니다. 예를 들어, 클라이언트 인증서의 서명자는 서버의 신뢰 저장소에 있어야 합니다. 이 메커니즘으로 사용자가 비밀번호를 제공하여 신뢰를 설정하지 않아도 됩니다.
Liberty와의 통신 보안을 확인하십시오.
해시 테이블 로그인 모듈
사용자 레지스트리에서 필수 속성을 검색하여 이 속성을 해시 테이블에 넣은 다음 해당 해시 테이블을 공유 상태에 추가하십시오. 이 로그인 모듈에서 ID가 전환되면 해시 테이블을 공유 상태에 추가해야 합니다. ID가 전환되지 않았지만 requiresLogin 코드 값이 true인 경우 속성의 해시 테이블을 작성할 수 있습니다. Liberty가 사용자 대신 로그인을 처리하므로, 이 상황에서는 해시 테이블을 작성할 필요가 없습니다. 그러나 특수한 경우에 속성을 수집할 해시 테이블을 작성해 볼 수 있습니다. 예를 들어, 사용자 고유한 특수 사용자 레지스트리를 사용할 경우 UserRegistry 구현을 작성하고 해시 테이블을 사용하여 서버에서 사용자 속성을 수집하는 방법이 단순한 솔루션이 될 수 있습니다.
다음 규칙은 해시 테이블 로그인 수행 방법을 자세히 정의합니다. 주제(공용 또는 개인용 신임 정보 세트) 또는 공유 상태 HashMap에서 java.util.Hashtable 오브젝트를 사용해야 합니다. com.ibm.wsspi.security.token.AttributeNameConstants 클래스는 사용자 정보를 포함하는 키를 정의합니다. Hashtable 오브젝트가 해시 테이블 로그인 모듈 이전에 나열되는 사용자 정의 로그인 모듈을 사용하여 로그인 컨텍스트의 공유 상태로 설정되는 경우 공유 상태 hashMap에서 다음 키를 사용하여 java.util.Hashtable 오브젝트의 값이 검색됩니다.
- 특성
- com.ibm.wsspi.security.cred.propertiesObject
- 특성에 대한 참조
- AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
- 설명
- 이 키는 로그인 컨텍스트의 공유 상태에서 필수 특성을 포함하는 Hashtable 오브젝트를 검색합니다.
- 예상 결과
- java.util.Hashtable 오브젝트입니다.
java.util.Hashtable 오브젝트를 주제 또는 공유 상태 영역에서 찾은 경우 다음과 같은 특성이 해시 테이블에 존재하는지 확인하십시오.
- com.ibm.wsspi.security.cred.uniqueId
- 특성에 대한 참조
- AttributeNameConstants.WSCREDENTIAL_UNIQUEID
- 리턴
- java.util.String
- 설명
- 특성 값은 사용자의 고유 표시여야 합니다. Liberty 기본 구현의 경우, 이 특성은 애플리케이션 권한 구성에 저장된 정보를 표시합니다. 정보가 배치되고 사용자 대 역할 맵핑이 수행된 후에는 해당 정보가 애플리케이션 배치 디스크립터에 있습니다. Liberty의 사용자 레지스트리 구현을 찾아봄으로써 사용자 대 역할 맵핑을 수행하는 경우 예상 형식의 예를 참조하십시오.
- 예상 형식 예제
- com.ibm.wsspi.security.cred.uniqueId 특성은 필수입니다.
표 1. 고유 ID의 형식 예제. 이 테이블은 예상 형식 예제를 제공합니다. 사용자 레지스트리 형식(UniqueUserId) 값 LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use 기본 basicRegistryRealm/kelvin
- com.ibm.wsspi.security.cred.securityName
- 특성에 대한 참조
- AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
- 리턴
- java.util.String
- 설명
- 이 특성은 인증 사용자의 securityName을 검색합니다. 이 이름은 보통 표시 이름 또는 축약 이름이라고 합니다. Liberty는 getRemoteUser, getUserPrincipal 및 getCallerPrincipal API(Application Programming Interface)에 대해 securityName 속성을 사용합니다. securityName 값의 기본 구현과 호환되는지 확인하려면 public String getUserSecurityName(String uniqueUserId) UserRegistry 메소드를 호출하십시오.
- 예상 형식 예제
- com.ibm.wsspi.security.cred.securityname 특성은 필수입니다.
표 2. securityName의 형식 예제. 이 테이블은 예상 형식 예제를 제공합니다. 사용자 레지스트리 형식(securityName) 값 LDAP kevin 기본 kevin
- com.ibm.wsspi.security.cred.group
- 특성에 대한 참조
- AttributeNameConstants. WSCREDENTIAL_GROUP
- 리턴
- java.util.ArrayList
- 설명
- 이 키는 사용자가 속하는 그룹의 배열 목록을 검색합니다. 그룹은 realm_name/user_name 형식으로 지정됩니다. Liberty 권한 엔진이 배치 디스크립터의 그룹 대 역할 맵핑을 위해 그룹을 사용하므로, 이 그룹의 형식은 중요합니다. 제공되는 형식은 Liberty 기본 구현으로 예상되는 형식과 일치해야 합니다. 써드파티 권한 제공자를 사용할 경우 써드파티 제공자가 예상한 형식을 사용해야 합니다. 고유 그룹 ID 값의 기본 구현과 호환되는지 확인하려면 public List getUniqueGroupIds(String uniqueUserId) UserRegistry 메소드를 호출하십시오.
- 예상 형식 예제
- com.ibm.wsspi.security.cred.group 특성이 필요합니다. 사용자를 그룹과 연관시키지 않아도 됩니다.
표 3. 그룹의 형식 예제. 이 테이블은 인바운드 ID 맵핑을 구성할 경우 몇 가지 형식 예제를 제공합니다. 사용자 레지스트리 형식(group) 값 LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US 기본 basicRegistryRealm/group1
com.ibm.wsspi.security.cred.realm
- 특성에 대한 참조
- AttributeNameConstants. WSCREDENTIAL_REALM
- 리턴
- java.util.String
- 설명
- 이 키 특성은 LTPA 쿠키에 저장되는 사용자 레지스트리 영역 이름을 지정할 수 있습니다.
- 이 키 특성은 필수가 아닙니다.
- com.ibm.wsspi.security.cred.cacheKey
- 특성에 대한 참조
- AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
- 리턴
- java.lang.Object
- 설명
- 이 키 특성은 고유성에 영향을 줄 수 있는 사용자 동적 속성 및 사용자 특정 정보를 포함하여 로그인의 고유 특성을 나타내는 오브젝트를 지정할 수 있습니다. 예를 들어, 액세스 제어에 영향을 줄 수 있는 A 위치에서 사용자가 로그인하는 경우 수신되는 주제가 현재 위치에서 적절한 주제가 되도록 하려면 캐시 키가 A 위치를 포함해야 합니다.
- 이 com.ibm.wsspi.security.cred.cacheKey 특성은 필요하지 않습니다. 이 특성이 지정되지 않은 경우, 캐시에서 WSCREDENTIAL_UNIQUEID에 대해 지정된 값이 검색됩니다. java.util.Hashtable 오브젝트에서 이 정보를 찾은 경우, Liberty는 최소한 LTPA에 대해 정상 로그인 프로세스를 거치는 주제와 유사한 주제를 작성합니다. 새 주제는 Hashtable 오브젝트에서 찾은 정보로 완전히 채워진 WSPrincipal 오브젝트 및 WSCredential 오브젝트를 포함합니다.