인증

Liberty 보안에서 인증은 사용자의 ID를 확인하기 위한 것입니다.

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

다음 다이어그램은 웹 자원에 대한 일반 인증 프로세스 플로우를 설명합니다.

그림 1. 인증 프로세스 개요 인증 서비스는 JAAS 로그인 모듈을 사용하여 인증을 처리합니다.

인증 프로세스는 사용자로부터 신임 정보 데이터를 수집하고, 캐시를 검사하여 주제가 해당 사용자에 대해 존재하는지 여부를 확인하고 부재 시 JAAS 서비스를 호출하여 인증을 수행하고 주제를 작성하는 것과 관련됩니다. JAAS 서비스는 로그인 모듈 세트를 호출하여 인증을 처리합니다. 하나 이상의 로그인 모듈은 신임 정보 데이터에 따라 주제를 작성합니다. 로그인 모듈은 신임 정보의 유효성을 검증하기 위해 구성된 레지스트리를 호출합니다. 유효성 검증이 성공한 경우, 인증 프로세스는 사용자가 속한 그룹, SSO(싱글 사인온) 기능을 위해 사용된 SSO 토큰을 포함한 해당 사용자에 대한 관련 정보를 수집하고 작성하며 관련 신임 정보로 주제에 저장합니다. 이 프로세스 중 사용자 정의 로그인 모듈에 연결하여 주제에 저장한 정보를 사용자 정의할 수도 있습니다.

인증이 성공한 경우, 이 프로세스 중 작성된 SSO 토큰을 쿠키를 통해 브라우저로 다시 보냅니다. 구성 가능한 쿠키의 기본 이름은 ltpaToken2입니다. 후속 호출에서, 토큰 정보가 사용되어 사용자를 인증합니다. 인증이 실패한 경우, 인증 데이터가 요청에 여전히 존재하면 인증 서비스는 사용자 ID와 비밀번호 같은 기타 인증 데이터를 사용하려고 합니다.
참고: US-ASCII가 아닌 문자를 포함하는 사용자 ID와 비밀번호를 지원하려면 웹 애플리케이션의 로그인 형성 메소드가 필요합니다. 자세한 정보는 autoRequestEncoding 및 autoResponseEncoding을 참조하십시오.

사용자 레지스트리

사용자의 인증 데이터의 유효성을 검증하는 경우, 로그인 모듈은 사용자 정보의 유효성을 검증하도록 구성된 사용자 레지스트리를 호출합니다. Liberty 프로파일은 단순 구성에 기반한 사용자 레지스트리와 보다 강력한 LDAP 기반의 저장소 모두를 지원합니다. 자세한 정보는 Liberty 프로파일을 위한 사용자 레지스트리 구성의 내용을 참조하십시오.

LDAP 레지스트리를 사용할 때, 여러 저장소를 연합하고 두 개 이상의 레지스트리에서 LDAP 오퍼레이션을 실행할 수도 있습니다. Liberty 프로파일 사용자는 LDAP 레지스트리 연합 기능을 server.xml 파일에서 직접 구성하거나, 개발자 도구의 LDAP 레지스트리 연합 섹션에서 구성할 수 있습니다.연합 저장소 구성 후에는 수행할 조작에 대해 연합 저장소의 통합 결과를 얻을 수 있습니다. 예를 들어, test로 시작하는 모든 사용자 이름에 대해 검색 오퍼레이션을 수행하려는 경우, LDAP 레지스트리 세트에서 검색을 수행하고, 호출하는 프로그램으로 다시 발송될 수 있는 통합 검색 결과를 가져올 수 있습니다.

인증 캐시

주제 작성은 상대적으로 시간과 노력을 많이 요하므로 Liberty 프로파일은 인증 캐시를 제공하여 사용자의 인증이 성공한 후 주제를 저장합니다. 캐시의 기본 만기 시간은 10분입니다. 사용자가 10분 이내에 다시 로그인하지 않는 경우, 주제가 제거되며 인증 프로세스가 반복되어 해당 사용자의 주제를 작성합니다. 주제 작성에 영향을 미치는 구성을 변경하면(예: 로그인 모듈 추가 또는 LTPA 키 변경) 인증 캐시가 지워집니다. 주제가 캐시되고 레지스트리의 정보가 변경되면 캐시가 레지스트리의 정보로 업데이트됩니다. 캐시 제한시간과 캐시 크기를 구성할 수 있으며 캐싱을 사용하거나 사용하지 않도록 설정할 수도 있습니다. 자세한 정보는 Liberty 프로파일에 인증 캐시 구성의 내용을 참조하십시오.

JAAS 구성

JAAS 구성이 로그인 모듈 세트를 정의하여 주제를 작성합니다. Liberty 프로파일은 다음 JAAS 구성을 지원합니다.
system.WEB_INBOUND
서블릿 및 JSP와 같은 웹 자원에 액세스할 때 사용됩니다.
WSLogin
애플리케이션이 프로그래밍 방식 로그인을 사용할 때 사용됩니다.
system.DEFAULT
지정된 JAAS 구성이 없는 경우 로그인에 사용됩니다.
[8.5.5.4 이상]system.DESERIALIZE_CONTEXT
[8.5.5.4 이상]보안 컨텍스트를 역직렬화할 때 사용됩니다. 이 JAAS 구성은 보안 컨텍스트가 직렬화될 때 스레드에서 활성 상태였던 주제를 다시 작성하기 위해 인증을 처리합니다. 이 JAAS 구성을 지정하고 server.xml 파일에서 JAAS 구성 항목을 편집하여 자체 사용자 정의 JAAS 로그인 모듈을 추가하여 전파된 주제에 사용자 정의 정보가 포함되도록 할 수 있습니다.
system.WEB_INBOUND 및 system.DEFAULT 구성에는 hashtable, userNameAndPassword, certificate, token 순서의 기본 로그인 모듈이 있습니다.WSLogin은 프록시 로그인 모듈을 기본 로그인 모듈로 사용하며 프록시는 모든 조작을 system.DEFAULT의 실제 로그인 모듈에 위임합니다.

사용자 정의 로그인 모듈로 사용자 정의하지 않으려면 명시적 구성이 필요하지 않습니다. 요구사항에 따라, 특정 로그인 구성을 사용자 정의할 수 있습니다. 예를 들어, 모든 웹 자원 로그인을 사용자 정의하려면, 사용자 정의 로그인 모듈만 system.WEB_INBOUND 구성에 추가해야 합니다. Liberty 프로파일에 대한 JAAS 사용자 정의 로그인 모듈 구성을 확인하십시오.

JAAS 로그인 모듈

JAAS 구성이 로그인 모듈 세트를 사용하여 주제를 작성합니다. Liberty 프로파일은 각 로그인 구성에 로그인 모듈 세트를 제공합니다. 인증 데이터에 따라, 특정 로그인 모듈은 주제를 작성합니다. 인증 데이터는 JAAS 스펙에 지정된 대로 콜백 핸들러를 사용하여 로그인 모듈에 전달됩니다. 예를 들어, 사용자 ID와 비밀번호 콜백 핸들러가 인증에 사용되면, userNameAndPassword 로그인 모듈은 인증을 처리합니다. SingleSignonToken 신임 정보가 인증 데이터로 표시된 경우, 토큰 로그인 모듈만 인증을 처리합니다.

다음 기본 로그인 모듈이 Liberty 프로파일에서 지원됩니다.
userNameAndPassword
사용자 이름 및 비밀번호가 인증 데이터로 사용된 경우 인증을 처리합니다.
certificate
X509 인증서가 상호 SSL의 인증 데이터로 사용된 경우 인증을 처리합니다.
token
SSO 토큰이 인증 데이터로 표시된 경우 인증을 처리합니다. 인증 프로세스 중, SSO 토큰이 작성되며 쿠키를 통해 HTTP 클라이언트(브라우저)로 다시 발송됩니다. 후속 요청에서, 이 쿠키를 브라우저에서 다시 보내고 서버는 토큰을 쿠키에서 추출하여 싱글 사인온이 사용되는 경우 사용자를 인증합니다.
hashtable
인증된 데이터가 사전 정의된 해시 테이블을 통해 발송되는 경우에 사용됩니다. 해시 테이블 로그인에 대한 자세한 정보는 해시 테이블 로그인 모듈의 내용을 참조하십시오. 인증이 ID만을 사용하여 수행되는 경우(예: runAs의 경우) 이 로그인 모듈은 보안 런타임에서도 사용됩니다.
proxy
WSLogin의 기본 로그인 모듈입니다. 프록시 로그인 모듈을 확인하십시오.

로그인 모듈은 구성되는 순서대로 호출됩니다. 기본 순서는 hashtable, userNameAndPassword, certificate, token입니다. 사용자 정의 로그인 모듈을 사용하여 로그인 프로세스를 사용자 정의해야 하는 경우, 필요한 순서대로 제공하고 구성할 수 있습니다. 일반적으로, 사용자 정의 로그인 모듈은 로그인 모듈의 목록에서 첫 번째 모듈이며 처음으로 호출됩니다. 사용자 정의 로그인 모듈이 사용되는 경우, 필요한 순서대로 사용자 정의 로그인 모듈과 함께 구성에서 모든 로그인 모듈 정보를 지정해야 합니다.

로그인 모듈이 인증을 처리할 수 있다고 판별한 경우, 먼저 전달된 인증 데이터가 유효한지 확인해야 합니다. 예를 들어, 사용자 이름 및 비밀번호 인증의 경우, 구성된 사용자 레지스트리가 호출되어 해당 정보를 확인합니다. 토큰 인증의 경우, 토큰이 복호화되고 유효해야 검증에 성공할 수 있습니다.

인증 데이터 유효성이 검증되면, 로그인 모듈은 그룹 및 SSO 토큰을 포함한 사용자에 대한 추가 데이터로 신임 정보를 작성합니다. 사용자 정의 로그인 모듈은 고유 신임 정보를 작성하여 추가 데이터를 주제에 추가할 수 있습니다. Liberty 프로파일 권한이 작동하도록, 주제에는 WSCredential, WSPrincipalSingleSignonToken 신임 정보가 포함되어야 합니다. WSCredential 신임 정보에는 그룹 정보와 보안 런타임 환경에 필요한 추가 정보가 포함되어 있습니다.

콜백 핸들러

Liberty 프로파일은 JAAS 인증 프로세스 중 로그인 모듈에 데이터를 제공하여 여러 콜백 핸들러를 지원합니다. 사용자 정의 로그인 모듈은 콜백 핸들러 정보를 사용하여 고유 인증을 수행할 수 있습니다. 예를 들어, 콜백 핸들러가 HttpServletRequest 오브젝트의 일부 정보에 액세스해야 하는 경우 특정 콜백 핸들러를 사용하여 액세스할 수 있습니다.

프로그래밍 방식 JAAS 로그인에 대한 다음 콜백 핸들러 및 팩토리는 Liberty 프로파일에서 지원됩니다.
  • com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
  • com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
각 Liberty 프로파일 API에 대한 Java API 문서는 Information Center의 프로그래밍 인터페이스(API) 절에 자세히 설명되어 있고 ${wlp.install.dir}/dev 디렉토리의 javadoc 서브디렉토리 중 하나에 별도의 .zip 파일로도 사용 가능합니다.

시스템 로그인 구성의 JAAS 사용자 정의 로그인 모듈 개발을 확인하십시오.

신임 정보와 토큰

loginModule 절에서 언급한 대로 신임 정보는 주제 작성 프로세스의 일부로 작성됩니다. Liberty 프로파일은 WSCredential, SingleSignonTokenWSPrincipal 신임 정보를 작성합니다. 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 프로파일 서버 간에 키 공유가 필요한 경우 키를 한 서버에서 다른 서버로 복사하십시오. 보안상의 이유로 키는 임의로 생성된 키로 암호화되며 키를 보호하기 위해 사용자 정의 비밀번호가 사용됩니다. 키를 다른 서버로 가져오는 경우 동일한 이 비밀번호가 필요합니다. 비밀번호는 키를 보호하는 데만 사용되며 키를 생성하는 데는 사용되지 않습니다.

보안이 사용되는 경우, Liberty 프로파일 서버 시작 시간 중 LTPA가 기본적으로 구성됩니다. LTPA 지원에 관한 자세한 정보는 Liberty 프로파일에서 LTPA 구성의 내용을 참조하십시오.

Liberty Repository[8.5.5.5 이상]

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에 대한 자세한 정보는 Liberty Repository[8.5.5.5 이상]SPNEGO를 참조하십시오. Liberty 프로파일 서버에서 SPNEGO 구성에 대한 자세한 정보는 Liberty Repository[8.5.5.5 이상]Liberty 프로파일에서 SPNEGO 인증 구성을 참조하십시오.

SSO(싱글 사인온)

SSO를 사용하면 사용자가 한 위치(예: 한 서버)에 로그인하여 다시 프롬프트를 표시하지 않고 다른 서버의 애플리케이션에 액세스할 수 있도록 합니다. SSO를 작동하려면 LTPA 키가 다른 Liberty 프로파일 서버에서 교환되어야 하며 사용자 레지스트리는 동일해야 하고 토큰은 만료되기 않아야 합니다. LTPA 키를 교환하려면, ltpa.keys 파일을 한 서버에서 다른 서버로 복사하고 서버를 다시 시작하여 새 LTPA 키를 사용할 수 있습니다. SSO 도메인에 참여 중인 모든 서버에서 사용된 레지스트리가 동일해야 합니다.

사용자가 하나의 Liberty 프로파일 서버에서 인증된 경우, 인증 프로세스 중 사용자에 대해 작성된 SSO 토큰이 브라우저와 같은 HTTP 클라이언트로 보내진 쿠키에 배치됩니다. 첫 번째 서버에서 SSO 구성의 일부로 구성되었던 동일 DNS이지만 다른 서버에 있는 다른 애플리케이션 세트에 액세스하기 위한 해당 클라이언트로부터의 다른 요청이 있는 경우, 쿠키가 요청과 함께 발송됩니다. 수신 서버는 쿠키의 토큰을 사용하여 사용자를 인증하려고 하고 두 조건 모두 충족되는 경우, 수신하는 서버는 토큰의 유효성을 검증하고 사용자가 다시 로그인하도록 프롬프트를 표시하지 않고 이 서버의 사용자를 기반으로 주제를 작성합니다. 토큰의 유효성을 검증할 수 없는 경우(예를 들어, LTPA 키 불일치로 토큰을 복호화 또는 확인할 수 없는 경우), 사용자가 신임 정보를 다시 입력하도록 프롬프트가 표시됩니다.

Form-login 속성을 사용하도록 구성된 애플리케이션에서는 해당 서버에 대해 SSO를 구성해야 합니다. 사용자가 form-login에 대해 인증된 경우, 토큰은 자원 액세스 시 사용자에게 권한 부여하는 데 사용될 브라우저로 다시 발송됩니다.

Liberty 프로파일에 대해 LTPA 쿠키를 사용하여 SSO 구성 사용자 정의을 확인하십시오.

연결 가능한 인증

다음 방법을 사용하여 인증 프로세스를 사용자 정의하십시오.

JAAS 로그인 모듈 및 TAI에 대한 자세한 정보는 WebSphere Application Server의 고급 인증을 참조하십시오.

ID 어설션

ID를 교정하기 위한 요청 엔티티가 필요한 인증 외에도 Liberty 프로파일은 ID 어설션을 지원합니다. ID 교정이 필요하지 않은 느슨한 양식의 인증이지만 어설션 ID를 보증하는 엔티티와의 신뢰 관계에 기반하여 ID를 수락합니다.

다음 방법을 사용하여 Liberty 프로파일에서 ID 어설션을 수행하십시오.
  1. 해시 테이블 로그인을 사용하십시오. 시스템 로그인 구성의 JAAS 사용자 정의 로그인 모듈 개발을 확인하십시오.
  2. IdentityAssertionLoginModule을 사용하십시오. 애플리케이션이나 시스템 제공업체가 신뢰 유효성 검증으로 ID 어설션을 수행할 수 있습니다. IdentityAssertionLoginModule을 사용하려면, JAAS 로그인 프레임워크를 사용할 수 있습니다. 여기서, 신뢰 유효성 검증은 하나의 사용자 정의 로그인 모듈에 함께 제공되며 신임 정보 작성은 IdentityAssertionLoginModule에서 수행됩니다. 두 로그인 모듈을 사용하여 ID 어설션을 수행하는 데 사용될 수 있는 JAAS 로그인 구성을 작성할 수 있습니다.
    다음 두 사용자 정의 로그인 모듈이 필요합니다.
    사용자가 구현한 로그인 모듈(신뢰 유효성 검증)
    사용자가 필요로 하는 신뢰 검증에 관계없이 사용자가 구현한 로그인 모듈이 수행됩니다. 신뢰가 확인된 경우, 신뢰 검증 상태 및 로그인 ID가 로그인 모듈의 공유 상태 맵에 배치되어야 신임 정보 작성 로그인 모듈이 해당 정보를 사용할 수 있습니다. 이 맵을 다음 특성에 저장하십시오.
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    이 특성은 다음 특성으로 구성됩니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      신뢰되는 경우 이 특성은 true로 설정되며 그렇지 않은 경우 false로 설정됩니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      이 특성은 ID의 프린시펄을 포함합니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      이 특성은 ID의 인증서를 포함합니다.
    ID 어설션 로그인 모듈(신임 정보 작성)
    다음 모듈은 신임 정보를 작성합니다.
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
    이 모듈은 로그인 컨텍스트의 공유 상태에 있는 신뢰 상태 정보를 사용합니다.
    ID 어설션 로그인 모듈은 공유 상태 특성의 신뢰 정보를 찾습니다.
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    이 특성은 로그인할 때 사용되는 ID 및 신뢰 상태를 포함하며 다음 특성을 포함해야 합니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      신뢰되는 경우 이 특성은 true로 설정되며 그렇지 않은 경우 false로 설정됩니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      프린시펄 사용 시 이 특성은 로그인할 때 사용되는 ID의 프린시펄을 포함합니다.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      이 특성은 인증서 사용 시 로그인할 때 사용되는 ID를 포함하는 인증서 체인의 배열을 포함합니다.

    상태, 신뢰 또는 ID 정보가 누락된 경우 WSLoginFailedException 메시지가 리턴됩니다. 그런 다음 로그인 모듈은 ID로 로그인하고 주제는 새 ID를 포함합니다.

    JAAS를 사용하여 ID 어설션을 수행하도록 애플리케이션 로그인 사용자 정의을 확인하십시오.

RunAs() 인증

서블릿 호출 후 성공적으로 인증된 경우, 서블릿은 다른 서블릿 등에 대한 후속 호출을 작성할 수 있습니다. 이 후속 호출은 대개 서블릿에 처음 로그인할 때 사용된 것과 동일한 보안 ID로 작성됩니다. 이 ID는 호출자 ID라고도 합니다. 또는, RunAs 스펙을 사용하여 다른 ID로 위임하도록 선택하여 서블릿이 작성한 후속 호출이 이 기타 ID에서 실행되도록 할 수 있습니다. 요약하면, 보안 ID를 전파하기 위한 다음 두 옵션이 있습니다.
  • 기본 동작인 호출자 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 프로파일의 사용자 레지스트리 구현에 대한 검색을 사용하여 사용자 대 역할 맵핑을 수행하는 경우 예상 형식 예제를 참조하십시오.
    예상 형식 예제
    표 1. 고유 ID의 형식 예제. 이 테이블은 예상 형식 예제를 제공합니다.
    사용자 레지스트리 형식(UniqueUserId) 값
    LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use
    기본 basicRegistryRealm/kelvin
    com.ibm.wsspi.security.cred.uniqueId 특성은 필수입니다.
  • com.ibm.wsspi.security.cred.securityName
    특성에 대한 참조
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    리턴
    java.util.String
    설명
    이 특성은 인증 사용자의 securityName을 검색합니다. 이 이름은 보통 표시 이름 또는 축약 이름이라고 합니다. Liberty 프로파일은 getRemoteUser, getUserPrincipalgetCallerPrincipal API(Application Programming Interface)에 securityName 속성을 사용합니다. securityName 값의 기본 구현과 호환되는지 확인하려면 public String getUserSecurityName(String uniqueUserId) UserRegistry 메소드를 호출하십시오.
    예상 형식 예제
    표 2. securityName의 형식 예제. 이 테이블은 예상 형식 예제를 제공합니다.
    사용자 레지스트리 형식(securityName) 값
    LDAP kevin
    기본 kevin
    com.ibm.wsspi.security.cred.securityname 특성은 필수입니다.
  • 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 메소드를 호출하십시오.
    예상 형식 예제
    표 3. 그룹의 형식 예제. 이 테이블은 인바운드 ID 맵핑을 구성할 경우 몇 가지 형식 예제를 제공합니다.
    사용자 레지스트리 형식(group) 값
    LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US
    기본 basicRegistryRealm/group1
    com.ibm.wsspi.security.cred.group 특성이 필요합니다. 사용자를 그룹과 연관시키지 않아도 됩니다.
  • 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 오브젝트를 포함합니다.

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

Information Center 이용 약관 | 피드백


시간소인 아이콘 마지막 업데이트 날짜: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_authentication
파일 이름: cwlp_authentication.html