Access Manager 7 2005Q4 패치 3 (Sun Java System Access Manager 7 2005Q4 릴리스 노트)

Sun Java System Access Manager 7 2005Q4 릴리스 노트

Access Manager 7 2005Q4 패치 3

Access Manager 7 패치 3(개정 03)은 패치에 포함되어 있는 README 파일에 나열된 여러 가지 문제를 해결합니다. 패치 3에는 또한 다음과 같은 새 기능과 알려진 문제가 포함됩니다.

패치 3의 새로운 기능

패치 3의 알려진 문제점 및 제한 사항

사이트 모니터링을 위한 새로운 구성 등록 정보

Access Manager 사이트 모니터링 기능은 다음과 같은 새로운 등록 정보를 포함합니다.

등록 정보	설명
`com.sun.identity.sitemonitor.interval`	사이트 모니터링을 위한 간격 시간(밀리초)입니다. 사이트 모니터링 기능은 각 사이트의 가용성을 지정된 시간 간격마다 확인합니다. 기본값: 60,000밀리초(1분).
`com.sun.identity.sitemonitor.timeout`	사이트 가용성 확인을 위한 시간 초과(밀리초)입니다. 사이트 모니터링 기능은 사이트에서 응답을 위해 지정한 제한 시간만큼 대기합니다. 기본값: 5,000밀리초(5초).

이 패치는 이러한 등록 정보를 AMConfig.properties 파일에 추가하지 않습니다. 이러한 새로운 등록 정보에 기본값이 아닌 다른 값을 사용하려면 다음과 같이 하십시오.

플랫폼에 따라 다음 위치에 있는 AMConfig.properties 파일에 등록 정보와 해당 값을 추가합니다.
- Solaris 시스템: /etc/opt/SUNWam/config
- Linux 시스템: /etc/opt/sun/identity/config
정책 에이전트에 대해서는 이러한 등록 정보를 AMAgents.properties 파일에 추가합니다.
값을 적용하려면 Access Manager 웹 컨테이너를 다시 시작합니다.

사용자 정의 구현. 또한 com.sun.identity.sitemonitor.SiteStatusCheck 클래스는 다음의 인터페이스를 사용하여 사이트 가용성 확인을 위한 구현을 사용자 정의할 수 있도록 해 줍니다.

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

각 구현 클래스는 doCheckSiteStatus 메소드를 사용해야 합니다.

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Liberty Identity Web Services Framework(ID-WSF) 1.1 지원

Access Manager 7 패치 3의 ID-WSF 기본 버전은 WSF1.1입니다. 샘플에서 새로운 보안 메커니즘을 사용해야 하는 경우에만 ID-WSF를 트리거하기 위해 별도로 구성해야 합니다. ID-WSF1.1을 위한 새로운 보안 메커니즘은 다음과 같습니다.

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Liberty ID-WSF 지원을 위한 새로운 등록 정보

Access Manager가 WSC로 동작할 때 프레임워크가 인바운드 메시지나 리소스 제공에서 확인할 수 없는 경우 com.sun.identity.liberty.wsf.version 등록 정보가 Liberty ID-WSF 프레임워크를 확인합니다. 값은 1.0 또는 1.1일 수 있습니다. 기본값은 1.1입니다.

주 패치를 설치하더라도 com.sun.identity.liberty.wsf.version 등록 정보가 AMConfig.properties 파일에 추가되지는 않습니다(CR# 6458184). 이 새로운 등록 정보를 사용하려면 패치를 설치한 다음 AMConfig.properties 파일에 등록 정보와 적절한 값을 추가하고 Access Manager 웹 컨테이너를 다시 시작하십시오.

Access Manager 7 패치 3이 설치되었으면 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager와 함께 표시되는 다음 명령을 실행하여 스키마 변경을 로드합니다.

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

ID-WSF 검색 등록에는 등록 시에 이러한 새로운 보안 메커니즘을 사용할 수 있습니다. WSC는 또한 WSP와의 통신에 어떤 버전을 사용할지를 자동으로 검색합니다. ID-WSF1.1을 구성하려면 제품에 포함된 Liberty ID-FF 샘플 및 ID-WSF 샘플의 Readme 파일의 설명을 따르십시오.

CR# 6463779 분산 인증 `amProfile_Client` 로그 및 Access Manager 서버 `amProfile_Server` 로그가 무해한 예외로 채워집니다.

분산 인증 UI를 통한 Access Manager 서버에 대한 요청은 distAuth/amProfile_Client 로그 및 Access Manager 서버 debug/amProfile_Server 로그에서 예외를 일으킵니다. 다수의 세션을 사용한 다음에는 amProfile_Client 로그의 크기는 몇 GB로 증가하고 Access Manager 서버 amProfile_Server 로그의 크기는 몇 MB로 증가할 수 있습니다. 로그에 이러한 예외가 기록되는 데 따르는 기능 손실은 없지만 사용자에게 잘못된 경고를 전달할 수 있으며 로그가 하드 디스크 공간을 차지할 수 있습니다.

해결 방법: 로그 파일의 내용이 null인 cron 작업을 실행합니다. 예를 들면 다음과 같습니다.

분산 인증 UI 클라이언트 시스템에서 트래픽 분량에 따라 몇 시간마다 "cat /dev/null > distAuth/amProfile_Client"를 실행합니다.
Access Manager 서버에서는 몇 시간이 아닌 며칠마다 "cat /dev/null > /var/opt/SUNWam/debug/amProfile_Server"를 실행합니다.

CR# 6460974 기본 분산 인증 응용 프로그램 사용자는 `amadmin`이 아니어야 합니다.

분산 인증 UI 서버를 배포하는 경우 분산 인증 관리자는 amadmin이 아니어야 합니다. Makefile.distAuthUI 파일의 파일 기본 분산 인증 응용 프로그램 사용자는 amadmin이며 distAuth.war 파일이 클라이언트측이 배포된 후에 이어서 AMConfig.properties 파일도 같습니다. amadmin 세션 시간 제한이 지나면 만료되는 AppSSOToken이 있는 amadmin 사용자는 amSecurity 로그 파일(기본적으로 /tmp/distAuth 디렉토리에 있음)에 FATAL ERROR가 발생하는 원인입니다.

해결 방법: UrlAccessAgent를 분산 인증 응용 프로그램 사용자로 지정합니다. 예를 들면 다음과 같습니다.

클라이언트 웹 컨테이너에 distAuth.war 파일을 배포하기 전에 Makefile.distAuthUI 파일에서 다음 매개 변수를 변경합니다.

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password 또는 amldapuser-password

또는

클라이언트 웹 컨테이너에 distAuth.war 파일을 배포한 다음 각 Access Manager 서버에 대해 AMConfig.properties 파일에서 다음 매개 변수를 변경합니다.

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password 또는 amldapuser-password

CR# 6440697: 분산 인증은 amadmin이 아닌 사용자로 실행해야 합니다.를 참조하십시오.

CR# 6460576 콘솔 온라인 도움말의 필터링된 역할 아래에 사용자 서비스에 대한 링크가 없습니다.

Access Manager 콘솔 온라인 도움말의 필터링된 역할 아래에 사용자 서비스에 대한 링크가 없습니다. 온라인 도움말에서 목차, 필터링된 역할, "필터링된 역할을 만들려면"으로 차례로 이동합니다. 페이지를 아래로 스크롤하면 선택한 identity 유형에 따라 서비스 목록이 표시되지만 사용자 서비스 링크는 사용할 수 없습니다.

해결 방법: 없음

CR# 6460085 `reinstallRTM`을 실행하고 웹 응용 프로그램을 다시 배포한 뒤에 WebSphere의 서버에 액세스할 수 없습니다.

DEPLOY_LEVEL=1 배포를 위한 Access Manager 7 패치 3을 Red Hat Linux AS 3.0 업데이트 4의 IBM WebSphere Application Server 5.1.1.6에 적용한 다음 RTM RPM을 복원하기 위해 reinstallRTM 스크립트를 실행하였습니다. reinstallRTM 스크립트에서 생성한 amsilent 파일을 편집한 다음 웹 응용 프로그램이 다시 배포되었습니다. stopServer.sh 및 startServer.sh 스크립트를 사용하여 WebSphere를 다시 시작했지만 로그인 페이지를 액세스하면 WebSphere에 amlcontroller 필터와 관련된 500 오류가 표시됩니다.

이 문제의 원인은 reinstallRTM 스크립트가 생성한 server.xml 파일이 손상되었기 때문입니다.

해결 방법: amconfig 스크립트가 백업한 server.xml 파일은 아직 유효합니다. 다음과 같이 이전의 복사본을 사용합니다.

서버를 중지합니다.
손상된 server.xml을 amconfig 스크립트가 백업한 복사본으로 대체합니다.

amconfig 스크립트가 백업한 server.xml 파일의 이름은 server.xml-orig- pid이며 여기에서 pid는 amwas51config 스크립트의 프로세스 ID입니다. 이 파일은 다음 디렉토리에 있습니다.
```
WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name
```
서버를 다시 시작합니다.

CR# 6455757: 업그레이드 전에 `sunISManagerOrganization` 표시자 클래스를 조직에 추가해야 합니다.

Access Manager 7 릴리스 전에 생성된 Access Manager DIT 내의 조직에는 sunISManagerOrganization 객체 클래스가 없을 수 있습니다. 또한 Access Manager 이외의 제품으로 만든 조직에도 해당 정의에 sunISManagerOrganization 객체 클래스가 없습니다.

해결 방법: Access Manager 7 2005Q4로 업그레이드하기 전에 DIT 내의 모든 조직의 해당 정의에 sunISManagerOrganization 객체 클래스가 있는지 확인합니다. 필요한 경우 업그레이드하기 전에 이 객체 클래스를 직접 추가합니다.

CR# 6454489: Access Manager 7 2005Q4 패치 2 업그레이드로 인해 콘솔 현재 세션 탭에 오류가 발생합니다.

업그레이드 시에 Access Manager 콘솔의 현재 세션 탭에 다음과 같은 오류가 발생합니다.

지정된 서버에서 유효한 세션을 가져오지 못했습니다.

이 문제는 o=orgname 형식의 루트 접미어가 있는 Access Manager 6 버전에서 업그레이드하는 배포에 해당됩니다.

해결 방법: Manager 7 2005Q4를 설치한 다음 Manager 7 패치 3을 적용하고 amupgrade 스크립트를 실행하여 다음과 같이 데이터를 마이그레이션합니다.

Access Manager 6 DIT를 백업합니다.
ampre70upgrade 스크립트를 실행합니다.
나중에 구성 옵션을 사용하여 Access Manager 7 2005Q4를 설치합니다.
Access Manager 웹 응용 프로그램 배포를 해제합니다.
Access Manager 웹 응용 프로그램을 배포합니다.
XML/LDIF 변경은 제외하고 Access Manager 7 패치 3을 적용합니다. XML/LDIF 변경은 다음 단계에서 amupgrade 스크립트를 실행한 다음 적용해야 합니다.
amupgrade 스크립트를 실행합니다.
Access Manager 7 패치 3이 변경되었으므로 Access Manager 웹 응용 프로그램을 다시 배포합니다.
Access Manager 콘솔에 액세스합니다.

CR# 6452320: 클라이언트 SDK로 폴링을 사용하면 예외가 발생합니다.

Access Manager 클라이언트 SDK(amclientsdk.jar)를 배포하고 폴링을 사용하도록 설정하면 다음과 같은 오류가 발생할 수 있습니다.

오류: 전송 폴링 오류:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller 스레드 풀의 작업 대기열이 가득 찼습니다.

이러한 오류는 분산 인증 UI 서버나 J2EE 에이전트를 배포한 뒤 또는 클라이언트 시스템에서 Access Manager 클라이언트 SDK를 배포한 경우에 발생할 수 있습니다.

해결 방법: 동시 세션이 수백 개 수준인 경우 다음 등록 정보 및 해당 값을 AMConfig.properties 파일 또는 AMAgents.properties 파일에 추가합니다.

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

수천 또는 수만 개의 세션이 있는 경우에는 이 값을 amtune-identity 스크립트를 실행하고 Access Manager AMConfig.properties 파일에 있는 알림과 같은 값으로 지정해야 합니다. 예를 들어 4GB RAM을 갖춘 시스템에서 Access Manager amtune-identity 스크립트는 다음 값을 지정합니다.

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

분산 인증 UI 서버 또는 Access Manager 클라이언트 SDK를 4GB RAM을 갖춘 클라이언트 시스템에 배포할 때도 클라이언트측 AMAgent.properties 또는 AMConfig.properties 파일에 비슷한 값을 설정합니다.

CR# 6442905: 인증된 사용자의 `SSOToken`이 의도와 다르게 불량 사이트로 유출될 수 있습니다.

인증된 Access Manager 사용자가 불량 사이트에 있는 URL을 클릭하면 의도와 다르게 SSOToken이 불량 사이트로 유출될 수 있습니다.

해결 방법: 참가하는 정책 에이전트에 대해 Access Manger에서 항상 고유한 에이전트 사용자 프로필을 만들어 해당 사이트가 불량 사이트인지 확인합니다. 또한 이러한 고유한 에이전트 사용자가 공유 보안 비밀번호 또는 amldapuser 비밀번호를 사용하는 일이 없도록 합니다. 기본적으로 정책 에이전트는 Access Manager 응용 프로그램 인증 모듈에 UrlAccessAgent 사용자로 인증됩니다.

Access Manager 관리 콘솔을 사용하여 에이전트를 만드는 방법은 Sun Java System Access Manager 7 2005Q4 관리 설명서의 에이전트를 참조하십시오.

CR# 6441918: 사이트 모니터링 간격 및 시간 제한 등록 정보

Access Manager 사이트 페일오버에 다음과 같은 새로운 등록 정보가 포함됩니다.

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

자세한 내용은 사이트 모니터링을 위한 새로운 구성 등록 정보를 참조하십시오.

CR# 6440697: 분산 인증은 amadmin이 아닌 사용자로 실행해야 합니다.

분산 인증 응용 프로그램을 위한 기본 관리 사용자(amadmin) 이외의 다른 분산 인증 관리자를 만들려면 다음 절차를 따르십시오.

분산 인증 관리자를 위한 LDAP 사용자를 만듭니다. 예를 들면 다음과 같습니다.
```
uid=DistAuthAdmin,ou=people,o=am
```
분산 인증 관리자를 특수 사용자 목록에 추가합니다. 예를 들면 다음과 같습니다.
```
com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am
```
이 등록 정보를 모든 Access Manager 서버의 AMConfig.properties 파일에 추가하여 분산 인증 관리자의 AppSSOToken이 세션이 만료될 때 함께 만료되지 않도록 합니다.

CR# 6440695: 로드 밸런서가 있는 분산 인증 UI 서버

여러 분산 인증 UI 서버 앞에 로드 밸런서가 포함된 배포의 경우에는 WAR 파일을 배포한 다음 AMConfig.properties 파일에서 다음의 등록 정보를 설정합니다.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651: 쿠키 재생에 `com.sun.identity.session.resetLBCookie` 등록 정보가 필요합니다.

Access Manager 세션 페일오버에 대한 쿠키 재생이 제대로 작동하려면 정책 에이전트와 Access Manager 서버에 대해 모두 true 값인 com.sun.identity.session.resetLBCookie 등록 정보를 추가합니다. 예를 들면 다음과 같습니다.

com.sun.identity.session.resetLBCookie='true'

정책 에이전트의 경우 AMAgent.properties 파일에 해당 등록 정보를 추가합니다.
Access Manager 서버의 경우 AMConfig.properties 파일에 해당 등록 정보를 추가합니다.

주: 이 등록 정보는 Access Manager 세션 페일오버를 구현한 경우에만 필요합니다.

CR# 6440648: `com.iplanet.am.lbcookie.name` 등록 정보는 `amlbcookie`에 기본값을 가정합니다.

기본적으로 정책 에이전트 및 Access Manager 서버는 로드 밸런서 쿠키 이름을 amlbcookie라고 가정합니다. 백엔드 서버에서 쿠키 이름을 변경한 경우에는 정책 에이전트에 대한 AMAgent.properties 파일에서도 같은 이름을 사용해야 합니다. 또한 Access Manager 클라이언트 SDK를 사용하는 경우에는 여기에도 백엔드 서버에서와 같은 쿠키 이름을 사용해야 합니다.

CR# 6440641: `com.iplanet.am.lbcookie.value` 등록 정보는 더 이상 사용되지 않습니다.

Access Manager는 더 이상 서버에서 로드 밸런서 쿠키를 사용자 정의하는 데 com.iplanet.am.lbcookie.value 속성을 지원하지 않습니다. 대신 Access Manager는 이제 쿠키 값 및 에이전트에 의해 재생되는 이름에 대해 세션 구성의 일부로 구성되는 서버 ID를 사용합니다.

CR# 6429610: ID-FF SSO 사용 예에 SSO 토큰을 만들 수 없습니다.

Liberty Identity Federation Framework(ID-FF) 샘플 1을 설정한 뒤에 연합은 성공하지만 SSO는 실패합니다.

해결 방법: dsameuser의 uuid를 AMConfig.properties 파일의 com.sun.identity.authentication.special.users 등록 정보에 추가합니다. 응용 프로그램 인증을 위해서 dsameuser는 Access Manager 서버에 대한 만료되지 않는 SSO 토큰이 필요합니다.

CR# 6389564: Access Manager 로그인 중에 LDAP v3 데이터 저장소에서 사용자의 역할 구성원에 대한 성공적인 쿼리가 반복됩니다.

사용자가 Access Manager로 로그인할 때 사용자의 nsRoleDN 속성에 대한 반복적인 LDAP 검색이 수행됩니다.

해결 방법: Access Manager 7 패치 3이 설치되었으면 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager와 함께 표시되는 다음 명령을 실행합니다.

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185: 인증 모듈이 "goto" URL을 무시하고 다른 URL을 지정할 수 있어야 합니다.

사용자 상태를 검증하기 위해서 인증 모듈은 "goto" URL을 무시하고 외부 웹 사이트의 다른 URL로 리디렉션할 수 있어야 합니다.

인증이 완료된 뒤에 "goto" URL을 무시하기 위해서는 다음 예의 SSOToken에 표시된 등록 정보를 설정합니다. 이 등록 정보는 AMPostAuthProcessInterface를 구현하는 PostProcess 클래스의 onLoginSuccess 메소드를 사용하여 설정합니다. 예를 들어 OverridingURL은 "goto" URL을 무시하는 URL입니다.

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184: SSO 토큰의 상태가 잘못된 경우 사용자 정의 인증 모듈 내에서 리디렉션됩니다.

사용자 정의 인증 모듈을 위한 RedirectCallback은 사용자를 검증하기 위해 인증 UI를 통한 외부 웹 사이트로 리디렉션을 허용합니다. 인증이 성공적인 경우 사용자는 원래의 Access Manager 서버 URL로 리디렉션됩니다. 다음과 같은 샘플 파일이 포함됩니다.

LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp

이러한 기능을 구현하려면

샘플 LoginModuleSample.java를 사용하여 사용자 정의 인증 모듈을 만듭니다.
Access Manager 서버로 모듈을 로드합니다.
샘플 LoginModuleSample.xml을 사용하여 XML 파일에 RedirectCallback을 구성합니다.
모듈을 테스트하려면 외부 웹 사이트로 testExtWebSite.jsp 파일을 사용합니다.

다음 URL을 사용하여 로그인합니다.

http://example.com/amserver/UI/Login?module=LoginModuleSample

사용자 이름 및 비밀번호가 검증을 위해 외부 웹 사이트로 리디렉션됩니다. 이름 및 비밀번호가 유효한 경우 인증이 성공하고 사용자는 원래 Access Manager 서버 URL로 리디렉션됩니다.

예를 들어 배포에서 사용자 정의 인증 모듈을 사용하여 공급/신용카드 사이트에 액세스하는 시나리오에 대해 고려해 보겠습니다.

사용자가 사용자 정의 인증 모듈에 대한 인증 프로세스/로그인 페이지를 호출합니다.
사용자가 자격 증명(사용자 이름 및 비밀번호)을 입력하고 사용자 정의 인증 모듈에 요청을 제출합니다.
사용자 정의 인증 모듈이 요청에 필요한 사용자 정보와 함께 사용자를 외부 공급/신용카드 사이트로 리디렉션합니다.
외부 공급/신용카드 사이트가 사용자 상태를 확인하고 반환된 요청의 일부로 설정되는 성공 또는 실패로 요청을 반환합니다.
사용자 정의 인증 모듈이 4단계에서 반환된 상태에 따라 사용자를 검증하고 해당 상태를 인증 서비스에 반환합니다.
사용자 인증이 성공 또는 실패로 완료됩니다.

CR# 6324056: 아티팩트 프로필을 사용하면 연합이 실패합니다.

해결 방법: 이 문제를 해결하려면 플랫폼에 따라 최신 버전의 "Core Mobile Access" 패치를 적용해야 합니다.

SPARC 기반 시스템상의 Solaris OS: 119527
x86 플랫폼에 설치된 Solaris OS: 119528
Linux 시스템: 119529

패치를 설치한 뒤에 웹 컨테이너를 다시 시작합니다.