test

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

Access Manager 7 2005Q4 패치 릴리스

Access Manager 7 2005Q4 패치 최신 개정판은SunSolve Online(http://sunsolve.sun.com)에서 다운로드하여 설치합니다. 최신 패치 아이디는 다음과 같습니다.

주 –

Access Manager 7 2005Q4 패치는 누적식입니다. 먼저 패치 1, 2, 3, 4, 5 또는 6을 설치하지 않고 패치 7을 설치할 수 있습니다. 그러나 이전 패치를 설치하지 않은 경우 이전 패치 절의 새로운 기능 및 문제를 검토하여 현재 배포에 적용할 기능 및 문제가 있는지 확인하십시오.

Access Manager 7 2005Q4 패치에 대한 정보는 다음과 같습니다.

Access Manager 7 2005Q4 패치 7

Access Manager 7 패치 7(개정 번호 07)에서는 패치에 포함된 README 파일에 나열된 여러 문제를 해결합니다.

패치 7에는 다음과 같은 변경 사항이 포함되어 있습니다.

CR# 6637806: 재시작한 후 Access Manager가 잘못된 응용 프로그램 SSO 토큰을 에이전트에 보냈지만 이제 올바른 토큰을 보냅니다.

이제 Access Manager 서버를 재시작한 후 Access Manager 클라이언트 SDK가 에이전트로 올바른 예외를 보내므로 해당 에이전트가 재인증을 통해 새로운 응용 프로그램 세션을 얻을 수 있습니다. 이전에는 Access Manager 7 2005Q4 패치 5를 적용한 후 Access Manager 서버를 재시작하면 Access Manager 클라이언트 SDK가 잘못된 응용 프로그램 SSO 토큰을 해당 에이전트로 보냈습니다.

이 문제는 CR 6496155를 복제하여 수정되었습니다. 또한 패치 7에서도 제한적 컨텍스트로 응용 프로그램 SSO 토큰을 보내는 옵션(comp.iplanet.dpro.session.dnRestrictionOnly 등록 정보)을 제공합니다. 기본적으로 에이전트는 해당 에이전트가 설치되어 있는 서버의 IP 주소를 보내지만 엄격한 DN 검사가 필요한 경우 AMConfig.properties 파일에서 이 등록 정보를 다음과 같이 설정하십시오.

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609: 네트워크 케이블이 Message Queue 서버에 연결되어 있지 않은 경우 세션 페일오버가 작동됩니다.

이제 세션 페일오버 배포 환경에서 각 Access Manager 인스턴스와 Message Queue 브로커가 동일한 서버에 설치되어 있는 경우 네트워크 케이블이 서버 중 하나에 연결되어 있지 않으면 세션 페일오버가 작동됩니다. 기본적으로 Message Queue imqAddressListBehavior 연결 팩토리 속성이 PRIORITY로 설정되기 때문에 Message Queue는 브로커 주소 목록에 나타난 순서대로 주소를 사용합니다(예: localhost:7777,server2:7777,server3:7777). 이 속성이 RANDOM으로 설정되어 있는 경우에는 임의의 순서로 주소를 사용합니다.

이 속성을 RANDOM으로 설정하려면 amsessiondb 스크립트에서 다음 매개 변수를 설정하십시오.

-DimqAddressListBehavior=RANDOM

Message Queue PRIORITY 및 RANDOM 속성에 대한 자세한 내용은 Sun Java System Message Queue 3.7 UR1 관리 설명서의 브로커 주소 목록를 참조하십시오.

CR# 6570409: 로드 밸러서 뒤에서 상호 작용 서비스가 Identity Provider로 올바르게 작동됩니다.

두 대의 서버가 로드 밸런서에 연결되어 단일 Identity Provider로 작동하는 배포 환경인 경우 AMConfig.properties 파일에서 다음 등록 정보를 설정해야 합니다.

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

com.sun.identity.liberty.interaction.interactionConfigClass는 현재 지원되는 유일한 클래스입니다. 따라서 기본적으로 Federation Liberty에 번들로 제공된 상호 작용 구성 클래스를 사용하여 상호 작용 구성 매개 변수에 액세스합니다.

CR# 6545176: 게시 인증 처리 SPI 플러그인에서 리디렉션 URL을 동적으로 설정할 수 있습니다.

이제 로그인 성공, 로그인 실패 및 로그아웃을 검증하는 데 필요한 리디렉션 URL을 게시 인증 처리 SPI 플러그인에서 동적으로 설정할 수 있습니다. 게시 처리 플러그인이 실행되지 않는 경우 게시 처리 SPI에 설정된 리디렉션 URL은 사용되지 않으며 다른 방법으로 설정한 리디렉션 URL이 앞서와 같이 사용됩니다.

자세한 내용은 com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java 샘플을 참조하십시오.

사전 설치 고려 사항

파일 백업

중요 현재 설치의 파일 중 사용자 정의한 파일이 있는 경우에는 패치를 설치하기 전에 이러한 파일을 백업해야 합니다. 패치를 설치한 다음 백업한 파일과 이 패치에서 설치한 파일을 비교하여 사용자 정의를 식별합니다. 사용자 정의를 새로운 파일에 병합하고 저장합니다. 사용자 정의 파일을 처리하는 데 대한 자세한 내용은 다음 정보를 읽어 보십시오.

패치를 설치하기 전에 다음 파일도 백업하십시오.

Solaris 시스템

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • /etc/opt/SUNWam/config/xml/template/ 디렉토리의 파일:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml , amSession.xml

  • AccessManager-base/SUNWam/locale/ 디렉토리의 파일:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Linux 및 HP-UX 시스템

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • /etc/opt/sun/identity/config/xml/template/ 디렉토리의 파일:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • AccessManager-base/identity/locale/ 디렉토리의 파일:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Windows 시스템

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • AccessManager-base\identity\config\xml\template 디렉토리의 파일:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • AccessManager-base\identity\locale 디렉토리의 파일:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

여기서 AccessManager-base는 기본 설치 디렉토리입니다. 플랫폼별 기본 설치 디렉토리는 다음과 같습니다.

  • Solaris 시스템: /opt

  • Linux 및 HP-UX 시스템: /opt/sun

  • Windows 시스템: javaes-install-directory\AccessManager . 예를 들면 다음과 같습니다. C:\Program Files\Sun\AccessManager

Access Manager 설치 및 구성

이 문서에서 설명한 Access Manager 패치가 Access Manager를 설치하는 것은 아닙니다. 패치를 설치하기 전에 Access Manager 7 2005Q4를 서버에 설치해야 합니다. 설치하는 방법은 Sun Java Enterprise System 2005Q4 설치 설명서를 참조하십시오.

Windows 시스템에 패치를 설치하는 경우 Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows를 참조하십시오.

Access Manager를 배포, 다시 배포 및 구성하려면 Sun Java System Access Manager 7 2005Q4 관리 설명서의 1 장, Access Manager 7 2005Q4 구성 스크립트에 설명된 대로 amconfig 스크립트 실행에 익숙해야 합니다.

이 패치에 의해 사용하지 않게 된 Access Manager 패치 목록과 이 패치를 설치하기 전에 설치해야 하는 패치에 대해서는 이 패치에 포함된 README 파일을 참조하십시오.

주의 – 주의 –

Access Manager 패치는 다른 패치와 마찬가지로 작업 환경에 적용하기 전에 준비 또는 배포 전 시스템에서 테스트해야 합니다. 또한 패치 설치 프로그램이 사용자 정의 JSP 파일을 올바르게 업데이트하지 못할 수 있으므로 Access Manager가 올바르게 동작하려면 이러한 파일을 직접 변경해야 할 수 있습니다.

패치 설치 지침

Solaris 시스템용 패치 설치 지침

Solaris 패치를 설치하기 전에 사전 설치 고려 사항에 나열된 파일들을 백업했는지 확인하십시오.

Solaris 시스템에서 패치를 추가하거나 제거하려면 OS에서 제공하는 patchadd 및 patchrm 명령을 사용하십시오.

patchadd 명령

독립형 시스템에 패치를 설치하려면 patchadd 명령을 사용합니다. 예를 들면 다음과 같습니다.

# patchadd /var/spool/patch/120954-07
주 –

Solaris 10 전역 영역에 Solaris 패치를 설치하는 경우 -G 인수를 사용하는 patchadd 명령을 호출하십시오. 예를 들면 다음과 같습니다.

patchadd -G /var/spool/patch/120954-07

postpatch 스크립트는 Access Manager SDK 구성 요소만 설치된 시스템의 경우를 제외하고 Access Manager 응용 프로그램을 다시 배포하는 데 대한 메시지를 표시합니다.

postpatch 스크립트는 다음 디렉토리에 amsilent 파일을 만듭니다.

여기서 AccessManager-base는 기본 설치 디렉토리입니다. 기본 설치 디렉토리는 Solaris 시스템의 경우 /opt이며 Linux 시스템의 경우 /opt/sun입니다.

amsilent는 amsamplesilent 파일에 기반하지만 시스템의 Access Manager 구성 파일에 따라 일부 매개 변수 집합이 필요할 수 있습니다. 비밀번호 매개 변수에는 기본값이 포함됩니다. 각 비밀번호 매개 변수의 주석을 해제하고 값을 수정한 다음, 파일 내의 배포에 필요한 다른 매개 변수의 값을 주의 깊게 확인합니다.

공통 도메인 웹 응용 프로그램의 URI 접두어인 COMMON_DEPLOY_URI 매개 변수에도 기본값이 포함됩니다. 이 URI에 대해 기본 이외의 값을 지정한 경우에는 이 값을 반드시 수정해야 합니다. 그렇지 않으면 amconfig 및 패치로 생성된 amsilent 파일을 통해 웹 응용 프로그램을 다시 배포할 수 없게 됩니다.

그리고 다음 명령을 실행합니다(기본 디렉토리에 설치된 Access Manager와 함께 표시).

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent
주의 – 주의 –

amsilent 파일에는 관리자 비밀번호와 같은 민감한 데이터가 일반 텍스트로 포함되므로 배포에 적합하도록 파일을 보호해야 합니다.

amconfig 스크립트를 실행한 후에 updateschema.sh 스크립트를 실행하여 XML 파일과 LDIF 파일을 로드합니다. updateschema.sh 스크립트는 다음 디렉토리에 패치 7을 설치한 후에 사용할 수 있습니다.

updateschem 스크립트를 실행한 후 Access Manager 프로세스를 다시 시작합니다. 예를 들면 다음과 같습니다.

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

그런 다음 Access Manager 웹 컨테이너를 다시 시작합니다.

patchrm Command

독립형 시스템에서 패치를 제거하려면 patchrm 명령을 사용합니다. 예를 들면 다음과 같습니다.

# patchrm 120954-03

backout 스크립트는 Access Manager SDK 구성 요소만 설치된 시스템의 경우를 제외하고 patchadd 명령과 비슷한 메시지를 표시합니다.

패치가 제거되었으면 AccessManager-base/SUNWam 디렉토리에 있는 amsilent 파일을 사용하여 Access Manager 응용 프로그램을 다시 배포합니다. 여기서 AccessManager-base는 기본 설치 디렉토리입니다. Solaris 시스템에서 기본 설치 디렉토리는 /opt입니다.

배포에 적합하도록 amsilent 파일의 매개 변수를 설정합니다.

그런 다음 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager와 함께 표시되는 다음 명령을 실행합니다.

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

patchadd 및 patchrm 명령에 대한 자세한 내용은 해당 Solaris man 페이지를 참조하십시오.

자세한 내용은 사후 설치 고려 사항을 참조하십시오.

Solaris 10 영역

Solaris 10 운영 체제에서는 "영역"이라는 새로운 개념을 소개했습니다.이에 따라 patchadd 명령에도 전역 영역에만 패치를 추가하는 -G 옵션이 추가되었습니다. 기본적으로 patchadd 명령은 패치될 패키지의 pkginfo에서 SUNW_PKG_ALLZONES를 찾습니다. 그러나 모든 Access Manager 패키지에 대해 SUNW_PKG_ALLZONES 변수가 설정되는 것은 아니며 Access Manager 7 2005Q4가 전역 영역에 설치된 경우에는 -G 옵션이 필요합니다. Access Manager가 로컬 영역에 설치된 경우 patchadd -G 옵션은 효과가 없습니다.

Access Manager 7 2005Q4 패치를 Solaris 시스템 시스템에 설치하는 경우에는 -G 옵션을 사용하는 것이 좋습니다. 예를 들면 다음과 같습니다.

# patchadd -G AM7_patch_dir

비슷하게 Access Manager가 전역 영역에 설치된 경우에는 patchrm 명령을 실행하는 데 -G 옵션이 필요합니다. 예를 들면 다음과 같습니다.

# patchrm -G 120954-07

Linux 시스템용 패치 설치 지침

Linux 패치를 설치하기 전에 사전 설치 고려 사항에 나열된 파일들을 백업했는지 확인하십시오.

installpatch는 단독형 Linux 시스템에 패치를 설치합니다. 예를 들면 다음과 같습니다.

# ./installpatch

postpatch 스크립트는 Solaris 시스템과 비슷한 메시지를 출력합니다. 그러나 Linux 시스템에서 패치를 취소하기 위한 절차는 Solaris 시스템과는 다릅니다. Linux 패치를 취소하는 공통적인 스크립트는 없습니다. 이전에 낮은 패치 버전을 설치한 경우 해당 버전을 다시 설치하고 postpatch 지침에 따라 amconfig 스크립트를 실행하여 Access Manager 응용 프로그램을 다시 배포할 수 있습니다.

amconfig 스크립트를 실행한 후에 updateschema.sh 스크립트(패치 5 이상)를 실행하여 XML 파일과 LDIF 파일을 로드합니다. updateschema.sh 스크립트는 patch-home-directory/120956-07/scripts 디렉토리에 패치 7을 설치한 후에 사용할 수 있습니다.

amconfig 및 updateschema.sh 스크립트를 실행한 후 Access Manager 웹 컨테이너를 다시 시작합니다.

Access Manager 7 2005Q4 RTM 릴리스에 패치가 설치되어 있고 패치를 제거하여 시스템을 RTM 상태로 복원하려는 경우 reinstallRTM 스크립트를 사용하여 Access Manager 7 2005Q4 RTM 패키지를 다시 설치해야 합니다. 이 스크립트는 Access Manager RTM RPM이 저장된 경로를 이용하여 패치한 RPM에 RTM RPM을 설치합니다. 예를 들면 다음과 같습니다.

# ./scripts/reinstallRTM path_of_AM7_RTM_RPM_directory

reinstallRTM 스크립트를 실행한 후 amconfig 스크립트를 실행하여 Access Manager 응용 프로그램을 다시 배포하고 웹 컨테이너를 다시 시작합니다.

자세한 내용은 사후 설치 고려 사항을 참조하십시오.

Windows 시스템용 패치 설치 지침

Windows 패치 설치에 관련되는 요구 사항은 다음과 같습니다.

Windows 패치 설치

Windows 패치를 설치하기 전에 사전 설치 고려 사항에 나열된 파일들을 백업했는지 확인하십시오.

패치 스크립트에서 입력하는 기본 디렉토리 경로에는 슬래시(/)를 사용합니다. 예를 들면 다음과 같습니다. c:/sun

Windows 패치를 설치하려면

  1. 관리자 그룹의 구성원으로 Windows 시스템에 로그온합니다.

  2. Windows 패치 파일을 다운로드하고 압축을 풀 디렉토리를 만듭니다. 예: AM7p7

  3. 이전 단계에서 만든 디렉토리에 124296-07.zip 파일을 다운로드하고 압축을 풉니다.

  4. 모든 Java ES 2005Q4 서비스를 중지합니다.

  5. AM7p7\scripts\prepatch.pl 스크립트를 실행합니다.

  6. AM7p7\124296-07.exe를 실행하여 패치를 설치합니다.

  7. AM7p7\scripts\postpatch.pl 스크립트를 실행합니다.

  8. Java ES 2005Q4 서비스를 다시 시작합니다.

  9. Access Manager 응용 프로그램을 다시 배포합니다. 자세한 내용은 사후 설치 고려 사항을 참조하십시오.

  10. AM7p7\scripts\updateschema.pl 스크립트를 실행하여 Directory Server 서비스 스키마를 업데이트합니다. 스크립트에서 입력 항목을 검증한 다음 해당 파일을 로드합니다. 또한 스크립트에서 다음과 같은 로그 파일에 기록합니다.

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema- timestamp

  11. Java ES 2005Q4 서비스를 다시 시작합니다.

Windows 패치 취소

Windows 패치를 취소하려면 다음을 수행합니다.

  1. 관리자 그룹의 구성원으로 Windows 시스템에 로그온합니다.

  2. Uninstall_124296-07.bat 파일을 실행합니다.

  3. AM7p7\scripts\postbackout.pl 스크립트를 실행합니다.

  4. Access Manager 응용 프로그램을 다시 배포합니다.

  5. Java ES 2005Q4 서비스를 다시 시작합니다.

주: 패치를 취소하더라도 AM7p7\scripts\updateschema.pl 스크립트로 추가된 스키마 변경 항목은 Directory Server에서 제거되지 않습니다. 그러나 패치가 취소된 후에는 Access Manager 기능이나 유용성에 영향을 미치지 않으므로 이러한 스키마 변경 항목을 수동으로 제거하지 않아도 됩니다.

HP-UX 시스템용 패치 설치 지침

HP-UX 패치를 설치하거나 제거하려면 swinstall 및 swremove 명령을 사용합니다. 예를 들어 독립형 시스템에 패치를 설치하려면 다음을 수행합니다.

# swinstall /var/spool/patch/126371-07

또는 독립형 시스템에서 패치를 제거하려면 다음을 수행합니다.

# swremove 126371-07

swinstall 및 swremove 명령에 대해서는 swinstall 및 swremove 매뉴얼 페이지를 참조하십시오.

패치를 설치하거나 제거한 후에는 사후 설치 고려 사항 절에 설명된 대로 Access Manager 응용 프로그램을 다시 배포해야 합니다.

Access Manager 응용 프로그램을 다시 배포한 후 updateschema.sh 스크립트(패치 5 이상)를 실행하여 XML 및 LDIF 파일을 로드합니다. updateschema.sh 스크립트는 patch-home-directory/120956-07/scripts 디렉토리에 패치 7을 설치한 후에 사용할 수 있습니다. amconfig 및 updateschema.sh 스크립트를 실행한 후 Access Manager 웹 컨테이너를 다시 시작합니다.

주: 패치를 제거해도 updateschema.sh 스크립트로 추가된 스키마 변경 항목은 Directory Server에서 제거되지 않습니다. 그러나 패치를 제거한 후 Access Manager 기능이나 유용성에 영향을 미치지 않으므로 이러한 스키마 변경 항목을 수동으로 제거하지 않아도 됩니다.

HP-UX 시스템에 Access Manager를 배포하는 방법은 Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX를 참조하십시오.

사후 설치 고려 사항

Access Manager 7 2005Q4 패치를 설치한 후 고려할 사항에는 다음이 포함됩니다.

CR# 6254355: Access Manager 패치가 postpatch 스크립트의 Access Manager 응용 프로그램을 배포하지 않습니다.

패치 설치 프로그램이 사용자 정의된 WAR 파일 일부를 유지하지 않고 사용자 정의되지 않은 버전으로 대체합니다. 사용자 정의된 WAR 파일의 내용을 식별하고 직접 업데이트하려면 다음과 같은 절차 사용을 고려해 보십시오.

다음 예에서 AccessManager-base는 기본 설치 디렉토리입니다. 기본 설치 디렉토리는 Solaris 시스템의 경우 /opt이며 Linux 시스템의 경우 /opt/sun입니다.

Windows 시스템의 경우 AccessManager-base는 javaes-install-directory\AccessManager입니다. 예: C:\Program Files\Sun\AccessManager

패치되는 WAR 파일은 다음과 같습니다.

이 파일들은 Solaris 시스템의 경우 AccessManager-base/SUNWam에 있으며, Linux 시스템의 경우 AccessManager-base/identity에 있습니다.

Windows 시스템의 경우패치된 WAR 파일은 AccessManager-base\에 있습니다.

WAR 파일에서 변경할 수 있는 내용은 다음과 같습니다.

이러한 모든 변경 사항을 유지하려면 다음 단계를 따르십시오. 파일을 변경하기 전에 항상 먼저 파일을 백업하십시오.

  1. 패치를 설치합니다.

  2. 임시 디렉토리에 WAR 파일 압축을 해제합니다. 예를 들어 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager를 사용하는 경우 다음과 같습니다.

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. 패치 설치 프로그램이 사용자 정의된 파일을 변경하는지 압축 해제된 파일을 확인하고 임시 디렉토리의 변경된 파일에 원래 사용자 정의 변경을 직접 추가합니다. AccessManager-base/web-src/ 디렉토리의 파일에 대한 변경 사항 중 패치된 WAR 파일에 포함되지 않는 항목에 대해서는 변경 사항을 다시 적용할 필요가 없습니다.

  4. 수정된 파일로 WAR 파일을 업데이트합니다. 예를 들어 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager를 사용하는 경우 다음과 같습니다.

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    2~4단계를 예로 들면 다음과 같습니다.

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. 패치에서 생성된 자동 구성 파일(amsilent)을 다시 사용하거나 amsamplesilent 템플리트 파일에 기반한 구성 파일을 새로 만들고 다음을 포함하여 해당 구성 변수를 설정합니다.

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • DS_DIRMGRPASSWD, ADMINPASSWD 및 AMLDAPUSERPASSWD를 위한 비밀번호

    • Access Manager 웹 컨테이너 변수

    Windows 시스템의 경우 postpatch.pl 스크립트에서 생성된 자동 구성 파일(amsilent)을 다시 사용하고 AccessManager-base\setup\AMConfigurator.properties-tmp 값이 유효한지 확인합니다. 그런 다음 이 파일의 이름을 AccessManager-base\setup\AMConfigurator.properties로 변경합니다.

    웹 컨테이너 변수에 대한 자세한 내용은 Solaris 시스템에서는 /opt/SUNWam/bin 디렉토리, Linux 시스템에서는 /opt/sun/identity/bin 디렉토리에 있는 amsamplesilent 파일을 참조하십시오.

    Windows 시스템의 경우 구성 파일은 AccessManager-base\setup\AMConfigurator.properties입니다.

  6. 아래에 표시된 amconfig 스크립트를 실행합니다. amconfig를 실행하기 전에 Directory Server 및 Access Manager 웹 컨테이너가 실행 중이어야 합니다. 예를 들어 Access Manager가 기본 설치 디렉토리에 설치된 Solaris 시스템에서 amconfig를 실행하려면 다음과 같이 수행합니다. 

    # cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

  7. amconfig 스크립트를 실행한 다음 Access Manager 프로세스를 다시 시작합니다. 예를 들면 다음과 같습니다.

    # cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

  8. Solaris 시스템의 경우 AccessManager-base/SUNWam/web-src/ 디렉토리의 해당 하위 디렉토리 또는 Linux 시스템의 경우 AccessManager-base/identity/web-src/ 디렉토리에 사용자 정의한 JSP 파일이 모두 있는지와 이러한 파일을 모두 백업했는지를 확인합니다.

    Windows 시스템의 경우 이러한 파일은 AccessManager-base\web-src\에 있습니다.

  9. Access Manager 웹 컨테이너를 다시 시작합니다.

amconfig 스크립트를 실행하는 데 대한 자세한 내용은Sun Java System Access Manager 7 2005Q4 관리 설명서의 1 장, Access Manager 7 2005Q4 구성 스크립트를 참조하십시오.

CR# 6436409: 분산 인증 및 클라이언트 SDK WAR 파일 다시 배포

분산 인증 또는 클라이언트 SDK를 사용하고 있다면 패치를 설치한 뒤에 분산 인증 WAR 파일 및/또는 클라이언트 SDK WAR 파일을 다시 만들고 다시 배포하십시오. 자세한 내용은 다음 문서를 참조하십시오.

Access Manager 7 2005Q4 패치 6

Access Manager 7 패치 6(개정 06)에서는 패치에 포함된 README 파일에 나와 있는 여러 문제를 수정했습니다. 패치 6에는 다음과 같은 새로운 기능, 문제점 및 설명서 업데이트가 들어 있습니다.

패치 6의 새로운 기능

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

주 –

패치 6을 설치하기 전에 다음 구성 요소를 업그레이드하거나 패치하는 것이 좋습니다.

Access Manager에서 JDK 1.5 HttpURLConnection setReadTimeout 메소드 지원

setReadTimeout 메소드를 지원하려면 AMConfig.properties 파일의 다음 새 등록 정보에서 읽기 시간 초과 값을 설정합니다. 

com.sun.identity.url.readTimeout

웹 컨테이너에서 JDK 1.5를 사용하는 경우 HttpURLConnections이 너무 많이 열려 있으면 서버가 중단될 수 있으므로 이를 방지하려면 연결이 시간 초과되도록 이 등록 정보를 적절한 값으로 설정합니다. 기본값은 30000밀리초(30초)입니다.

setReadTimeout 메소드는 com.sun.identity.url.readTimeout 이 AMConfig.properties 파일에 없거나 빈 문자열로 설정된 경우 무시됩니다.

Access Manager SDK에서 기본 Directory Server를 백업한 후 기본 Directory Server로 폴백

Sun Java System Directory Server가 MMR(Multi-Master Replication)로 구성된 경우 Access Manager SDK는 기본 Directory Server를 중단하고 백업한 후 기본 Directory Server로 폴백합니다. 이전에는 Access Manager SDK가 기본 Directory Server를 백업한 후에도 보조 Directory Server로 계속 액세스했습니다.

Access Manager에서 이 새 동작을 지원하기 위해 AMConfig.properties 파일에 다음과 같은 새 등록 정보가 추가되었습니다.

com.sun.am.ldap.fallback.sleep.minutes

이 등록 정보에서는 기본 Directory Server를 백업한 후 기본 서버로 폴백하기 전에 보조 Directory Server 인스턴스가 일시 정지하는 시간(분)을 설정합니다. 기본값은 15분입니다.

com.sun.am.ldap.fallback.sleep.minutes 등록 정보는 숨겨져 있습니다. 이 등록 정보를 기본값(15분) 이외의 값으로 설정하려면 AMConfig.properties 파일에 이 등록 정보를 명시적으로 추가합니다. 예를 들어 값을 7분으로 설정하려는 경우 다음을 추가합니다.

com.sun.am.ldap.fallback.sleep.minutes=7

새 값을 적용하려면 Access Manager 웹 컨테이너를 다시 시작합니다.

다중 Access Manager 인스턴스에서 별도의 로그 파일에 로그

AMConfig.properties 파일에서 다음의 새 등록 정보를 설정하면 같은 호스트 서버에서 실행되는 다중 Access Manager 인스턴스에서 서로 다른 로깅 하위 디렉토리에 있는 별도의 로그 파일에 로그할 수 있습니다.

com.sun.identity.log.logSubdir

관리 콘솔에서 기본 로깅 디렉토리를 변경하지 않은 경우 기본 로깅 디렉토리는 다음과 같습니다.

첫 번째 Access Manager 인스턴스는 항상 기본 로깅 디렉토리에 로그합니다. 추가 Access Manager 인스턴스에 대해 다른 로깅 하위 디렉토리를 지정하려면 추가 Access Manager 인스턴스마다 AMConfig.properties 파일에 com.sun.identity.log.logSubdir 등록 정보를 설정합니다.

예를 들어 am-instance-1, am-instance-2 및 am-instance-3과 같은 3개 인스턴스를 모두 같은 Solaris 호스트 서버에서 실행하는 경우 다음과 같이 등록 정보를 설정합니다.

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

com.sun.identity.log.logSubdir 등록 정보는 숨겨져 있습니다. 필요한 경우 이 등록 정보를 AMConfig.properties 파일에 명시적으로 추가하고 Access Manager 웹 컨테이너를 다시 시작하여 하위 디렉토리 값을 적용합니다.

그러면 Access Manager 인스턴스가 다음 디렉토리에 로그합니다.

/var/opt/SUNWam/logs/log-files-for-am-instance-1
/var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2
/var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3

Access Manager 7에서 다중 쿠키 도메인 허용

Access Manager에서는 다중 쿠키 도메인을 허용하기 위해 다음 새 등록 정보를 추가했습니다.

com.sun.identity.authentication.setCookieToAllDomains

기본값은 true입니다. 이 새 등록 정보는 숨겨져 있습니다. false로 값을 설정하려면 AMConfig.properties 파일에 등록 정보를 명시적으로 추가한 후 Access Manager 웹 컨테이너를 다시 시작합니다.

Microsoft IIS 6.0 사후 인증 플러그인에서 SharePoint Server 지원

Microsoft 인터넷 정보 서비스(IIS) 6.0 인증 플러그인에서 Microsoft Office SharePoint Server를 지원합니다. 사용자는 사용자 ID 또는 로그인 이름을 이용하여 Access Manager에 로그인할 수 있습니다. 그러나 SharePoint Server의 경우 로그인 이름은 허용하지만 사용자 ID를 지정한 경우 문제가 발생합니다.

SharePoint Server로 로그인을 허용하려면 사후 인증 플러그인(ReplayPasswd.java)에서 다음의 새 등록 정보를 사용해야 합니다.

com.sun.am.sharepoint_login_attr_name

이 새 등록 정보는 SharePoint Server에서 인증 시 사용하는 사용자 속성을 나타냅니다. 예를 들어 다음 등록 정보는 인증 시 공통 이름(cn)을 지정합니다. 

com.sun.am.sharepoint_login_attr_name=cn

사후 인증 플러그인은 com.sun.am.sharepoint_login_attr_name 등록 정보를 읽고 Directory Server에서 사용자에 해당하는 속성 값을 가져옵니다. 그런 다음 사용자가 SharePoint Server에 액세스할 수 있도록 인증 헤더를 설정합니다.

이 등록 정보는 숨겨져 있습니다. 등록 정보를 설정하려면 AMConfig.properties 파일에 명시적으로 등록 정보를 추가한 후 Access Manager 웹 컨테이너를 다시 시작하여 값을 적용합니다.

Access Manager에서 Internet Explorer 7 지원

Access Manager 7 2005Q4 패치 6에서 Microsoft Windows Internet Explorer 7을 지원합니다.

CR# 6379325: 세션 페일오버 중 콘솔에 액세스하면 null 포인터 예외가 발생합니다.

이 시나리오에서는 쿠키 기반 지속 요청 라우팅에 구성된 로드 밸런서 뒤에 다중 Access Manager 서버가 세션 페일오버 모드로 배포되었습니다. Access Manager 관리자는 로드 밸런서를 통해 Access Manager 콘솔에 액세스합니다. 관리자가 콘솔에 로그인하면 Access Manager 서버 중 하나에서 세션이 만들어집니다. 서버가 중단되면 예상대로 콘솔 세션이 다른 Access Manager 서버로 페일오버됩니다. 그러나 브라우저와 웹 컨테이너 오류 로그에 간헐적인 null 포인터 예외가 나타나는 경우가 있습니다.

이 문제는 페일오버 시 활성 Access Manager 콘솔 세션에만 영향을 주며 Access Manager 서버 작동에는 영향을 주지 않습니다.

해결 방법: 간헐적인 null 포인터 예외를 방지하려면 다음을 수행합니다.

CR# 6508103: Windows에서 관리 콘솔의 도움말을 누르면 응용 프로그램 오류를 반환합니다.

Windows 2003 Enterprise Edition에서 영어 이외의 로켈로 Sun Java System Application Server에 Access Manager를 배포한 경우 영역 관리 모드 콘솔에서 도움말을 누르면 응용 프로그램 오류가 발생합니다.

해결 방법:

  1. javaes-install-dir\share\lib\jhall.jar 파일을 %JAVA_HOME%\jre\lib\ext 디렉토리에 복사합니다.

    여기서 javaes-install-dir은 Windows 설치 디렉토리입니다.

  2. Application Server 인스턴스를 다시 시작합니다.

CR# 6564877: Access Manager 7 패치 설치 시 SAML v2 파일을 덮어씁니다.

SAML v2 플러그인이 설치되면 패치 설치 시 SAML v2 관련 파일을 덮어쓰고 postpatch 스크립트에 다음 메시지가 나타납니다.

The postpatch script detected that the SAML v2 plug-in is installed in your environment. When you run the amconfig script to redeploy the Access Manager applications, the script will recreate the amserver.war file and the SAML v2 related files will be lost. Therefore, after you run amconfig, recreate and redeploy the amserver.war file, as described in the Sun Java System SAML v2 Plug-in for Federation Services User's Guide.

해결 방법: 패치를 설치하고 amconfig 스크립트를 실행한 후 SAML v2 플러그인을 사용하는 Federation Manager 또는 Access Manager 배포에 대해 amserver.war 파일을 다시 만들어 다시 배포합니다.

구체적인 단계는 Sun Java System SAML v2 Plug-in for Federation Services User’s Guide의 2 장, Installing the SAML v2 Plug-in for Federation Services를 참조하십시오.

Access Manager 7 2005Q4 패치 5

Access Manager 7 패치 5(개정 05)에서는 패치에 포함된 README 파일에 나열된 여러 문제를 해결합니다. 또한 패치 5에 포함된 새 기능, 문제점 및 설명서 업데이트 사항은 다음과 같습니다.

패치 5의 새로운 기능

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

국제화(g11n) 문제

설명서 업데이트

HP-UX 시스템 지원

패치 126371에서는 HP-UX 시스템에 대한 지원을 제공합니다. 자세한 내용은 다음 항목을 참조하십시오.

HP-UX 시스템에 설치하는 방법은 Sun Java Enterprise System 2005Q4 설치 설명서를 참조하십시오.

Microsoft Windows 시스템 지원

패치 124296에서는 Windows 시스템에 대한 지원을 제공합니다. 자세한 내용은 다음 항목을 참조하십시오.

Windows 시스템에 설치하는 방법은 Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows를 참조하십시오.

새로운 updateschema.sh 스크립트로 LDIF 및 XML 파일 로드

패치 5 이상에는 Directory Server 서비스 스키마를 업데이트하는 데 필요한 다음 파일을 로드하는 updateschema.sh 스크립트가 들어 있습니다.

이전 Access Manager 패치 릴리스에서는 이러한 파일을 수동으로 로드해야 했습니다.

updateschema.sh 스크립트를 실행하려면

  1. 수퍼유저(root)로 로그인합니다.

  2. 패치 디렉토리로 변경합니다.

  3. 스크립트를 실행합니다. 예를 들어 Solaris 시스템의 경우 다음과 같습니다.

    # cd /120954-07 
# ./updateschema.sh

    Windows 시스템의 경우 해당 스크립트는 updateschema.pl입니다.

  4. 스크립트에서 요청하는 메시지가 나타나면 다음 항목을 입력합니다.

    • Directory Server 호스트 이름 및 포트 번호

    • Directory Server 관리자 DN 및 비밀번호

    • amadmin DN 및 비밀번호

  5. 스크립트에서 입력 항목을 검증한 다음 해당 파일을 로드합니다. 또한 스크립트에서 다음과 같은 로그 파일에 기록합니다.

    • Solaris 시스템: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema.timestamp

    • Linux 시스템: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema.timestamp

  6. 스크립트가 완료되면 Access Manager 웹 컨테이너를 다시 시작합니다.

주 패치 5를 취소하는 경우 updateschema.sh 스크립트로 추가된 스키마 변경 항목이 Directory Server에서 제거되지 않습니다. 그러나 패치가 취소된 후에는 Access Manager 기능이나 유용성에 영향을 미치지 않으므로 이러한 스키마 변경 항목을 수동으로 제거하지 않아도 됩니다.

특정 응용 프로그램의 유휴 세션 시간 초과 값 지원

패치 5를 적용하면 응용 프로그램마다 별도의 유휴 세션 시간 초과 값을 설정할 수 있습니다. 기업에서는 일부 응용 프로그램의 유휴 세션 시간 초과 값이 세션 서비스에 지정된 값보다 작아야 할 수도 있습니다. 예를 들어 세션 서비스의 유휴 세션 시간 초과 값을 30분으로 지정했지만 사용자가 10분 이상 유휴 상태로 있을 경우 시간 초과로 인해 HR 응용 프로그램이 중지됩니다.

이 기능을 사용하기 위한 요구 사항은 다음과 같습니다.

이 기능을 사용하려면

예를 들어 다음과 같은 인증 방식 조건을 사용하는 http://host.sample.com/hr/* 정책이 있다고 가정합니다.

HR 응용 프로그램 자원을 보호하도록 정의된 정책이 여러 개 있으면 모든 정책에 조건을 추가해야 합니다.

특정 세션에 있는 사용자가 Access Manager 에이전트로 보호되는 HR 응용 프로그램에 액세스하려고 할 때 아직 인증되지 않은 경우 LDAP 스키마로 인증되도록 요청하는 메시지가 나타납니다.

사용자가 이미 LDAP 스키마로 인증되어 있으면 사용자가 마지막으로 인증된 이후 경과된 시간 또는 사용자가 HR 응용 프로그램에 마지막으로 액세스한 이후 경과된 시간이 10분 미만일 때만 응용 프로그램에 액세스할 수 있습니다. 그렇지 않으면 사용자가 LDAP 스키마로 다시 인증되어 응용 프로그램에 액세스하도록 요구하는 메시지가 나타납니다.

분산 인증 UI 서버에 배포될 수 있는 CDC 서블릿

CDC 서블릿은 크로스 도메인 단일 사인 온(CDSSO)을 사용하기 위해 DMZ의 분산 인증 UI 서버와 함께 사용될 수 있습니다. Access Manager 서버는 방화벽 뒤에 배포되며 CDSSO를 얻기 위해 Access Manager에 시도하는 액세스는 모두 분산 인증 UI 서버에서 CDC 서블릿으로 처리됩니다. CDSSO를 사용하도록 설정하려면 관련 정책 에이전트 설명서를 참조하고 다음 단계를 추가로 수행합니다.

CDC 서블릿에서 Access Manager 로그인 URL로 리디렉션할 때 지정될 수 있는 영역

이제는 CDC 서블릿에 영역 이름을 지정할 수 있으므로 Access Manager 로그인 URL로 리디렉션할 때 영역 이름이 포함되어 사용자가 특정 영역에 로그인할 수 있습니다. 예를 들면 다음과 같습니다.

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

UPN 값으로 사용자 프로필을 매핑할 수 있는 인증서 인증

이전에는 인증서 인증에서 subjectDN에 있는 dn 구성 요소만 사용하여 사용자 프로필을 매핑했습니다. 이제는 Access Manager에서 프로필 매핑을 위한 SubjectAltNameExt에 사용자 기본 이름(UPN) 값을 사용할 수 있습니다.

다중 서버 환경에서 발생하는 로그아웃 사후 인증 처리

세션 페일오버가 구성되거나 구성되지 않은 다중 서버 환경에서 사용자가 처음 로그인한 서버와 다른 서버에서 로그아웃할 때 사후 인증 처리가 발생합니다.

SAML에서 새 이름 식별자 SPI 지원

이제는 SAML에서 새 이름 식별자 서비스 공급자 인터페이스(SPI)를 지원하므로 사이트에서 SAML 명제의 이름 식별자를 사용자 정의할 수 있습니다. 사이트에서 새로운 NameIdentifierMapper 인터페이스를 구현하여 사용자 계정을 SAML 명제의 주제에 포함된 이름 식별자와 매핑할 수 있습니다.

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

Access Manager 사이트 모니터링 기능에는 다음과 같은 새 기능이 포함되어 사이트 상태 확인 동작을 지정할 수 있습니다.

등록 정보 

설명 

com.sun.identity.urlchecker.invalidate.interval

중단되었거나 응답하지 않는 사이트를 인식하기 위한 시간 간격(밀리초)입니다. 

기본값: 70,000밀리초(70초) 

com.sun.identity.urlchecker.sleep.interval

사이트 상태 확인이 일시 정지되어야 하는 시간 간격(밀리초)입니다. 

기본값: 30,000밀리초(30초) 

com.sun.identity.urlchecker.targeturl

Access Manager 프로세스 상태 확인을 위한 다른 대상 URL입니다. 

기본값: "/amserver/namingservice".

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

  1. AMConfig.properties 파일에 등록 정보와 해당 값을 추가합니다. 정책 에이전트에 대해서는 이러한 등록 정보를 AMAgents.properties 파일에 추가합니다.

  2. 값을 적용하려면 Access Manager 웹 컨테이너를 다시 시작합니다.

인증 체인에서 더 이상 두 번 인증될 필요가 없는 사용자

사이트에서 3개 LDAP 모듈로 인증 체인을 구성한다고가정합니다. 이 경우 모든 모듈은 SUFFICIENT로 설정되고, 두 옵션(iplanet-am-auth-shared-state-enabled 및 iplanet-am-auth-store-shared-state-enabled)은 true로 설정됩니다. 예를 들면 다음과 같습니다.

<AttributeValuePair>
   <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
</AttributeValuePair>

패치 5는 모듈 옵션에 사용 가능한 두 값(tryFirstPass(기본값) 및 useFirstPass)을 갖는iplanet-am-auth-shared-state-behavior-pattern 옵션을 새로 추가합니다.

이전 시나리오에서 설명한 대로 사용자가 인증을 위해 사용자 아이디와 비밀번호를 두 번씩 입력하지 않도록 하려면 인증 체인의 모든 모듈에 대해 새로운 이 옵션을 useFirstPass로 설정합니다. 이전에는 세 번째 LDAP 인스턴스에서만 존재하는 사용자가 인증을 위해 사용자 아이디와 비밀번호를 두 번씩 입력해야 했습니다.

성능 조정 스크립트 변경

패치 5에 포함된 성능 조정 스크립트에 대한 변경 내용은 다음과 같습니다.

CR# 6527663: com.sun.identity.log.resolveHostName 등록 정보의 기본값은 true가 아니라 false여야 합니다.도 참조하십시오.

비밀번호 파일을 지원하는 조정 스크립트

패치 5를 사용하면 조정 스크립트에 사용될 비밀번호를 텍스트 파일에 지정할 수 있습니다. 이전에는 명령줄 인수로만 비밀번호를 입력할 수 있어 보안 문제가 발생할 수 있었습니다. 비밀번호 파일을 사용하려면 필요에 따라 다음 변수를 파일에 설정합니다.

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

예를 들어 Application Server 8을 조정하려면

# ./amtune-as8 password-file

여기서 password-file에는 Application Server 8 관리자 비밀번호로 설정된 AS_ADMIN_PASSWORD가 포함됩니다.

ldapmodify, ldapsearch, db2index 및 dsconf Directory Server 유틸리티를 호출하는 경우 조정 스크립트에는 -j password-file 옵션이 사용됩니다.

Directory Server에 있는 불필요한 ACI를 제거하는 조정 스크립트

Access Manager 7 2005Q4가 영역 모드로 설치되면 위임 권한이 액세스 권한을 결정하는 데 사용되기 때문에 일부 Directory Server ACI가 필요하지 않습니다. Access Manager 7 2005Q4 패치 5를 사용하면 amtune-prepareDSTuner 스크립트를 실행하여 불필요한 ACI를 제거할 수 있습니다. 이 스크립트는 remacis.ldif 파일에서 ACI 목록을 판독한 다음 ldapmodify 유틸리티를 호출하여 해당 파일을 제거합니다.

amtune-prepareDSTuner 스크립트를 사용하면 Solaris, Linux, HP-UX 및 Windows 시스템에서 불필요한 ACI를 제거할 수 있습니다. 스크립트 실행 방법을 포함한 자세한 내용은 Technical Note: Sun Java System Access Manager ACI Guide를 참조하십시오.

분산 인증 UI 서버 웹 컨테이너를 조정할 수 있는 조정 스크립트

웹 컨테이너에 분산 인증 UI 서버를 배포한 후 Access Manager 조정 스크립트를 실행하여 웹 컨테이너를 조정할 수 있습니다. 다음 조정 스크립트는 개별 웹 컨테이너에 대해 JVM 및 기타 조정 옵션을 설정합니다.

표 2 Access Manager 웹 컨테이너 조정 스크립트

웹 컨테이너 

조정 스크립트 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

분산 인증 UI 서버를 위한 웹 컨테이너를 조정하려면

  1. 분산 인증 UI 서버가 배포된 시스템에는 Access Manager 서버가 설치되지 않으므로 설치된 Access Manager 서버 설치로부터 앞서 나온 표에서 보여 주는 해당 웹 컨테이너 조정 스크립트, amtune-env 구성 파일 및 amtune-utils 스크립트를 복사합니다. Solaris 또는 Linux 운영 체제를 조정하는 경우에는 amtune-os 스크립트도 복사합니다.

  2. amtune-env 구성 파일에서 매개 변수를 편집하여 웹 컨테이너와 조정 옵션을 지정합니다. REVIEW 모드로 스크립트를 실행하려면 amtune-env 파일에 AMTUNE_MODE=REVIEW를 설정합니다.

  3. REVIEW 모드로 웹 컨테이너 조정 스크립트를 실행합니다. REVIEW 모드에서 스크립트는 amtune-env 파일의 값에 기반한 조정 변경을 제안하지만 배포 시 실제로 변경을 적용하지는 않습니다.

  4. 디버그 로그 파일에 있는 조정 권장 사항을 검토합니다. 필요한 경우 이 실행에 기반하여 amtune-env 파일을 변경합니다.

  5. 조정을 변경하려면 amtune-env 파일에 AMTUNE_MODE=CHANGE를 설정합니다.

  6. CHANGE 모드로 조정 스크립트를 실행하여 배포에 대한 조정을 변경합니다.

조정 스크립트를 실행하여 Access Manager 웹 컨테이너를 조정하는 방법은 Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide의 2 장, Access Manager Tuning Scripts를 참조하십시오.

Solaris OS 및 Linux OS를 모두 조정하는 단일 amtune-os 스크립트

패치 5에는 Solaris OS 및 Linux OS를 모두 조정하는 단일 amtune-os 스크립트가 포함되어 있습니다. 스크립트는 uname -s 명령에서 OS 종류를 결정합니다. 이전에는 Access Manager에서 조정할 OS마다 별도의 amtune-os 스크립트를 제공했습니다.

Solaris 10 로컬 영역에서 완료하기 위해 실행하는 조정 스크립트

Access Manager가 Solaris 10 로컬 영역에 설치되는 경우 amtune-os를 제외한 모든 조정 스크립트가 로컬 영역에서 실행될 수 있습니다. amtune-os 스크립트는 로컬 영역에서 경고 메시지를 표시하지만 OS를 조정하지 않습니다. 그렇지만 이 스크립트는 요청한 다른 조정 스크립트를 계속 실행합니다. 이전에는 로컬 영역에서 amtune-os 스크립트가 중단되고 요청한 다음 조정 스크립트도 모두 실행되지 않았습니다.

amtune 스크립트는 Solaris 10 전역 영역에서 amtune-os를 호출하여 실행하도록 요청한 다른 스크립트와 함께 OS를 조정합니다.

Windows 시스템에 사용 가능한 조정 스크립트

패치 5에는 Windows 시스템용 조정 스크립트가 포함되어 있습니다. Windows 시스템에서 조정 스크립트를 실행하는 것은 Solaris 시스템이나 Linux 시스템에서 조정 스크립트를 실행하는 것과 비슷하지만 다음과 같은 차이점이 있습니다.

Sun Fire T1000 및 T2000 서버 조정 시 고려 사항

Access Manager가 Sun Fire T1000 또는 T2000 서버에 설치되는 경우 패치 5 Web Server 6.1 및 Application Server 8용 조정 스크립트는 다음과 같이 JVM GC ParallelGCThreads 매개 변수를 8로 설정합니다.

-XX:ParallelGCThreads=8

이 매개 변수는 32개 스레드 동시 실행 가능 시스템에서 지나치게 높을 수도 있는 가비지 컬렉션 스레드 수를 줄입니다. 그러나 Sun Fire T1000 또는 T2000 서버와 같은 32개 스레드 가상 CPU 시스템에서 전체 가비지 컬렉션 작업을 최소화하려는 경우 이 값을 16 또는 20까지로 높일 수 있습니다.

또한 CoolThreads 기술의 CMT 프로세서를 탑재하는 Solaris SPARC 시스템의 경우 /etc/opt/SUNWam/config/AMConfig.properties 파일 끝에 다음 등록 정보를 추가하는 것이 좋습니다.

com.sun.am.concurrencyRate=value

value 기본값은 16이지만 Sun Fire T1000 또는 T2000 서버의 코어 수에 따라 이 등록 정보를 더 낮은 값으로 설정할 수 있습니다.

IIS 6.0 정책 에이전트에서의 기본 인증

Microsoft 인터넷 정보 서비스(IIS) 6.0의 기본 인증을 사용할 수 있도록 지원하려면 정책 에이전트에서 사용자의 이름과 비밀번호를 확보해야 합니다. 패치 5에는 사용자 비밀번호의 DES 암호화를 통해 기본 인증 기능을 사용할 수 있도록 지원하는 새로운 클래스가 포함되어 있습니다.

IIS 6.0 기본 인증을 사용하려면 Access Manager 서버측과 IIS 6.0 정책 에이전트측 모두에서 다음 단계를 수행해야 합니다.

Access Manager 서버측:

  1. DESGenKey.java를 실행하여 비밀번호 암호화 및 해독을 위한 고유 암호화 키를 생성합니다. Solaris 시스템에서 DESGenKey.java 파일은 com/sun/identity/common 디렉토리에 있으며, /opt/SUNWam/lib 디렉토리의 am_sdk.jar 파일에 포함됩니다. 예를 들어 암호화 키를 생성하는 명령은 다음과 같습니다.

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. 1단계의 암호화 키 값을 AMConfig.properties 파일의 com.sun.am.replaypasswd.key 등록 정보에 할당합니다.

  3. ReplayPasswd.java를 사후 인증 플러그인으로 배포합니다. 플러그인을 구성할 때 다음과 같이 전체 클래스 이름을 사용합니다. com.sun.identity.authentication.spi.ReplayPasswd.

IIS 6.0 정책 에이전트측:

  1. 서비측의 암호화 키 값을AMAgent.properties 파일의 com.sun.am.replaypasswd.key 등록 정보에 할당합니다. Access Manager 서버와 IIS 6.0 정책 에이전트에서 모두 동일한 암호화 키를 사용해야 합니다.

  2. IIS 6.0 관리자에서 기본 인증을 사용하도록 설정합니다.

IIS 6.0 정책 에이전트가 세션 응답의 암호화된 비밀번호를 읽고 com.sun.am.replaypasswd.key 등록 정보의 비밀번호를 해독한 후 기본 인증을 사용하도록 인증 헤더를 설정합니다.

IIS 6.0 정책 에이전트에 대한 자세한 내용은 Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0을 참조하십시오.

CR# 6567746: HP-UX 시스템에서 Access Manager 패치 5는 비밀번호 재시도 횟수를 초과한 경우 잘못된 errorCode 값을 보고합니다.

사용자 계정이 잠긴 경우 HP-UX 시스템용 Access Manager 7 2005Q4 패치 5는 비밀번호 재시도 횟수를 초과하면 errorCode = 107 대신 errorCode = null을 보고합니다.

해결 방법: 없음.

CR# 6527663: com.sun.identity.log.resolveHostName 등록 정보의 기본값은 true가 아니라 false여야 합니다.

amtune-identity 조정 스크립트를 실행하기 전에 AMConfig.properties 파일에 false로 설정된 다음 등록 정보를 추가하는 것이 좋습니다.

com.sun.identity.log.resolveHostName=false

false 값은 호스트 이름을 결정하는 데 미치는 영향을 최소화하여 성능을 향상시킬 수 있습니다. 그러나 클라이언트 시스템의 호스트 이름이 amAuthentication.access 로그에 출력되도록 하려면 값을 true로 설정합니다.

CR# 6527528: 패치를 제거하면 일반 텍스트에 amldapuser 비밀번호가 포함된 XML 파일이 남아 있습니다.

전체 설치된 Access Manager 서버에서 패치 5를 제거하면 amAuthLDAP.xml 및 amPolicyConfig.xml 파일에 일반 텍스트 형식의 amldapuser 비밀번호가 있습니다. 플랫폼에 따라 이러한 파일이 있는 디렉토리는 다음과 같습니다.

해결 방법: amAuthLDAP.xml 및 amPolicyConfig.xml 파일을 편집하여 일반 텍스트 비밀번호를 삭제합니다.

CR# 6527516: 클라이언트 SDK와 통신하려면 WebLogic의 모든 서버에 JAX-RPC 1.0 JAR 파일이 필요합니다.

Access Manager 7 2005Q4 패치에 있는 BEA WebLogic Server용 Access Manager 구성 스크립트(amwl81config)는 WebLogic 인스턴스용 classpath에 JAX-RPC 1.1 JAR 파일을 추가합니다. 이렇게 수정하면 Sun Java System Portal Server와 같은 제품에는 유용하지만 WebLogic Server에 전체 설치(DEPLOY_LEVEL=1)로 배포된 서버에서 설치된 클라이언트 SDK와 통신할 수 없게 되며 결과적으로 예외가 발생합니다.

따라서 Access Manager 7 2005Q4 서버가 BEA WebLogic Server에 설치되는 경우 Access Manager 클라이언트 SDK와 통신하려면 startWebLogic.sh 스크립트의 CLASSPATH를 JAX-RPC 1.0 JAR 파일의 위치로 설정해야 합니다.

해결 방법: Access Manager 패치를 적용하기 전에 WebLogic Server 인스턴스가 JAX-RPC 1.1 JAR 파일 대신 JAX-RPC 1.0 JAR 파일을 사용하도록 startWebLogic.sh 스크립트에서 CLASSPATH를 설정합니다.

  1. Access Manager 서버에서 수퍼유저(root)로 로그인합니다.

  2. startWebLogic.sh 스크립트를 편집하여 CLASSPATH에서 JAX-RPC 1.0 JAR 파일을 사용하도록 변경합니다. 예를 들면 다음과 같습니다.

현재 값:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:

새 값:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:

여기서 AccessManager-base는 기본 설치 디렉토리입니다. 기본값은 Solaris 시스템의 경우 /opt이며, Linux 및 HP-UX 시스템의 경우 /opt/sun입니다. AccessManager-package-dir은 Access Manager 패키지 디렉토리입니다.

5. WebLogic Server 인스턴스를 다시 시작합니다.

CR # 6523499: 모든 Linux 시스템 사용자가 패치 5의 amsilent 파일을 읽을 수 있습니다.

Linux 시스템에서postpatch 스크립트는 모든 사용자에게 읽기 액세스를 허용하는 644 권한을 갖는 /opt/sun/identity/amsilent 파일을 만듭니다.

해결 방법: installpatch 스크립트를 실행한 후에 amsilent 파일에 대한 권한을 소유자에 대해서만 읽기 및 쓰기 액세스를 허용하도록 변경합니다. 예를 들면 다음과 같습니다.

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326: 서버의 두 번째 Access Manager 인스턴스에 패치 5를 적용하면 첫 번째 인스턴스에 대해 serverconfig.xml 파일을 덮어씁니다.

이 배포 시나리오에서는 별도의 웹 컨테이너 인스턴스에 하나씩 실행되는 두 Access Manager 인스턴스가 동일한 호스트 서버에 배포됩니다. 이 경우 다음 단계를 수행합니다.

  1. 패치 5를 적용합니다.

  2. amsilent 파일을 수정한 다음 첫 번째 Access Manager 인스턴스를 다시 배포합니다.

  3. 두 번째 Access Manager 인스턴스에 대해 amsilent 파일을 다시 수정한 다음 해당 인스턴스를 다시 배포합니다.

amsilent 파일에서 NEW_INSTANCE=false인 경우 첫 번째 Access Manager 인스턴스에 대한 serverconfig.xml 파일이 두 번째 Access Manager 인스턴스 정보를 덮어씁니다. 그런 후에 첫 번째 Access Manager 인스턴스를 다시 시작하면 해당 인스턴스가 실행되지 않습니다. 플랫폼에 따라 serverconfig.xml 파일이 있는 디렉토리는 다음과 같습니다.

해결 방법: 두 번째 Access Manager를 배포할 때 amsilent 파일에 NEW_INSTANCE=true를 설정합니다. 그러면 두 번째 Access Manager 인스턴스에 대한 serverconfig.xml 파일이 올바른 정보로 업데이트되며, 첫 번째 Access Manager 인스턴스에 대한 serverconfig.xml 파일을 덮어쓰지 않습니다.

CR# 6520016: SDK 전용 시스템에 패치 5를 설치하면 샘플 makefile을 덮어씁니다.

SDK 전용 시스템에 패치 5를 적용하면 샘플 makefile을 덮어씁니다.

해결 방법: SDK 전용 시스템에 패치 5를 적용하는 경우 다시 구성하지 않아도 되지만 샘플 makefile을 사용하려면 다음 단계를 수행하여 이 makefile에 대한 LDIF 및 등록 정보 파일을 업데이트합니다(태그 스왑 수행).

  1. DEPLOY_LEVEL=14를 사용하는 amconfig 스크립트를 실행하여 SDK를 제거하고 웹 컨테이너 구성을 해제합니다.

  2. DEPLOY_LEVEL=4를 사용하는 amconfig 스크립트를 실행하여 SDK를 다시 설치하고 웹 컨테이너를 다시 구성합니다.

CR#6515502: LDAPv3 저장소 플러그인에서 언제나 별칭 검색 속성을 올바르게 처리하는 것은 아닙니다.

대부분의 검색에서 이 문제가 해결되었지만별칭 검색 속성을 설정할 때는 주의해야 합니다. 별칭 검색 속성 값은 조직 전체에서 고유해야 합니다. 별칭 검색 속성이 둘 이상 설정되는 경우 데이터 저장소에 있는 한 항목이 한 속성과 일치하고 다른 한 항목은 다른 속성과 일치할 수 있습니다. 이 경우 Access Manager 서버에서 다음과 같은 오류가 발생합니다.

내부 인증 오류가 발생했습니다. 시스템 관리자에게 문의하십시오.

해결 방법: 없음

CR# 6515383: 분산 인증과 J2EE 에이전트가 동일한 웹 컨테이너에서 작동하지 않습니다.

분산 인증 UI 서버와 J2EE 정책 에이전트가 동일한 웹 컨테이너에 설치되면 작동하지 않습니다.

해결 방법: 두 번째 웹 컨테이너 인스턴스를 만들고 분산 인증 UI 서버와 J2EE 정책 에이전트를 서로 다른 컨테이너 인스턴스에 배포합니다.

CR# 6508103: Windows 시스템 온라인 도움말에서 Application Server 관련 응용 프로그램 오류가 반환됩니다.

Windows 시스템의 Sun Java System Application Server에 Access Manager를 배포할 때 영역 모드 콘솔의 도움말 화면 왼쪽 패널에 있는 도움말을 클릭하면 응용 프로그램 오류가 발생합니다.

해결 방법: JAVA_HOME\jre\lib\ext 디렉토리에 javaes-install-dir\share\lib\jhall.jar 파일을 복사한 다음 Application Server를 다시 시작합니다.

CR# 6507383 및 CR# 6507377: 분산 인증에 명시적인 goto URL 매개 변수가 필요합니다.

명시적 goto URL 매개 변수가 지정되지 않으면 분산 인증 UI 서버에서 Access Manager에 지정된 성공 URL에 있는 goto로 리디렉션하려고 시도합니다. 이 리디렉션은 다음과 같은 이유로 실패할 수 있습니다.

해결 방법: 항상 분산 인증 UI 서버용 명시적 goto URL 매개 변수를 지정합니다.

CR# 6402167: LDAP JDK 4.18을 사용하면 LDAP 클라이언트/Directory Server 문제가 발생합니다.

Access Manager 7 2005Q4는 Java ES 2005Q4 릴리스의 일부로서 LDAP JDK 4.18과 함께 릴리스되었지만 Access Manager 및 Directory Server 연결 문제가 다양하게 발생했습니다.

해결 방법: 다음 Sun Java System LDAP Java Development Kit 패치 중 하나를 적용합니다.

패치는http://sunsolve.sun.com.

CR# 6352135: 분산 인증 UI 서버 파일이 잘못된 위치에 설치됩니다.

Solaris 시스템에서 Java ES 설치 프로그램이 Makefile.distAuthUI, README.distAuthUI 및 amauthdistui.war 분산 인증 UI 서버 파일을잘못된 위치(/opt/SUNComm/SUNWam)에 설치합니다.

해결 방법: 올바른 위치인/opt/SUNWam에 해당 파일을 복사합니다.

주: 패치에서 해결된 분산 인증 UI 서버 문제는 모두 /opt/SUNComm/SUNWam/amauthdistui.war 파일에 포함되므로 Access Manager 서버에 패치를 적용한 다음 WAR 파일을 다시 만들어 배포할 때마다 마찬가지로 이러한 파일을 /opt/SUNWam 디렉토리에 복사해야 합니다.

CR# 6522720: Windows 및 HP-UX 시스템의 경우 콘솔 온라인 도움말에서 멀티 바이트 문자 검색이 동작하지 않습니다.

Access Manager가 Windows 또는 HP-UX 시스템에서 멀티 바이트 문자(예: 일본어)를 사용하는 로켈로 설치된 경우 콘솔 온라인 도움말에서 멀티 바이트 문자를 사용하여 키워드를 입력하는 경우 검색이 동작하지 않습니다.

해결 방법: 없음

패치 6 업데이트: Access Manager 7 2005Q4 패치 6은 Windows 시스템에서의 이 문제를 수정했습니다. 그러나 HP-UX 시스템에서는 이 문제가 여전히 존재합니다.

CR# 6524251: Windows 시스템에서 Access Manager를 구성하는 동안 출력 메시지의 멀티 바이트 문자가 올바르게 표시되지 않습니다.

Windows 시스템에서 멀티 바이트 문자를 사용하는 로켈(예: 일본어 또는 중국어)로 Access Manager가 설치되는 경우 Access Manager를 구성하는 동안 단말기 창에서 출력 메시지의 단어가 올바르게 표시되지 않습니다.

해결 방법: 없음. 그러나 구성 자체에는 이 문제가 영향을 미치지 않습니다.

CR# 6526940: Windows 시스템에서 영어 이외의 로켈로 패치 5를 설치하는 동안 메시지 텍스트 대신 등록 정보 키가 표시됩니다.

Windows 시스템에서 영어 이외의 로켈로 패치 5(124296-05)를 설치하면 설치 패널의 문자열 일부가 실제 메시지 텍스트가 아닌 등록 정보 키로 표시됩니다. 등록 정보 키의 예로 PRODUCT_NAME, JES_Patch_FinishPanel_Text1 및 JES_Patch_FinishPanel_Text2가 있습니다.

해결 방법: 없음

CR# 6513653: com.iplanet.am.session.purgedelay 등록 정보 설정에 문제가 있습니다.

Access Manager amtune 스크립트는 가능한 한 많은 Access Manager 세션을 허용하기 위해 com.iplanet.am.session.purgedelay 등록 정보를 1로 설정합니다. 이 등록 정보는 세션 제거 작업의 지연 시간(분)을 지정합니다. 그러나 Sun Java System Portal Server와 같은 클라이언트에서는 1 값으로도 충분하지 않을 수 있습니다.

해결 방법: amtune 스크립트를 실행한 후 com.iplanet.am.session.purgedelay 등록 정보를 다음과 같이 다시 설정합니다.

  1. AMConfig.properties 파일에서 해당 등록 정보를 새 값으로 설정합니다. 예를 들면 다음과 같습니다.

    com.iplanet.am.session.purgedelay=5

  2. 새 값을 적용하려면 Access Manager 웹 컨테이너를 다시 시작합니다.

Access Manager 7 2005Q4 패치 4

Access Manager 7 2005Q4 패치 4(개정판 04)에서 해결된 문제는 다음과 같습니다.

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

CR# 6470055: 분산 인증 UI 서버 성능 향상

분산 인증 UI 서버 사용자에 대한 사용자 속성 읽기, 검색 및 비교 성능을 향상시키려면 다음 단계를 수행합니다.

  1. Makefile.distAuthUI 파일에서 응용 프로그램 사용자 이름을 anonymous에서 다른 사용자로 변경합니다. 예를 들면 다음과 같습니다. 

    APPLICATION_USERNAME=user1

  2. Directory Server에서 사용자 속성 읽기, 검색 및 비교를 허용할 새로운 사용자(이 예의 경우 user1)와 ACI를 추가합니다. 새로운 ACI를 추가하는 예는 다음과 같습니다.

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn = "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079: 비밀번호가 변경되면 비밀번호 재설정 서비스에서 알림 오류를 보고합니다.

비밀번호가 변경되면 Access Manager에서 정규화되지 않은 보낸 사람 이름(Identity-Server)을 사용하여 전자 메일 알림을 제출하므로 amPasswordReset 로그에 오류 항목이 발생합니다. 예를 들면 다음과 같습니다.

07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main]
ERROR: Could not send email to user [Ljava.lang.String;@999262
com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>...
Domain name required for sender address Identity-Server

해결 방법: amPasswordResetModuleMsgs.properties 파일에서 호스트 서버의 정규화된 도메인 이름을 포함하도록 보낸 사람 주소를 다음과 같이 변경합니다.

  1. 보낸 사람 주소 레이블을 변경합니다. 예를 들면 다음과 같습니다.

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. 잠금 알림에서 올바른 보낸 사람 주소를 사용하도록 지원하기 위해 lockOutEmailFrom 등록 정보를 변경합니다. 예를 들면 다음과 같습니다.

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    amPasswordResetModuleMsgs.properties 파일은 Solaris 시스템의 경우 AccessManager-base/SUNWam/locale 디렉토리에 있으며, Linux 시스템의 경우 AccessManager-base/identity/locale 디렉토리에 있습니다.

    여기서 AccessManager-base는 기본 설치 디렉토리입니다. 기본 설치 디렉토리는 Solaris 시스템의 경우 /opt이며 Linux 시스템의 경우 /opt/sun입니다.

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 파일에 추가하지 않습니다. 이러한 새로운 등록 정보에 기본값이 아닌 다른 값을 사용하려면 다음과 같이 하십시오.

  1. 플랫폼에 따라 다음 위치에 있는 AMConfig.properties 파일에 등록 정보와 해당 값을 추가합니다.

    • Solaris 시스템: /etc/opt/SUNWam/config

    • Linux 시스템: /etc/opt/sun/identity/config

    정책 에이전트에 대해서는 이러한 등록 정보를 AMAgents.properties 파일에 추가합니다.

  2. 값을 적용하려면 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 작업을 실행합니다. 예를 들면 다음과 같습니다.

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 파일은 아직 유효합니다. 다음과 같이 이전의 복사본을 사용합니다.

  1. 서버를 중지합니다.

  2. 손상된 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

  3. 서버를 다시 시작합니다.

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 스크립트를 실행하여 다음과 같이 데이터를 마이그레이션합니다.

  1. Access Manager 6 DIT를 백업합니다.

  2. ampre70upgrade 스크립트를 실행합니다.

  3. 나중에 구성 옵션을 사용하여 Access Manager 7 2005Q4를 설치합니다.

  4. Access Manager 웹 응용 프로그램 배포를 해제합니다.

  5. Access Manager 웹 응용 프로그램을 배포합니다.

  6. XML/LDIF 변경은 제외하고 Access Manager 7 패치 3을 적용합니다. XML/LDIF 변경은 다음 단계에서 amupgrade 스크립트를 실행한 다음 적용해야 합니다.

  7. amupgrade 스크립트를 실행합니다.

  8. Access Manager 7 패치 3이 변경되었으므로 Access Manager 웹 응용 프로그램을 다시 배포합니다.

  9. 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) 이외의 다른 분산 인증 관리자를 만들려면 다음 절차를 따르십시오.

  1. 분산 인증 관리자를 위한 LDAP 사용자를 만듭니다. 예를 들면 다음과 같습니다.

    uid=DistAuthAdmin,ou=people,o=am

  2. 분산 인증 관리자를 특수 사용자 목록에 추가합니다. 예를 들면 다음과 같습니다.

    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'

주: 이 등록 정보는 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로 리디렉션됩니다. 다음과 같은 샘플 파일이 포함됩니다.

이러한 기능을 구현하려면

  1. 샘플 LoginModuleSample.java를 사용하여 사용자 정의 인증 모듈을 만듭니다.

  2. Access Manager 서버로 모듈을 로드합니다.

  3. 샘플 LoginModuleSample.xml을 사용하여 XML 파일에 RedirectCallback을 구성합니다.

  4. 모듈을 테스트하려면 외부 웹 사이트로 testExtWebSite.jsp 파일을 사용합니다.

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

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

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

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

  1. 사용자가 사용자 정의 인증 모듈에 대한 인증 프로세스/로그인 페이지를 호출합니다.

  2. 사용자가 자격 증명(사용자 이름 및 비밀번호)을 입력하고 사용자 정의 인증 모듈에 요청을 제출합니다.

  3. 사용자 정의 인증 모듈이 요청에 필요한 사용자 정보와 함께 사용자를 외부 공급/신용카드 사이트로 리디렉션합니다.

  4. 외부 공급/신용카드 사이트가 사용자 상태를 확인하고 반환된 요청의 일부로 설정되는 성공 또는 실패로 요청을 반환합니다.

  5. 사용자 정의 인증 모듈이 4단계에서 반환된 상태에 따라 사용자를 검증하고 해당 상태를 인증 서비스에 반환합니다.

  6. 사용자 인증이 성공 또는 실패로 완료됩니다.

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

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

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

Access Manager 7 2005Q4 패치 2

Access Manager 7 2005Q4 패치 2(개정판 02)에서는 패치에 포함된 README 파일에 나열된 대로 많은 문제를 해결했습니다. 패치 2에는 또한 다음과 같은 새로운 기능 및 알려진 문제점이 포함되어 있습니다.

패치 2의 새로운 기능

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

사용자 관리, Identity 저장소 및 서비스 관리 캐시의 새 등록 정보

패치 2에는 사용자 관리(Access Manager SDK), Identity 저장소(IdRepo) 및 서비스 관리 캐시에 대한 다음과 같은 새로운 등록 정보가 포함되어 있습니다. 이러한 등록 정보를 사용하면 배포 요구 사항에 따라 서로 다른 캐시를 개별적으로 활성화 및 비활성화하고 캐시 항목에 대한 TTL(time to live)을 설정할 수 있습니다.

표 3 사용자 관리, Identity 저장소 및 서비스 관리 캐시의 새 등록 정보

등록 정보 

설명 

캐시를 활성화 및 비활성화하는 새 등록 정보

com.iplanet.am.sdk.caching.enabled

Identity 저장소(IdRepo), 사용자 관리 및 서비스 관리 캐시를 활성화(true) 또는 비활성화(false)하는 전역 등록 정보입니다. true이거나 등록 정보가 AMConfig.properties 파일에 없는 경우 세 개의 캐시가 모두 활성화됩니다.

주 특정 캐시를 활성화 또는 비활성화하는 다음의 세 등록 정보는 이전의 전역 등록 정보가 false로 설정된 경우에만 적용됩니다.

com.sun.identity.amsdk.cache.enabled

사용자 관리(Access Manager SDK) 캐시만 활성화(true) 또는 비활성화(false)합니다. 

com.sun.identity.idm.cache.enabled

Identity 저장소(IdRepo) 캐시만 활성화(true) 또는 비활성화(false)합니다. 

com.sun.identity.sm.cache.enabled

서비스 관리 캐시만 활성화(true) 또는 비활성화(false)합니다. 

TTL의 새 사용자 관리 캐시 등록 정보

com.iplanet.am.sdk.cache.entry.expire.enabled

사용자 관리 캐시의 만료 시간(다음의 두 등록 정보에 의해 정의됨)을 활성화(true) 또는 비활성화(false)합니다. 

com.iplanet.am.sdk.cache.entry.user.expire.time

사용자 관리 캐시의 사용자 항목이 마지막 수정 후 유효한 상태로 유지되는 시간(분)을 지정합니다. 즉, 이 지정된 시간이 경과된 후(마지막 수정 또는 디렉토리에서 읽은 후) 캐시된 항목의 데이터가 만료됩니다. 그런 다음, 이러한 항목의 데이터에 대한 새 요청을 디렉토리에서 읽습니다. 

com.iplanet.am.sdk.cache.entry.default.expire.time

사용자 관리 캐시의 비 사용자 항목이 마지막 수정 후 유효한 상태로 유지되는 시간(분)을 지정합니다. 즉, 이 지정된 시간이 경과된 후(마지막 수정 또는 디렉토리에서 읽은 후) 캐시된 항목의 데이터가 만료됩니다. 그런 다음, 이러한 항목의 데이터에 대한 새 요청을 디렉토리에서 읽습니다. TTL의 새 Identity 저장소 캐시 등록 정보 

com.sun.identity.idm.cache.entry.expire.enabled

IdRepo 캐시의 만료 시간(다음의 두 등록 정보에 의해 정의됨)을 활성화(true) 또는 비활성화(false)합니다.  

com.sun.identity.idm.cache.entry.default.expire.time

IdRepo 캐시의 비 사용자 항목이 마지막 수정 후 유효한 상태로 유지되는 시간(분)을 지정합니다. 즉, 이 지정된 시간이 경과된 후(마지막 수정 또는 저장소에서 읽은 후) 캐시된 항목의 데이터가 만료됩니다. 그런 다음, 이러한 항목의 데이터에 대한 새 요청을 저장소에서 읽습니다. 

새 캐싱 등록 정보 사용

Access Manager 7 2005Q4 패치는 새 캐싱 등록 정보를 AMConfig.properties 파일에 자동으로 추가하지 않습니다.

새 캐싱 등록 정보를 사용하려면

  1. 텍스트 편집기를 사용하여 플랫폼에 따라 다음 디렉토리에 있는 AMConfig.properties 파일에 등록 정보 및 값을 추가합니다.

    • Solaris 시스템: /etc/opt/SUNWam/config

    • Linux 시스템: /etc/opt/sun/identity/config

  2. 값을 적용하려면 Access Manager 웹 컨테이너를 다시 시작합니다.

연합 서비스 공급자를 위한 새 등록 정보

새로운 com.sun.identity.federation.spadapter 등록 정보는 서비스 공급자측의 연합 처리 과정에 응용 프로그램별 처리를 추가하는 com.sun.identity.federation.plugins.FederationSPAdapter를 위한 구현 클래스를 정의합니다.

CR# 6385696: 기존 및 새로운 IDP 및 SP가 보이지 않습니다.를 참조하십시오.

LDAP 필터 조건 지원

패치 2에 LDAP 필터 조건 지원이 추가되었습니다. 정책 관리자는 정책을 정의할 때 조건에 LDAP 필터를 지정할 수 있습니다. 해당 정책은 사용자의 LDAP 항목이 조건에 지정된 LDAP 필터를 충족하는 경우에만 사용자에 적용됩니다. 정책 구성 서비스에 지정된 디렉토리부터 사용자의 LDAP 항목이 조회됩니다.

LDAP 필터 조건을 등록하고 사용하려면 Access Manager 7 패치 2를 설치한 후에 Solaris 시스템의 기본 디렉토리에 설치된 Access Manager와 함께 표시되는 다음 명령을 실행합니다.

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

패치 5 주 Access Manager 7 2005Q4 패치 5를 추가하고 updateschema.sh 스크립트를 실행했으면 amadmin을 사용하여 이러한 파일을 로드하지 않아도 됩니다. 자세한 내용은 새로운 updateschema.sh 스크립트로 LDIF 및 XML 파일 로드를 참조하십시오.

CR# 6283582: 로그인 실패 횟수가 Access Manager 인스턴스 간에 공유되지 않습니다.

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

# cd DirectoryServer-base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort 
-D "cn=Directory Manager" -w DirectoryMangerPassword 
-a -f /etc/opt/SUNWam/accountLockout.ldif
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/accountLockoutData.xml

DirectoryServer-base의 기본값은 Solaris 시스템에서는 /var/opt/mps/serverroot이고 Linux 시스템에서는 /var/opt/sun/directory-server입니다.

패치 5 주 Access Manager 7 2005Q4 패치 5를 추가하고 updateschema.sh 스크립트를 실행했으면 amadmin을 사용하여 이러한 파일을 로드하지 않아도 됩니다. 자세한 내용은 새로운 updateschema.sh 스크립트로 LDIF 및 XML 파일 로드를 참조하십시오.

CR# 6293673: 세션 시간 초과 알림을 보낼 때 원래 세션 정보를 유지해야 합니다.

AMConfig.properties 파일의 새로운 com.sun.identity.session.property.doNotTrimList 등록 정보는 쉼표로 분리된 세션 등록 정보 이름을 포함할 수 있습니다. 세션이 시간 초과되면 이 목록에 정의된 등록 정보는 세션이 삭제되기 전에 액세스할 수 있도록 잘리지 않습니다. 예를 들면 다음과 같습니다.

com.sun.identity.session.property.doNotTrimList=UserId,HostName

CR# 6244578: Access Manager는 브라우저 쿠키 지원이 비활성/사용할 수 없을 경우 사용자에게 경고해야 합니다.

AMConfig.properties 파일의 새로운 com.sun.identity.am.cookie.check 등록 정보는 서버가 브라우저의 쿠키 지원/쿠키 활성 여부를 확인할지 여부를 지정합니다. true 값을 사용하면 서버는 브라우저에서 쿠키 지원/쿠키 활성 여부를 확인하고 지원하지 않거나 활성화되지 않은 경우 오류 페이지를 표시합니다. 서버가 인증 기능에 쿠키를 사용하지 않는 모드를 지원하는 경우 이 값은 false(기본값)로 설정해야 합니다.

CR# 6236892: 로그인 뒤에 CDCServlet이 AuthNResponse를 처리하는 동안 사용할 이미지/텍스트 자리 표시자

다음과 같은 새로운 등록 정보가 AMConfig.properties 파일에 추가되었으며 CDCServlet으로 읽을 수 있습니다.

CR# 6363157: 지속 검색이 반드시 필요하지만 새로운 등록 정보로 인해 지속 검색을 사용할 수 없습니다.

AMConfig.properties 파일의 새로운 com.sun.am.event.connection.disable.list 등록 정보는 사용하지 않도록 설정할 이벤트 연결을 지정합니다. 값(대소문자 구분)은 다음과 같을 수 있습니다.

aci - LDAP 필터(aci=*)를 사용하는 검색에서 aci 속성으로의 변경

sm - sunService 또는 sunServiceComponent 표시자 객체 클래스가 있는 객체를 포함하는 Access Manager 정보 트리 또는 서비스 관리 노드에서의 변경. 예를 들어 보호되는 자원에 대한 액세스 권한을 정의하는 정책을 만들거나 기존 정책에 대한 규칙, 주제, 조건 또는 응답 공급자를 수정할 수 있습니다.

um - 사용자 디렉토리 또는 사용자 관리 노드에서의 변경. 예를 들어 사용자의 이름이나 주소를 변경할 수 있습니다.

예를 들어 Access Manager 정보 트리 또는 서비스 관리 노드로의 변경에 대해 지속 검색을 사용할 수 없도록 설정하려면 다음을 수행합니다.

com.sun.am.event.connection.disable.list=sm

여러 개의 값을 지정하려면 각각의 값을 쉼표로 구분합니다.

주의 – 주의 –

지속 검색을 수행하면 Directory Server에서 약간의 성능 오버헤드가 발생합니다. 이러한 성능 오버헤드를 일부라도 제거하는 것이 작업 환경에 정말로 중요하다고 생각하면 com.sun.am.event.connection.disable.list 등록 정보를 사용하여 지속 검색을 하나 이상 사용하지 않도록 설정하면 됩니다.

그러나 지속 검색을 사용하지 않도록 설정하기 전에 앞에서 설명한 제한 사항을 반드시 알고 있어야 합니다. 지속 검색을 사용하지 않도록 설정해야 하는 경우를 제외하고는 이 등록 정보를 변경하지 않는 것이 가장 좋습니다. 원래 이 등록 정보는 2.1 J2EE 에이전전트가 여러 개 사용될 때 각 에이전트마다 이러한 지속 검색을 설정하고 있기 때문에 Directory Server에서 발생하는 오버헤드를 피하기 위해 도입되었습니다. 이제는 2.2 J2EE에서 더 이상 이러한 지속 검색을 설정하지 않으므로 이 등록 정보를 사용할 필요가 없습니다.

자세한 내용은 지속 검색 사용 불가능에 대한 상세 정보 문서화(6486927)를 참조하십시오.

CR# 6385696: 기존 및 새로운 IDP 및 SP가 보이지 않습니다.

AMConfig.properties 파일의 새로운 com.sun.identity.federation.spadapter 등록 정보는 응용 프로그램이 명제 및 응답 정보를 얻는 위치인 연합 서비스 제공자 어댑터의 기본 구현을 지정합니다. 예를 들면 다음과 같습니다.

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Access Manager 7 2005Q4 패치 1

Access Manager 7 2005Q4 패치 1(개정판 01)에서는 패치에 포함된 README 파일에 나열된 대로 많은 문제를 해결했습니다. 패치 1에는 또한 다음과 같은 새로운 기능 및 알려진 문제점이 포함되어 있습니다.

디버그 파일 생성

AMConfig.properties 파일의 com.iplanet.services.debug.level 등록 정보가 error로 설정되어 있더라도 기본적으로 Access Manager 디버그 파일이 디버그 디렉토리에 생성됩니다. Access Manager 7 패치 1 이 릴리스되기 전에는 첫 번째 디버그 메시지가 파일에 기록되는 경우에만 디버그 파일이 생성되었습니다.

LDAPv3 플러그인에서 역할 및 필터링된 역할 지원

Sun Java System Directory Server에 데이터가 저장된 경우 Access Manager 7 패치 1은 LDAPv3 플러그인에서 역할 및 필터링된 역할에 대한 지원을 추가합니다. 자세한 내용은 LDAPv3 플러그인의 역할 및 필터링된 역할 지원 문제 문서화(6365196)를 참조하십시오.

CR# 6320475: 서버측 com.iplanet.am.session.client.polling.enable이 true여서는 안 됩니다.

서버측 AMConfig.properties 파일의 com.iplanet.am.session.client.polling.enable 등록 정보는 기본적으로 false이며 true로 재설정되어서는 안 됩니다.

CR# 6358751: 암호화 키에 공백이 삽입되어 있는 경우 Access Manager 7 패치 1 적용이 실패합니다.

비밀번호 암호화 키에 공백이 포함되어 있는 경우 패치 적용이 실패합니다.

해결 방법: 공백을 포함하지 않는 새로운 암호화 키를 사용합니다. 암호화 키를 변경하는 단계에 대한 자세한 설명은Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide의 부록 B, Changing the Password Encryption Key을 참조하십시오.