Sun Java System Access Manager 7.1 관리 설명서

Previous: 1 액세스 제어

2 디렉토리 관리 및 기본 서비스

Sun Java System Access Manager 7.1 관리 설명서의 제2부입니다. 디렉토리 관리 장에서는 Access Manager를 레거시 모드로 배포할 때 디렉토리 객체를 관리하는 방법에 대해 설명합니다. 다른 장에서는 Access Manager의 일부 기본 서비스를 구성하고 사용하는 방법에 대해 설명합니다. 다음 내용으로 구성되어 있습니다.

7장 디렉토리 관리

디렉토리 관리 탭은 Access Manager를 레거시 모드로 설치할 경우에만 표시됩니다. 디렉토리 관리 기능은 Sun Java System Directory Server를 사용하는 Access Manager 배포를 위한 Identity 관리 솔루션을 제공합니다.

레거시 모드 설치 옵션에 대한 자세한 내용은 Sun Java Enterprise System 5 Installation Guide for UNIX를 참조하십시오.

디렉토리 객체 관리

디렉토리 관리 탭에는 Directory Server 객체를 보고 관리하는 데 필요한 모든 구성 요소가 포함되어 있습니다. 이 절에서는 객체 유형과 객체 유형을 구성하는 방법에 대해 설명합니다. Access Manager 콘솔 또는 명령줄 인터페이스를 사용하여 사용자, 역할, 그룹, 조직, 하위 조직 및 컨테이너 객체를 정의, 수정 또는 삭제할 수 있습니다. 콘솔에는 다양한 권한으로 디렉토리 객체를 생성하고 관리하는 기본 관리자가 있습니다. (역할을 기반으로 추가 관리자를 만들 수 있습니다.) 관리자는 Access Manager 설치 시 Directory Server 내에 정의됩니다. 다음은 사용자가 관리할 수 있는 Directory Server 객체입니다.

조직

조직은 기업에서 부서와 자원을 관리하는 데 사용되는 최상위 수준의 계층 구조를 나타냅니다. 설치 시 Access Manager는 Access Manager 엔터프라이즈 구성을 관리하기 위해 최상위 수준 조직(설치하는 동안 정의됨)을 동적으로 만듭니다. 설치 후에 추가 조직을 만들어 별도 엔터프라이즈를 관리할 수 있습니다. 생성되는 모든 조직은 최상위 조직 아래에 놓입니다.

조직 만들기

[디렉토리] 관리 탭을 누릅니다.

[조직] 목록에서 [새로 만들기]를 누릅니다.

필드에 대한 값을 입력합니다. [이름] 필드만 필수입니다. 필드는 다음과 같습니다.

이름

조직의 이름 값을 입력합니다.

도메인 이름

조직의 완전한 DNS(Domain Name System) 이름을 입력합니다(있을 경우).

조직 상태

active 또는 inactive 상태를 선택합니다. 기본값은 active입니다. 이 값은 조직의 수명 동안 [등록 정보] 아이콘을 선택하여 언제든지 변경할 수 있습니다. inactive를 선택하면 조직에 로그인할 때 사용자 액세스가 사용 불가능하게 됩니다.

조직 별칭

이 필드는 URL 로그인에서 별칭을 사용하여 인증할 수 있도록 조직에 대한 별칭 이름을 정의합니다. 예를 들어, 조직 이름이 exampleorg이고 123 및 abc를 별칭으로 정의하는 경우 다음 URL 중 하나를 사용하여 조직에 로그인할 수 있습니다.

http://machine.example.com/amserver/UI/Login?org=exampleorg

http://machine.example.com/amserver/UI/Login?org=abc

http://machine.example.com/amserver/UI/Login?org=123

조직 별칭 이름은 조직 전체에서 고유해야 합니다. 고유 속성 목록을 사용하여 고유성을 강제로 적용할 수 있습니다.

DNS 별칭 이름

조직의 DNS 이름에 대해 별칭 이름을 추가할 수 있습니다. 이 속성은 “실제” 도메인 별칭(임의의 문자열은 허용 안 됨)만 수락합니다. 예를 들어, DNS 이름이 example.com이고 example1.com 및 example2.com을 exampleorg 조직에 대한 별칭으로 정의하는 경우 다음 URL 중 하나를 사용하여 조직에 로그인할 수 있습니다.

http://machine.example.com/amserver/UI/

Login?org=exampleorg

http://machine.example1.com/amserver/

UI/Login?org=exampleorg

http://machine.example2.com/amserver/

UI/Login?org=exampleorg

고유 속성 목록

조직의 사용자에 대한 고유 속성 이름 목록을 추가할 수 있습니다. 예를 들어, 전자 메일 주소를 지정하는 고유한 속성 이름을 추가할 경우 동일한 전자 메일 주소를 가지는 두 명의 사용자를 만들 수 없습니다. 또한, 이 필드에서는 쉼표로 구분된 목록을 허용합니다. 목록에 있는 속성 이름 중 하나가 고유성을 정의합니다. 예를 들어, 필드에 다음과 같은 속성 이름 목록이 있고

PreferredDomain, AssociatedDomain

PreferredDomain이 특정 사용자에 대한 http://www.example.com으로 정의되는 경우 전체 쉼표로 구분된 목록이 해당 URL에 대한 고유성으로 정의됩니다. 고유 속성 목록에 이름 지정 속성인 'ou'를 추가하면 기본 그룹, 사용자 컨테이너의 속성에 고유성이 강제 적용되지 않습니다. (ou=Groups,ou=People)

모든 하위 조직에 고유성이 강제 적용됩니다.

주 –
고유 속성은 영역 모드에서 설정할 수 없습니다. 또한 레거시 모드의 경우 7.0 또는 7.1 기반 콘솔에서 설정할 수도 없습니다. 고유 속성 목록을 만들려면 6.3 기반 콘솔에 로그인해야 합니다. 자세한 내용은 레거시 모드 6.3 콘솔을 참조하십시오.

[확인]을 누릅니다.

새 조직이 조직 목록에 표시됩니다. 조직을 만드는 동안 정의한 등록 정보를 편집하려면 편집할 조직의 이름을 누르고 등록 정보를 변경한 다음 저장을 누릅니다.

조직 삭제

삭제할 조직의 이름 옆에 있는 확인란을 선택합니다.

[삭제]를 누릅니다.

주 –
삭제를 수행할 때 경고 메시지가 나타나지 않습니다. 조직 내의 모든 항목이 삭제되고 실행 취소를 수행할 수 없습니다.

정책에 조직 추가

Access Manager 객체는 정책의 주제 정의를 통해 정책에 추가됩니다. 정책을 작성하거나 수정할 때 조직, 역할, 그룹 및 사용자를 주제로 정의할 수 있습니다. 주제가 정의되고 나면 정책이 객체에 적용됩니다. 자세한 내용은 정책 관리를 참조하십시오.

컨테이너

객체 클래스와 속성의 차이로 인해 조직 항목을 사용할 수 없는 경우 컨테이너 항목을 사용합니다. Access Manager 컨테이너 항목과 Access Manager 조직 항목이 LDAP 객체 클래스 organizationalUnit 및 organization과 반드시 같을 필요가 없다는 것이 중요합니다. 추상적인 identity 항목입니다. 이상적인 경우라면 컨테이너 항목 대신 조직 항목이 사용됩니다.

주 –

컨테이너 표시는 선택 사항입니다. 컨테이너를 보려면 [구성] > [콘솔 등록 정보] 아래의 관리 서비스에서 [컨테이너 표시]를 선택해야 합니다.

컨테이너 만들기

새 컨테이너가 생성될 조직의 위치 링크 또는 컨테이너를 선택합니다.

[컨테이너] 탭을 누릅니다.

[컨테이너] 목록에서 [새로 만들기]를 누릅니다.

만들려는 컨테이너의 이름을 입력합니다.

[확인]을 누릅니다.

컨테이너 삭제

[컨테이너] 탭을 누릅니다.

삭제할 컨테이너의 이름 옆에 있는 확인란을 선택합니다.

[삭제]를 누릅니다.

주 –
컨테이너를 삭제하면 해당 컨테이너에 존재하는 모든 객체가 삭제됩니다. 여기에는 모든 객체와 하위 컨테이너가 포함됩니다.

그룹 컨테이너

그룹 컨테이너는 그룹을 관리하는 데 사용됩니다. 그룹 컨테이너는 그룹과 다른 그룹 컨테이너만 포함할 수 있습니다. 그룹 컨테이너 그룹은 모든 관리 대상 그룹에 대한 부모 항목으로 동적으로 할당됩니다. 원하는 경우 추가 그룹 컨테이너를 추가할 수 있습니다.

주 –

그룹 컨테이너의 표시는 선택 사항입니다. 그룹 컨테이너를 보려면 [구성] > [콘솔 등록 정보]의 관리 서비스에서 [그룹 컨테이너 사용 가능]을 선택해야 합니다.

그룹 컨테이너 만들기

새 그룹 컨테이너를 포함할 조직의 위치 링크 또는 그룹 컨테이너를 선택합니다.

[그룹 컨테이너] 탭을 선택합니다.

[그룹 컨테이너] 목록에서 [새로 만들기]를 누릅니다.

이름 필드에 값을 입력하고 [확인]을 누릅니다. [그룹 컨테이너] 목록에 새 그룹 컨테이너가 표시됩니다.

그룹 컨테이너 삭제

삭제할 그룹 컨테이너가 포함된 조직으로 이동합니다.

[그룹 컨테이너] 탭을 선택합니다.

삭제할 그룹 컨테이너 옆의 확인란을 선택합니다.

[삭제]를 누릅니다.

그룹

그룹은 공통된 기능, 특징 또는 관심사를 가진 사용자 모음을 나타냅니다. 일반적으로 이 그룹에는 연관된 권한이 없습니다. 그룹은 두 가지 수준 즉, 조직 내에서와 다른 관리 대상 그룹 내에서 존재할 수 있습니다. 다른 그룹 내에서 존재하는 그룹을 하위 그룹이라고 부릅니다. 하위 그룹은 상위 그룹 내에서 “물리적으로” 존재하는 하위 노드입니다.

Access Manager는 또한 단일 그룹에 포함된 기존 그룹의 “표현”인 중첩 그룹을 지원합니다. 하위 그룹과 달리 중첩 그룹은 DIT 내의 어디에나 존재할 수 있습니다. 중첩 그룹은 다수의 사용자에 대한 액세스 권한을 신속하게 설정할 수 있게 합니다.

정적 그룹과 동적 그룹의 두 가지 유형의 그룹을 만들 수 있습니다. 사용자는 정적 그룹에만 수동으로 추가할 수 있습니다. 동적 그룹은 필터를 통해 사용자의 추가를 제어합니다. 중첩 또는 하위 그룹은 두 유형 모두에 추가될 수 있습니다.

정적 그룹

정적 그룹은 사용자가 지정한 관리 대상 그룹 유형을 기준으로 만들어집니다. groupOfNames 또는 groupOfUniqueNames 객체 클래스를 사용하여 그룹 항목에 그룹 구성원을 추가합니다.

주 –

기본적으로 관리 대상 그룹 유형은 동적입니다. 관리 서비스 구성에서 이 기본값을 변경할 수 있습니다.

동적 그룹

LDAP 필터를 사용하여 동적 그룹을 만듭니다. 모든 항목이 필터를 통해 걸러져 그룹에 동적으로 할당됩니다. 필터는 항목에서 속성을 검색하여 속성이 포함된 항목을 반환합니다. 예를 들어, 건물 번호를 기반으로 그룹을 만들 경우 필터를 사용하여 해당 건물 번호 속성을 포함하는 모든 사용자 목록을 반환할 수 있습니다.

주 –

참조 무결성 플러그 인을 사용하려면 Access Manager를 Directory Server와 함께 구성해야 합니다. 참조 무결성 플러그 인은 사용 가능하게 될 경우 삭제 또는 이름 바꾸기 작업 직후에 지정된 속성에 대한 무결성 업데이트를 수행합니다. 따라서 관련된 항목 간의 관계가 데이터베이스 전체에서 유지됩니다. 데이터베이스 색인은 Directory Server에서 검색 성능을 향상시킵니다. 플러그인 사용에 대한 자세한 내용은 Access Manager 6 Migration Guide를 참조하십시오.

정적 그룹을 만들려면

새 그룹을 만들 조직, 그룹 또는 그룹 컨테이너로 이동합니다.

[그룹] 목록에서 [새 정적]을 누릅니다.

[이름] 필드에 그룹의 이름을 입력합니다. [다음]을 누릅니다.

[사용자가 이 그룹에 가입할 수 있음] 속성을 선택하여 사용자가 그룹에 직접 가입할 수 있게 합니다.

[확인]을 누릅니다.

그룹이 만들어지면 그룹 이름을 선택하고 [일반] 탭을 눌러서 [사용자가 이 그룹에 가입할 수 있음] 속성을 편집할 수 있습니다.

정적 그룹에서 구성원 추가 또는 제거

[그룹] 목록에서 구성원을 추가할 그룹을 선택합니다.

[작업 선택] 메뉴에서 수행할 작업을 선택합니다. 수행할 수 있는 작업은 다음과 같습니다.

새 사용자

이 작업은 새 사용자를 만들며 사용자 정보를 저장할 때 사용자를 그룹에 추가합니다.

사용자 추가

이 작업은 기존 사용자를 그룹에 추가합니다. 이 작업을 선택하면 추가할 사용자를 지정할 검색 기준을 만들 수 있습니다. 기준을 만드는 데 사용되는 필드는 ANY 또는 ALL 연산자를 사용합니다. ALL은 지정된 모든 필드에 해당하는 사용자를 반환합니다. ANY는 지정된 필드 중 하나 이상에 해당하는 사용자를 반환합니다. 필드를 비워두면 해당 특정 속성과 일치하는 가능한 모든 항목을 반환합니다.

검색 기준을 작성하고 나서 [다음]을 누릅니다. 반환된 사용자 목록에서 추가할 사용자를 선택하고 [마침]을 누릅니다.

그룹 추가

이 작업은 중첩 그룹을 현재 그룹에 추가합니다. 이 작업을 선택할 경우 검색 범위와 그룹 이름(“*” 와일드카드 사용 가능)을 포함하는 검색 조건을 만들며 사용자가 그룹에 직접 가입할 수 있는지 여부를 지정할 수 있습니다. 정보를 입력하고 [다음]을 누릅니다. 반환된 그룹 목록에서 추가할 그룹을 선택하고 [마침]을 누릅니다.

구성원 제거

이 작업은 그룹에서 구성원(사용자 및 그룹 포함)을 제거하지만 삭제하지는 않습니다. 제거할 구성원을 선택하고 [작업 선택] 메뉴에서 [구성원 제거]를 선택합니다.

구성원 삭제

이 작업은 선택한 구성원을 영구적으로 삭제합니다. 삭제할 구성원을 선택한 다음 [구성원 삭제]를 선택합니다.

동적 그룹을 만들려면

새 그룹을 만들 조직 또는 그룹으로 이동합니다.

[그룹] 탭을 누릅니다.

[새 동적]을 누릅니다.

[이름] 필드에 그룹의 이름을 입력합니다.

LDAP 검색 필터를 생성합니다.

기본적으로 Access Manager는 기본 검색 필터 인터페이스를 표시합니다. 필터를 생성하는 데 사용되는 기본 필드는 ANY 또는 ALL 연산자를 사용합니다. ALL은 지정된 모든 필드에 해당하는 사용자를 반환합니다. ANY는 지정된 필드 중 하나 이상에 해당하는 사용자를 반환합니다. 필드를 비워두면 해당 특정 속성과 일치하는 가능한 모든 항목을 반환합니다.

[확인]을 누르면 검색 조건과 일치하는 모든 사용자가 자동으로 그룹에 추가됩니다.

동적 그룹에서 구성원을 추가 또는 제거하려면

[그룹] 목록에서 구성원을 추가할 그룹의 이름을 누릅니다.

[작업 선택] 메뉴에서 수행할 작업을 선택합니다. 수행할 수 있는 작업은 다음과 같습니다.

그룹 추가

이 작업은 중첩 그룹을 현재 그룹에 추가합니다. 이 작업을 선택할 경우 검색 범위와 그룹 이름(“*” 와일드카드 사용 가능)을 포함하는 검색 조건을 만들며 사용자가 그룹에 직접 가입할 수 있는지 여부를 지정할 수 있습니다. 정보를 입력하고 [다음]을 누릅니다. 반환된 그룹 목록에서 추가할 그룹을 선택하고 [마침]을 누릅니다.

구성원 제거

이 작업은 그룹에서 구성원(그룹 포함)을 제거하지만 삭제하지는 않습니다. 제거할 구성원을 선택한 다음 [구성원 제거]를 선택합니다.

구성원 삭제

이 작업은 선택한 구성원을 영구적으로 삭제합니다. 삭제할 구성원을 선택한 다음 [구성원 삭제]를 선택합니다.

정책에 그룹 추가

Access Manager 객체는 정책의 주제 정의를 통해 정책에 추가됩니다. 정책을 작성하거나 수정할 때 정책의 주제 페이지에서 조직, 역할, 그룹 및 사용자를 주제로 정의할 수 있습니다. 주제가 정의되고 나면 정책이 객체에 적용됩니다. 자세한 내용은 정책 관리를 참조하십시오.

사용자 컨테이너

사용자 컨테이너는 조직 내에서 사용자가 만들어질 때 모든 사용자가 할당되는 기본 LDAP 조직 구성 단위입니다. 사용자 컨테이너는 조직 수준에서 표시되거나 사용자 컨테이너 수준에서 하위 사용자 컨테이너로 표시될 수 있습니다. 사용자 컨테이너는 다른 사용자 컨테이너와 사용자만 포함할 수 있습니다. 원하는 경우 추가 사용자 컨테이너를 조직에 추가할 수 있습니다.

주 –

사용자 컨테이너의 표시는 선택 사항입니다. 사용자 컨테이너를 보려면 관리 서비스에서 [사용자 컨테이너 사용 가능]을 선택해야 합니다.

사용자 컨테이너 만들기

새 사용자 컨테이너를 만들려는 조직이나 사용자 컨테이너로 이동합니다.

[사용자 컨테이너] 목록에서 [새로 만들기]를 누릅니다.

만들려는 사용자 컨테이너의 이름을 입력합니다.

[확인]을 누릅니다.

사용자 컨테이너를 삭제하려면

삭제할 사용자 컨테이너를 포함하는 조직이나 사용자 컨테이너로 이동합니다.

삭제할 사용자 컨테이너의 이름 옆에 있는 확인란을 선택합니다.

[삭제]를 누릅니다.

주 –
사용자 컨테이너를 삭제하면 해당 사용자 컨테이너에 존재하는 모든 객체가 삭제됩니다. 여기에는 모든 사용자와 하위 사용자 컨테이너가 포함됩니다.

사용자

사용자는 개인의 아이디를 나타냅니다. Access Manager Identity 관리 모듈을 통해 사용자를 조직, 컨테이너 및 그룹에서 만들고 삭제할 수 있으며 역할 및/또는 그룹에서 추가 또는 제거할 수 있습니다. 또한 서비스를 사용자에게 할당할 수도 있습니다.

주 –

amadmin과 동일한 사용자 아이디를 사용하여 하위 조직의 사용자를 만들 경우 amadmin에 대한 로그인이 실패하게 됩니다. 이런 문제가 발생할 경우 관리자는 Directory Server 콘솔을 통해 사용자의 아이디를 변경해야 합니다. 이렇게 하면 관리자는 기본 조직에 로그인할 수 있습니다. 또한 인증 서비스에서 사용자 검색을 시작할 DN을 사용자 컨테이너 DN으로 설정하여 로그인 프로세스 도중 고유한 일치가 반환되도록 할 수 있습니다.

사용자 만들기

사용자를 만들 조직, 컨테이너 또는 사용자 컨테이너로 이동합니다.

해당 사용자 탭을 누릅니다.

사용자 목록에서 [새로 만들기]를 누릅니다.

다음 값의 데이터를 입력합니다.

사용자 아이디

이 필드에는 사용자가 Access Manager에 로그인할 때 사용하는 이름을 입력합니다. 이 등록 정보는 DN이 아닌 값일 수 있습니다.

이름

이 필드에는 사용자의 이름을 입력합니다. 이름 값 및 성 값은 현재 로그인된 사용자 필드에서 사용자를 식별합니다. 이 값은 필수 값이 아닙니다.

성

이 필드에는 사용자의 성을 입력합니다. 이름 값 및 성 값은 사용자를 식별합니다.

전체 이름

이 필드에는 사용자의 전체 이름을 입력합니다.

비밀번호

이 필드에는 사용자 아이디 필드에 지정된 이름의 비밀번호를 입력합니다.

비밀번호(확인)

비밀번호를 확인합니다.

사용자 상태

이 옵션은 사용자에게 Access Manager를 통한 인증이 허용되었는지 여부를 나타냅니다. 활성 사용자만 인증될 수 있습니다. 기본값은 활성입니다.

[확인]을 누릅니다.

사용자 프로필을 편집하려면

관리 역할이 할당되지 않은 사용자가 Access Manager에 대해 인증될 경우 기본 보기는 해당 사용자 프로필입니다. 또한 적절한 권한이 있는 관리자가 사용자 프로필을 편집할 수 있습니다. 이 보기에서 사용자는 개인 프로필 특정의 속성 값을 수정할 수 있습니다. 사용자 프로필 보기에 표시되는 속성은 확장할 수 있습니다. 객체 및 Identity에 대한 사용자 정의 속성 추가에 대한 자세한 내용은 Access Manager Developer's Guide를 참조하십시오.

프로필을 편집할 사용자를 선택합니다. 기본적으로 일반 보기가 표시됩니다.

다음 필드를 편집합니다.
이름

이 필드에는 사용자의 이름을 입력합니다.

성

이 필드에는 사용자의 성을 입력합니다.

전체 이름

이 필드에는 사용자의 전체 이름을 입력합니다.

비밀번호

사용자 비밀번호를 추가 및 확인하려면 편집 링크를 누릅니다.

전자 메일 주소

이 필드에는 사용자의 전자 메일 주소를 입력합니다.

사원 번호

이 필드에는 사용자의 사원 번호를 입력합니다.

전화 번호

이 필드에는 사용자의 전화 번호를 입력합니다.

집 주소

이 필드에는 사용자의 집 주소를 입력합니다.

사용자 상태
이 옵션은 사용자에게 Access Manager를 통한 인증이 허용되었는지 여부를 나타냅니다. 활성 사용자만 Access Manager를 통해 인증될 수 있습니다. 기본값은 활성입니다. 다음 중 하나를 풀다운 메뉴에서 선택할 수 있습니다.
- 활성 — Access Manager를 통해 사용자를 인증할 수 있습니다.
- 비활성 — Access Manager를 통해 사용자를 인증할 수 없지만 사용자 프로필은 디렉토리에 저장된 채로 남습니다.
  
  주 –
  사용자 상태를 비활성으로 변경하는 것은 Access Manager를 통한 인증에만 영향을 줍니다. Directory Server는 nsAccountLock 속성을 사용하여 사용자 계정 상태를 결정합니다. Access Manager 인증에 대해 비활성화된 사용자 계정은 여전히 Access Manager가 필요하지 않은 작업을 수행할 수 있습니다. 단순히 Access Manager 인증에 대해서가 아니라 디렉토리에서 사용자 계정을 비활성화하려면 nsAccountLock 값을 false로 설정합니다. 사이트의 위임된 관리자가 정기적으로 사용자를 비활성화할 경우 nsAccountLock 속성을 Access Manager 사용자 프로필 페이지에 추가하는 방법을 고려하십시오. 자세한 내용은 Sun Java System Access Manager 7.1 Developer’s Guide를 참조하십시오.
계정 만료 날짜

이 속성이 있으면 현재 날짜와 시간이 지정된 계정 만료일을 지난 경우 인증 서비스는 로그인을 허용하지 않습니다. 이 속성의 형식은 mm/dd/yyyy hh:mm입니다.

사용자 인증 구성

이 속성은 사용자의 인증 체인을 설정합니다.

사용자 별칭 목록

이 필드는 사용자에게 적용될 수 있는 별칭 목록을 정의합니다. 이 속성에 구성된 별칭을 사용하려면 LDAP 서비스의 사용자 항목 검색 속성 필드에 iplanet-am-user-alias-list 속성을 추가하여 LDAP 서비스를 수정해야 합니다.

기본 로켈

이 필드는 사용자의 로켈을 지정합니다.

성공 URL

이 속성은 인증 성공 시 사용자가 리디렉션되는 URL을 지정합니다.

실패 URL

이 속성은 인증 실패 시 사용자가 리디렉션되는 URL을 지정합니다.

비밀번호 재설정 옵션

이 옵션은 잊어버린 비밀번호를 복구하는 데 사용되는 비밀번호 분실 페이지에서 질문을 선택하는 데 사용됩니다.

사용자 검색 자원 오퍼링

사용자에 대한 사용자 검색 서비스의 자원 오퍼링을 설정합니다.

MSIDSN 번호

MSISDN 인증을 사용 중인 경우 사용자의 MSISDN 번호를 정의합니다.

역할 및 그룹에 사용자 추가

[사용자] 탭을 누릅니다.

수정할 사용자의 이름을 누릅니다.

[역할] 또는 [그룹] 탭을 선택합니다.

사용자를 추가할 역할이나 그룹을 선택하고 [추가]를 누릅니다.

[저장]을 누릅니다.

주 –
역할이나 그룹에서 사용자를 제거하려면 역할 또는 그룹을 선택하고 [제거]를 누른 다음 [저장]을 누릅니다.

정책에 사용자 추가

역할

역할은 그룹의 개념과 비슷한 Directory Server 항목 체계입니다. 그룹이 구성원을 가지므로 역할도 구성원을 가집니다. 역할의 구성원은 역할을 소유하는 LDAP 항목입니다. 역할의 기준 자체는 속성과 함께 LDAP 항목으로 정의되며 항목의 고유 이름(DN) 속성에 의해 식별됩니다. Directory Server에는 여러 가지 유형의 역할이 있지만 Access Manager는 그 중에서(관리 대상 역할)만 관리할 수 있습니다.

주 –

다른 Directory Server 역할 유형은 Access Manager 콘솔에서 관리할 수는 없지만 디렉토리를 배포하는 데 사용할 수 있습니다. 정책의 주제 정의에 다른 Directory Server 유형을 사용할 수 있습니다. 정책 주제에 대한 자세한 내용은 정책 만들기를 참조하십시오.

사용자는 하나 이상의 역할을 소유할 수 있습니다. 예를 들어, 세션 서비스 및 비밀번호 재설정 서비스의 속성을 갖는 계약자 역할을 만들 수 있습니다. 새 계약직 직원이 회사에 합류하면 관리자는 계약자 항목에 개별 속성을 설정하는 대신 이 역할을 할당할 수 있습니다. 계약자가 엔지니어링 부서에서 일하며, 엔지니어링 직원이 사용할 수 있는 서비스와 액세스 권한을 요구하는 경우, 관리자는 계약자를 계약자 역할 외에 엔지니어링 역할에도 지정할 수 있습니다.

Access Manager는 역할을 사용하여 액세스 제어 명령을 적용합니다. 처음 설치되면 Access Manager는 관리자 사용 권한을 정의하는 액세스 제어 명령(ACI)을 구성합니다. 그런 다음 이러한 ACI는 사용자에게 할당될 때 사용자의 액세스 권한을 정의하는 역할(예: 조직 관리자 역할 및 조직 도움말 데스크 관리자 역할)에 지정됩니다.

사용자는 관리 서비스에서 사용자 프로필 페이지에 역할 표시 속성이 사용 가능하게 된 경우에만 할당된 역할을 볼 수 있습니다.

주 –

다음과 같은 두 가지 역할 유형이 있습니다.

정적 — 정적 역할은 역할을 만들 때 사용자 추가 없이 만듭니다. 역할이 만들어진 다음 해당 역할에 특정 사용자를 추가할 수 있습니다. 따라서 주어진 역할에 사용자를 추가할 때 더 많은 것을 제어할 수 있습니다.
동적 – 동적 역할은 LDAP 필터를 사용하여 만듭니다. 모든 사용자가 필터를 통해 걸러져 역할 작성 시 역할에 할당됩니다. 필터는 항목의 임의 속성 값 쌍(예: ca=user*)을 찾아 해당 속성을 포함하는 사용자를 역할에 자동으로 할당합니다.

정적 역할 만들기

역할을 만들 조직으로 이동합니다.

[역할] 탭을 누릅니다.

기본 역할 세트는 조직이 구성될 때 만들어지며 역할 목록에 표시됩니다. 기본 역할은 다음과 같습니다.

컨테이너 도움말 데스크 관리자.컨테이너 도움말 데스크 관리자 역할은 조직 구성 단위의 모든 항목에 대한 읽기 권한과 이 컨테이너 단위에 한하여 사용자 항목의 userPassword 속성에 대한 쓰기 권한을 가집니다.

조직 도움말 데스크 관리자.조직의 도움말 데스크 관리자는 조직의 모든 항목에 대한 읽기 권한과 userPassword 속성에 대한 쓰기 권한을 가집니다.

주 –
하위 조직을 만들 때 관리 역할이 부모 조직이 아닌 하위 조직에서 만들어진다는 점에 주의하십시오.

컨테이너 관리자.컨테이너 관리자 역할은 LDAP 조직 구성 단위의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. Access Manager에서 LDAP 조직 구성 단위를 흔히 컨테이너라고 부릅니다.

조직 정책 관리자.조직 정책 관리자는 모든 정책에 대한 읽기 및 쓰기 권한을 가지며 해당 조직 내의 모든 정책을 작성, 할당, 수정 및 삭제할 수 있습니다.

사용자 관리자.기본적으로 새로 만든 조직의 모든 사용자 항목은 해당 조직에 속한 구성원입니다. 사용자 관리자는 조직의 모든 사용자 항목에 대한 읽기 및 쓰기 권한을 가집니다. 이 역할은 역할 및 그룹 DN을 포함하는 속성에 대한 읽기 및 쓰기 권한을 갖지 않으므로 역할 또는 그룹의 속성을 수정하거나 역할 또는 그룹에서 사용자를 제거할 수 없다는 점에 주의하십시오.

주 –
Access Manager에서 다른 컨테이너를 구성하여 사용자 항목, 그룹 항목 또는 다른 컨테이너를 포함할 수 있습니다. 조직이 이미 구성된 후에 만든 컨테이너에 관리자 역할을 할당하면 컨테이너 관리자 역할 또는 컨테이너 도움말 데스크 관리자 기본값이 사용됩니다.

그룹 관리자.그룹을 만들 때 생성되는 그룹 관리자는 특정 그룹의 모든 구성원에 대한 읽기 및 쓰기 권한을 가지며, 새 사용자를 만들고 관리하는 그룹에 사용자를 할당하고 만든 사용자를 삭제하는 등의 작업을 수행할 수 있습니다.

그룹이 만들어지면 해당 그룹을 관리하는 데 필요한 권한과 함께 그룹 관리자 역할이 자동으로 생성됩니다. 이 역할은 그룹 구성원에 자동으로 할당되지 않습니다. 따라서 그룹 작성자나 그룹 관리자 역할에 대한 액세스 권한을 가진 누군가가 이 역할을 할당해야 합니다.

최상위 수준 관리자.최상위 수준 관리자는 최상위 수준 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. 즉, 이 최상위 수준 관리자 역할은 Access Manager 응용 프로그램 내의 모든 구성 기본에 대한 권한을 가집니다.

조직 관리자.조직 관리자는 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. 조직이 만들어지면 해당 조직을 관리하는 데 필요한 권한과 함께 조직 관리자 역할이 자동으로 생성됩니다.

[새 정적] 버튼을 누릅니다.

역할의 이름을 입력합니다.

역할에 대한 설명을 입력합니다.

[유형] 메뉴에서 역할 유형을 선택합니다.

역할은 관리 역할 또는 서비스 역할이 될 수 있습니다. 역할 유형은 Access Manager 콘솔에서 사용자를 시작할 위치를 파악하기 위해 사용됩니다. 관리 역할은 역할 소유자가 관리 권한을 갖고 있다는 것을 콘솔에 알리고 서비스 역할은 역할 소유자가 최종 사용자라는 것을 콘솔에 알립니다.

[액세스 권한] 메뉴에서 역할에 적용할 기본 사용 권한 집합을 선택합니다. 이러한 사용 권한은 조직 내의 항목에 대한 액세스를 제공합니다. 기본 사용 권한은 특별한 순서 없이 표시됩니다. 다음과 같은 권한이 있습니다.

사용 권한 없음

역할에 사용 권한이 설정되지 않습니다.

조직 관리자

조직 관리자는 구성된 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다.

조직 도움말 데스크 관리자

조직 도움말 데스크 관리자는 구성된 조직의 모든 항목에 대한 읽기 권한과 userPassword 속성에 대한 쓰기 권한을 가집니다.

조직 정책 관리자

조직 정책 관리자는 조직의 모든 정책에 대한 읽기 및 쓰기 권한을 가집니다. 조직 정책 관리자는 피어 조직에 대한 참조 정책을 만들 수 없습니다.

일반적으로 서비스 역할에는 사용 권한 없음 ACI가 할당되고 관리 역할에는 임의의 기본 ACI가 할당됩니다.

정적 역할에 사용자 추가

사용자를 추가할 역할의 이름을 누릅니다.

[구성원] 목록의 [작업 선택] 메뉴에서 [사용자 추가]를 선택합니다.

검색 조건에 대한 정보를 입력합니다. 하나 이상의 표시된 필드에 기초하여 사용자를 검색할 수 있습니다. 이러한 필드는 다음과 같습니다.

일치

필터에 포함할 필드를 선택할 수 있습니다. ALL은 지정된 모든 필드에 해당하는 사용자를 반환합니다. ANY는 지정된 필드 중 하나 이상에 해당하는 사용자를 반환합니다.

이름

이름을 기준으로 사용자를 검색합니다.

사용자 아이디

사용자 아이디를 기준으로 사용자를 검색합니다.

성

성을 기준으로 사용자를 검색합니다.

전체 이름

성명을 기준으로 사용자를 검색합니다.

사용자 상태

상태(활성 또는 비활성)를 기준으로 사용자를 검색합니다.

[다음]을 눌러 검색을 시작합니다. 검색 결과가 표시됩니다.

아이디 옆에 있는 확인란을 선택하여 반환된 이름에서 사용자를 선택합니다.

[마침]을 누릅니다.

사용자가 이제 역할에 할당됩니다.

동적 역할을 만들려면

역할을 만들 조직으로 이동합니다.

[역할] 탭을 누릅니다.

기본 역할 세트는 조직이 구성될 때 만들어지며 역할 목록에 표시됩니다. 기본 역할은 다음과 같습니다.

컨테이너 도움말 데스크 관리자.컨테이너 도움말 데스크 관리자 역할은 조직 구성 단위의 모든 항목에 대한 읽기 권한과 이 컨테이너 단위에 한하여 사용자 항목의 userPassword 속성에 대한 쓰기 권한을 가집니다.

조직 도움말 데스크 관리자.조직의 도움말 데스크 관리자는 조직의 모든 항목에 대한 읽기 권한과 userPassword 속성에 대한 쓰기 권한을 가집니다.

주 –
하위 조직을 만들 때 관리 역할이 부모 조직이 아닌 하위 조직에서 만들어진다는 점에 주의하십시오.

컨테이너 관리자.컨테이너 관리자 역할은 LDAP 조직 구성 단위의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. Access Manager에서 LDAP 조직 구성 단위를 흔히 컨테이너라고 부릅니다.

조직 정책 관리자.조직 정책 관리자는 모든 정책에 대한 읽기 및 쓰기 권한을 가지며 해당 조직 내의 모든 정책을 작성, 할당, 수정 및 삭제할 수 있습니다.

사용자 관리자.기본적으로 새로 만든 조직의 모든 사용자 항목은 해당 조직에 속한 구성원입니다. 사용자 관리자는 조직의 모든 사용자 항목에 대한 읽기 및 쓰기 권한을 가집니다. 이 역할은 역할 및 그룹 DN을 포함하는 속성에 대한 읽기 및 쓰기 권한을 갖지 않으므로 역할 또는 그룹의 속성을 수정하거나 역할 또는 그룹에서 사용자를 제거할 수 없다는 점에 주의하십시오.

주 –
Access Manager에서 다른 컨테이너를 구성하여 사용자 항목, 그룹 항목 또는 다른 컨테이너를 포함할 수 있습니다. 조직이 이미 구성된 후에 만든 컨테이너에 관리자 역할을 할당하면 컨테이너 관리자 역할 또는 컨테이너 도움말 데스크 관리자 기본값이 사용됩니다.

그룹 관리자.그룹을 만들 때 생성되는 그룹 관리자는 특정 그룹의 모든 구성원에 대한 읽기 및 쓰기 권한을 가지며, 새 사용자를 만들고 관리하는 그룹에 사용자를 할당하고 만든 사용자를 삭제하는 등의 작업을 수행할 수 있습니다.

그룹이 만들어지면 해당 그룹을 관리하는 데 필요한 권한과 함께 그룹 관리자 역할이 자동으로 생성됩니다. 이 역할은 그룹 구성원에 자동으로 할당되지 않습니다. 따라서 그룹 작성자나 그룹 관리자 역할에 대한 액세스 권한을 가진 누군가가 이 역할을 할당해야 합니다.

최상위 수준 관리자.최상위 수준 관리자는 최상위 수준 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. 즉, 이 최상위 수준 관리자 역할은 Access Manager 응용 프로그램 내의 모든 구성 기본에 대한 권한을 가집니다.

조직 관리자.조직 관리자는 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다. 조직이 만들어지면 해당 조직을 관리하는 데 필요한 권한과 함께 조직 관리자 역할이 자동으로 생성됩니다.

[새 동적] 버튼을 누릅니다.

역할의 이름을 입력합니다.

역할에 대한 설명을 입력합니다.

[유형] 메뉴에서 역할 유형을 선택합니다.

역할은 관리 역할 또는 서비스 역할이 될 수 있습니다. 역할 유형은 Access Manager 콘솔에서 사용자를 시작할 위치를 파악하기 위해 사용됩니다. 관리 역할은 역할 소유자가 관리 권한을 갖고 있다는 것을 콘솔에 알리고 서비스 역할은 역할 소유자가 최종 사용자라는 것을 콘솔에 알립니다.

[액세스 권한] 메뉴에서 역할에 적용할 기본 사용 권한 집합을 선택합니다. 이러한 사용 권한은 조직 내의 항목에 대한 액세스를 제공합니다. 기본 사용 권한은 특별한 순서 없이 표시됩니다. 다음과 같은 권한이 있습니다.

사용 권한 없음

역할에 사용 권한이 설정되지 않습니다.

조직 관리자

조직 관리자는 구성된 조직의 모든 항목에 대한 읽기 및 쓰기 권한을 가집니다.

조직 도움말 데스크 관리자

조직 도움말 데스크 관리자는 구성된 조직의 모든 항목에 대한 읽기 권한과 userPassword 속성에 대한 쓰기 권한을 가집니다.

조직 정책 관리자

조직 정책 관리자는 조직의 모든 정책에 대한 읽기 및 쓰기 권한을 가집니다. 조직 정책 관리자는 피어 조직에 대한 참조 정책을 만들 수 없습니다.

일반적으로 서비스 역할에는 사용 권한 없음 ACI가 할당되고 관리 역할에는 임의의 기본 ACI가 할당됩니다.

검색 조건에 대한 정보를 입력합니다. 필드는 다음과 같습니다.

일치

필터에 포함할 임의의 필드에 대한 연산자를 포함할 수 있습니다. ALL은 지정된 모든 필드에 해당하는 사용자를 반환합니다. ANY는 지정된 필드 중 하나 이상에 해당하는 사용자를 반환합니다.

이름

이름을 기준으로 사용자를 검색합니다.

사용자 아이디

사용자 아이디를 기준으로 사용자를 검색합니다.

성

성을 기준으로 사용자를 검색합니다.

전체 이름

성명을 기준으로 사용자를 검색합니다.

사용자 상태

상태(활성 또는 비활성)를 기준으로 사용자를 검색합니다.

[확인]을 눌러 필터 조건에 기초한 검색을 시작합니다. 필터 조건에서 정의한 사용자가 자동으로 역할에 할당됩니다.

역할에서 사용자 제거

수정할 역할을 포함하는 조직으로 이동합니다.

Identity 관리 모듈의 [보기] 메뉴에서 [조직]을 선택하고 [역할] 탭을 선택합니다.

수정할 역할을 선택합니다.

[보기] 메뉴에서 [사용자]를 선택합니다.

제거할 각 사용자 옆에 있는 확인란을 선택합니다.

[작업 선택] 메뉴에서 [사용자 제거]를 누릅니다.

사용자가 이제 역할에서 제거됩니다.

정책에 역할 추가

8장 현재 세션

이 장에서는 Access Manager의 세션 관리 기능에 대해 설명합니다. 세션 관리 모듈은 사용자 세션 정보를 확인하고 사용자 세션을 관리하기 위한 솔루션을 제공합니다. 세션 관리 모듈을 사용하면 다양한 세션 시간을 추적할 수 있으며 관리자가 세션을 종료할 수 있습니다. 시스템 관리자는 플랫폼 서버 목록에 있는 로드 밸런서 서버를 무시해야 합니다.

현재 세션 인터페이스

현재 세션 모듈 인터페이스를 사용하면 적절한 사용 권한이 있는 관리자가 현재 Access Manager에 로그인한 사용자의 세션 정보를 볼 수 있습니다.

세션 관리

세션 관리 프레임은 현재 관리되고 있는 Access Manager의 이름을 표시합니다.

세션 정보

세션 정보 창은 현재 Access Manager에 로그인한 모든 사용자 및 각 사용자의 세션 시간을 표시합니다. 표시 필드는 다음과 같습니다.

사용자 아이디.현재 로그인한 사용자의 사용자 아이디를 표시합니다.

남은 시간.사용자가 다시 인증하기 전에 해당 세션에 대해 남은 시간(분)을 표시합니다.

최대 세션 시간.세션이 만료되고 액세스 권한을 다시 얻기 위해 다시 인증하기 전까지 사용자가 로그인할 수 있는 최대 시간(분)을 표시합니다.

유휴 시간. 사용자가 유휴 상태인 시간(분)을 표시합니다.

최대 유휴 시간.사용자가 다시 인증하기 전까지 유휴 상태로 있을 수 있는 최대 시간(분)을 표시합니다.

시간 제한은 관리자가 세션 관리 서비스에서 정의합니다.

[사용자 아이디] 필드에 문자열을 입력하고 [필터]를 눌러 특정 사용자 세션이나 사용자 세션의 특정 범위를 표시할 수 있습니다. 와일드카드를 사용할 수 있습니다.

[새로 고침] 버튼을 누르면 사용자 세션 표시가 업데이트됩니다.

세션 종료

적절한 사용 권한을 가진 관리자가 언제든지 사용자 세션을 종료할 수 있습니다.

세션을 종료하려면

종료하려는 사용자 세션을 선택합니다.

[종료]를 누릅니다.

9장 비밀번호 재설정 서비스

Access Manager는 사용자가 Access Manager로 보호되는 지정된 서비스 또는 응용 프로그램에 액세스하기 위한 비밀번호를 재설정할 수 있게 해주는 비밀번호 재설정 서비스를 제공합니다. 비밀번호 재설정 서비스 속성은 최상위 관리자가 정의하고, 비밀번호 질문 형태로 사용자 검증 자격 증명을 제어하며 새로운 또는 기존 비밀번호 알림 기법을 제어합니다. 그리고 잘못된 사용자 검증에 대한 가능한 잠금 간격을 설정합니다.

이번 장은 다음 절로 구성됩니다.

비밀번호 재설정 서비스 등록

사용자가 소속된 영역에 대해서는 비밀번호 재설정 서비스를 등록할 필요가 없습니다. 사용자가 위치한 조직에 비밀번호 재설정 서비스가 없는 경우 서비스 구성에서 해당 서비스에 대해 정의된 값을 상속합니다.

다른 영역의 사용자에 대해 비밀번호 재설정을 등록하려면

사용자에 대한 비밀번호를 등록하려는 영역으로 이동합니다.

영역 이름을 누르고 [서비스] 탭을 누릅니다.

서비스가 아직 영역에 추가되지 않은 경우 [추가] 버튼을 누릅니다.

[비밀번호 재설정]을 선택하고 [다음]을 누릅니다.

비밀번호 재설정 서비스 속성이 표시됩니다. 속성 정의는 온라인 도움말을 참조하십시오.

[마침]을 누릅니다.

비밀번호 재설정 서비스 구성

비밀번호 재설정 서비스가 등록되어 있는 경우 관리자 권한이 있는 사용자가 서비스를 구성해야 합니다.

서비스를 구성하려면

비밀번호 재설정 서비스를 등록할 영역을 선택합니다.

[서비스] 탭을 누릅니다.

서비스 목록에서 [비밀번호 재설정]을 누릅니다.

비밀번호 재설정 속성이 표시되고 사용자는 이 속성을 사용하여 비밀번호 재설정 서비스에 대한 요구 사항을 정의할 수 있습니다. 비밀번호 재설정 서비스가 사용 가능(기본값)한지 확인합니다. 최소한 다음 속성을 정의해야 합니다.
- 사용자 검증
  - 비밀 문제
  - 바인드 DN
  - 바인드 비밀번호
    
    바인드 DN 속성은 비밀번호 재설정 권한이 있는 사용자(예: 도움말 데스크 관리자)를 포함해야 합니다. Directory Server의 제한 때문에 바인드 DN이 cn=Directory Manager인 경우에는 비밀번호 재설정이 실행되지 않습니다.
    
    나머지 속성은 선택 사항입니다. 서비스 속성에 대한 설명은 온라인 도움말을 참조하십시오.
  주 –
  Access Manager는 임의의 비밀번호 생성을 위한 비밀번호 재설정 웹 응용 프로그램을 자동으로 설치합니다. 그러나 비밀번호 생성 및 비밀번호 알림을 위한 사용자 플러그 인 클래스를 작성할 수 있습니다. 이러한 플러그 인 클래스에 대해서는 다음 위치에 있는 다음 Readme.html 파일을 참조하십시오.
  
  PasswordGenerator:
  AccessManager-base/SUNWam/samples/console/PasswordGenerator
  NotifyPassword:
  AccessManager-base/SUNWam/samples/console/NotifyPassword

사용자가 고유 개인 문제를 직접 정의해야 하는 경우 개인 문제 사용 가능 속성을 선택합니다. 속성을 정의한 다음 [저장]을 누릅니다.

비밀 문제를 현지화하려면

현지화된 Access Manager 버전을 실행하는 경우 사용자의 로켈에 해당하는 문자 집합으로 비밀 문제를 표시하려면 다음을 수행하십시오.

비밀번호 재설정 서비스에서 [비밀 문제] 속성 아래의 [현재 값] 목록에 비밀 문제 키를 추가합니다. 예를 들면 favorite-color와 같습니다.

amPasswordReset.properties 파일에 키 값을 표시할 문제와 함께 해당 키를 추가합니다. 예를 들면 다음과 같습니다.

favorite-color=가장 좋아하는 색상은?

/opt/SUNWam/locale의 AMPasswordReset_locale.properties 파일에 현지화된 질문과 함께 해당 키를 추가합니다. 사용자가 비밀번호를 변경하려는 경우 현지화된 문제가 표시됩니다.

비밀번호 재설정 잠금

비밀번호 재설정 서비스에는 사용자가 비밀 문제에 올바르게 응답하기 위해 시도할 수 있는 횟수를 제한하는 잠금 기능이 포함됩니다. 잠금 기능은 비밀번호 재설정 서비스 속성을 통해 구성됩니다. 서비스 속성에 대한 설명은 온라인 도움말을 참조하십시오. 비밀번호 재설정은 메모리 잠금과 물리적 잠금이라는 두 가지 유형의 잠금을 지원합니다.

메모리 잠금

이 잠금은 임시 잠금이며 비밀번호 재설정 실패 잠금 기간 속성의 값이 0보다 크고 비밀번호 재설정 실패 잠금 사용 가능 속성이 활성화된 경우에만 유효합니다. 이 잠금은 사용자가 비밀번호 재설정 웹 응용 프로그램을 통해 비밀번호를 재설정하지 못하게 합니다. 잠금은 비밀번호 재설정 실패 잠금 기간에 지정된 기간 동안 지속되거나 서버가 다시 시작될 때까지 지속됩니다. 서비스 속성에 대한 설명은 온라인 도움말을 참조하십시오.

물리적 잠금

보다 영구적인 잠금입니다. 비밀번호 재설정 실패 잠금 횟수 속성 값을 0으로 설정하고 비밀번호 재설정 실패 잠금 사용 가능 속성을 활성화하면 사용자가 비밀번호 질문에 잘못 대답할 경우 해당 사용자의 계정 상태가 비활성 상태로 변경됩니다. 서비스 속성에 대한 설명은 온라인 도움말을 참조하십시오.

최종 사용자에 대한 비밀번호 재설정

다음 절에서는 비밀번호 재설정 서비스에 대한 사용자 경험을 설명합니다.

비밀번호 재설정 사용자 정의

비밀번호 재설정 서비스가 사용 가능하고 관리자가 속성을 정의한 경우 사용자는 Access Manager 콘솔에 로그인하여 비밀 문제를 사용자 정의할 수 있습니다.

비밀번호 재설정을 사용자 정의하려면

사용자가 아이디와 비밀번호를 제공하여 Access Manager 콘솔에 로그인하면 성공적으로 인증됩니다.

사용자 프로필 페이지에서 비밀번호 재설정 옵션을 선택합니다. 사용 가능한 문제 응답 화면이 표시됩니다.

관리자가 해당 서비스에 대해 정의한 사용 가능한 문제가 표시됩니다. 예를 들면 다음과 같습니다.
- 애완동물 이름은?
  - 가장 좋아하는 TV 쇼는?
  - 어머니의 성함은?
  - 자주 가는 식당은?

비밀번호 질문을 선택합니다. 비밀번호 질문은 관리자가 영역에 대해 정의한 최대 문제 수 이하로 선택할 수 있습니다(최대 양은 비밀번호 재설정 서비스를 통해 정의됨). 그런 다음 선택한 문제에 대한 대답을 입력합니다. 이러한 문제와 대답은 사용자의 비밀번호 재설정을 위한 기초가 됩니다(다음 절 참조). 관리자가 개인 문제 사용 가능 속성을 선택한 경우 사용자가 고유한 비밀 문제를 입력하고 대답을 제공할 수 있는 텍스트 필드가 제공됩니다.

[저장]을 누릅니다.

잊어버린 비밀번호 재설정

사용자가 비밀번호를 잊어버린 경우 Access Manager는 비밀번호 재설정 웹 응용 프로그램을 사용하여 새 비밀번호를 임의로 생성하여 사용자에게 새 비밀번호를 알려 줍니다. 다음은 일반적인 잊어버린 비밀번호 시나리오입니다.

잊어버린 비밀번호를 재설정하려면

관리자가 지정해 준 URL에서 비밀번호 재설정 웹 응용 프로그램에 로그인합니다. 예를 들면 다음과 같습니다.

http://hostname:port/ampassword(기본 영역용)

또는

http://hostname: port/deploy_uri /UI/PWResetUserValidation?realm=realmname(여기서 realmname은 영역 이름임)

주 –
비밀번호 재설정 서비스가 상위 영역에 대해서는 사용 가능으로 설정되어 있지 않고 하위 영역에 대해서는 사용 가능으로 설정되어 있는 경우 사용자가 서비스에 액세스하려면 다음 구문을 사용해야 합니다.
http://hostname: port/deploy_uri/UI/PWResetUserValidation?realm=realmname

사용자 아이디를 입력합니다.

비밀번호 재설정 서비스에서 정의하고 사용자 정의 과정에서 사용자가 선택한 개인 문제가 표시됩니다. 사용자 프로필 페이지에 로그인하지 않고 개인 문제를 사용자 정의한 경우 비밀번호가 생성되지 않습니다.

사용자가 문제에 올바르게 대답하면 새 비밀번호를 생성하여 전자 메일로 사용자에게 알려 줍니다. 문제에 올바르게 대답했는지 여부에 관계 없이 사용자에게 시도 알림을 보냅니다. 새 비밀번호와 시도 알림을 받으려면 사용자 프로필 페이지에 전자 메일 주소를 입력해야 합니다.

비밀번호 정책

비밀번호 정책은 지정된 디렉토리에서 비밀번호가 사용되는 방법을 제어하는 일련의 규칙이며, 대개 Directory Server 콘솔을 통해 Directory Server에 정의됩니다. 보안 비밀번호 정책은 다음을 적용하여 비밀번호를 쉽게 추측할 수 있는 위험을 최소화합니다.

일정에 따라 비밀번호를 변경해야 합니다.
쉽게 추정할 수 없는 비밀번호를 지정해야 합니다.
잘못된 비밀번호로 여러 번 바인드하면 계정이 잠길 수 있습니다.

Directory Server에서는 트리의 노드에서 여러 가지 방법으로 비밀번호 정책을 설정할 수 있으며 여러 가지 정책 설정 방법을 제공합니다. 자세한 내용은

Directory Server Enterprise Edition 6.0 관리 설명서의 Directory Server 비밀번호 정책을 참조하십시오.

주 –

Directory Server의 비밀번호 정책에는 지정된 시간(초)이 경과하면 사용자 비밀번호가 만료되는지 여부를 정의하는 passwordExp 속성이 포함됩니다. passwordExp 속성을 on으로 설정하면 Access Manager의 관리 계정(예: amldap, dsame 및 puser)과 함께 최종 사용자의 비밀번호에 대한 만료 여부가 설정됩니다. Access Manager 관리자의 계정 비밀번호가 만료된 경우 최종 사용자가 로그인하면 해당 사용자에게 비밀번호 변경 화면이 표시됩니다. 그러나 Access Manager는 이 비밀번호 변경 화면과 관련된 사용자를 지정하지 않습니다. 이 경우 관리자를 위해 제공되는 화면이므로 최종 사용자는 비밀번호를 변경할 수 없습니다.

이 문제를 해결하려면 관리자가 Directory Server에 로그인하여 amldap, dsame 및 puser 비밀번호를 변경하거나 passwordExpirationTime 속성을 변경해야 합니다.

10장 로깅 서비스

Sun Java™ System Access Manager는 사용자 작업, 트래픽 패턴 및 인증 위반과 같은 정보를 기록하기 위한 로깅 서비스를 제공합니다. 또한 관리자는 디버그 파일을 사용하여 설치 문제를 해결할 수 있습니다.

로그 파일

로그 파일은 모니터링하는 각 서비스에 대한 여러 가지 이벤트를 기록합니다. 관리자는 이 파일을 정기적으로 확인해야 합니다. 로그 파일의 기본 디렉토리는 SPARC 시스템의 경우 /var/opt/SUNWam/logs, Linux 시스템의 경우 /var/opt/sun/identity, HP-UX 시스템의 경우 /var/opt/sun/identity, Windows 시스템의 경우 jes-install-dir\identity입니다. 로그 파일 디렉토리는 Access Manager 콘솔을 사용하여 로깅 서비스에서 구성할 수 있습니다.

기본 로그 파일 유형, 로그에 기록되는 정보 및 로그 파일 형식에 대한 자세한 내용은 Sun Java System Access Manager 7.1 Technical Overview의 Logging Overview를 참조하십시오.

로깅 서비스에 대한 속성 정의는 Access Manager 콘솔에 있는 도움말 버튼을 눌러 온라인 도움말을 참조하십시오.

Access Manager 서비스 로그

서비스 로그 파일에는 액세스 로그 파일과 오류 로그 파일의 두 가지유형이 있습니다. 액세스 로그 파일에는 작업 시도와 성공적인 결과에 대한 기록이 포함됩니다. 오류 로그 파일은 Access Manager 서비스 내에서 발생한 오류를 기록합니다. 플랫 로그 파일에는 .error 또는 .access 확장자가 붙습니다. 데이터베이스 열 이름은 Oracle 데이터베이스의 경우 _ERROR 또는 _ACCESS로 끝나고 MySQL 데이터베이스는 _error 또는 _access로 끝납니다. 예를 들어 콘솔 이벤트를 기록하는 플랫 파일의 이름은 amConsole.access로, 같은 이벤트를 기록하는 데이터베이스 열의 이름은 AMCONSOLE_ACCESS로 지정됩니다. 다음 절에서는 로깅 서비스에서 기록하는 로그 파일에 대해 설명합니다.

세션 로그

로깅 서비스는 세션 서비스에 대해 다음 이벤트를 기록합니다.

로그인
로그아웃
세션 유휴 시간 초과
세션 최대 시간 초과
로그인 실패
세션 재활성화
세션 삭제

세션 로그에는 amSSO 접두어가 붙습니다.

콘솔 로그

Access Manager 콘솔 로그는 조직, 조직 구성 단위, 사용자, 역할, 정책 및 그룹 등을 포함한 Identity 관련 객체, 정책 및 서비스의 생성, 삭제 및 수정을 기록합니다. 또한 비밀번호를 포함한 사용자 속성 수정, 역할 및 그룹에서의 사용자 추가 및 제거를 기록합니다. 이외에도 콘솔 로그는 위임 및 데이터 저장소 작업을 기록합니다. 콘솔 로그에는 amConsole 접두어가 붙습니다.

인증 로그

인증 구성 요소는 사용자 로그인과 로그아웃을 기록합니다. 인증 로그에는 amAuthentication 접두어가 붙습니다.

연합 로그

연합 구성 요소는 인증 도메인 생성 및 호스트 공급자 생성을 포함하나 이에 제한되지 않은 연합 관련 이벤트를 기록합니다. 연합 로그에는 amFederation 접두어가 붙습니다.

정책 로그

정책 구성 요소는 정책 관리(정책 생성, 삭제 및 수정) 및 정책 평가를 포함하나 이에 제한되지 않은 정책 관련 이벤트를 기록합니다. 정책 로그에는 amPolicy 접두어가 붙습니다.

에이전트 로그

정책 에이전트 로그는 사용자에게 허용 또는 거부된 로그 자원에 관한 로깅 예외 기록을 담당합니다. 에이전트 로그에는 amAgent 접두어가 붙습니다. amAgent 로그는 에이전트 서버에만 있습니다. 에이전트 이벤트는 Access Manager 서버에서 인증 로그에 기록됩니다. 이 기능에 대한 자세한 내용은 대상 정책 에이전트에 대한 설명서를 참조하십시오.

SAML 로그

SAML 구성 요소는 명제 및 아티팩트 생성 또는 제거, 응답 및 요청 정보, SOAP 오류를 포함하나 이에 제한되지 않은 SAML 관련 이벤트를 기록합니다. 세션 로그에는 amSAML 접두어가 붙습니다.

amadmin 로그

명령줄 로그는 명령줄 도구를 사용한 작업 중에 발생한 이벤트 오류를 기록합니다. 이러한 이벤트에는 서비스 스키마 로드, 정책 생성 및 사용자 삭제 등이 포함됩니다(이에 제한되지 않음). 명령줄 로그에는 amAdmin 접두어가 붙으며, amadmin.access 및 amadmin.error 로그 파일은 주 로깅 디렉토리의 하위 디렉토리에 있습니다. 기본적으로 amadmin 명령줄 도구 로그 파일은 /var/opt/SUNWam/logs에 있습니다.

로깅 기능

로깅 서비스에는 추가 기능을 사용할 수 있도록 해주는 여러 가지의 특수 기능이 있습니다. 이러한 기능에는 보안 로깅 사용, 명령줄 로깅 및 원격 로깅이 포함됩니다.

보안 로깅

로깅 기능에 추가 보안 수단을 적용합니다(선택 사항). 보안 로깅을 통해 보안 로그의 인증되지 않은 변경이나 손상을 감지할 수 있습니다. 이 기능을 사용하기 위해 특별한 코딩이 필요하지는 않습니다. 보안 로깅은 시스템 관리자가 구성한 미리 등록된 인증서를 사용하여 수행됩니다. 이러한 MAC(Manifest Analysis and Certification)는 모든 로그 레코드에 대해 생성 및 저장됩니다. 특수 '서명' 로그 레코드가 정기적으로 삽입되어 해당 지점에 기록된 로그의 내용에 대한 서명을 나타냅니다. 두 레코드의 조합으로 로그가 손상되지 않았음을 확인할 수 있습니다. 보안 로깅을 활성화하는 방법은 JSS(Java Security Server) 공급자를 사용하는 방법과 JCE(Java Cryptography Extension) 공급자를 사용하는 방법이 있습니다.

JSS 공급자를 통해 보안 로깅을 활성화하려면

이름이 Logger인 인증서를 만들어 Access Manager를 실행 중인 배포 컨테이너에 설치합니다.

Application Server에 대한 자세한 지침은 Sun Java System Application Server Enterprise Edition 8.2 Administration Guide의 Working with Certificates and SSL을 참조하십시오.

Web Server에 대한 자세한 지침은 Sun Java System Web Server 7.0 Administrator’s Guide의 Managing Certificates를 참조하십시오.

Access Manager 콘솔을 사용하여 로깅 서비스 구성에서 보안 로깅을 활성화하고 변경 내용을 저장합니다. 관리자는 로깅 서비스의 다른 속성에 대한 기본값도 수정할 수 있습니다.

로깅 디렉토리가 기본 디렉토리(/var/opt/SUMWam/logs)에서 변경된 경우 권한이 0700으로 설정되었는지 확인하십시오. 로깅 서비스는 디렉토리가 없으면 만들지만 권한이 0755로 설정된 디렉토리를 생성하게 됩니다.

또한 기본값에서 다른 디렉토리를 지정하는 경우 웹 컨테이너의 server.policy 파일에 있는 다음 매개 변수를 새 디렉토리로 변경해야 합니다.

permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

AccessManager-base/SUNWam/config 디렉토리에 인증서 데이터베이스 비밀번호를 포함한 파일을 만들고 이름을 .wtpass로 지정합니다.

주 –
파일 이름 및 이 파일에 대한 경로는 AMConfig.properties 파일에서 구성할 수 있습니다. 자세한 내용은 Access Manager Administration Reference에 있는 AMConfig.properties 파일 참조 장의 "Certificate Database"를 참조하십시오.

보안을 위해 배포 컨테이너 사용자가 이 파일에 대한 읽기 권한을 가진 유일한 관리자임을 확인합니다.

서버를 다시 시작합니다.

보안 로깅 시작 시에 /var/opt/SUNWam/debug/amLog 파일에 잘못된 확인 오류가 기록될 수 있으므로 보안 로그 디렉토리를 지워야 합니다.

보안 로그에 허용되지 않은 변경 또는 손상이 있는지 알아보려면 확인 프로세스에서 /var/opt/SUNWam/debug/amLog에 기록한 오류 메시지를 확인합니다. 손상을 수동으로 확인하려면 VerifyArchive 유틸리티를 실행합니다. 자세한 내용은 Access Manager Administration Reference의 VerifyArchive 명령줄 장을 참조하십시오.

JCE 공급자를 통해 보안 로깅을 활성화하려면

Java keytool 명령으로 Logger라는 인증서를 만들고 JKS 키 저장소에 설치합니다. 예를 들면 다음과 같습니다.

JAVA-HOME/jre/lib/security/Logger.jks

Application Server에 대한 자세한 지침은 Sun Java System Application Server Enterprise Edition 8.2 Administration Guide의 Working with Certificates and SSL을 참조하십시오.

Web Server에 대한 자세한 지침은 Sun Java System Web Server 7.0 Administrator’s Guide의 Managing Certificates를 참조하십시오.

Access Manager 콘솔을 사용하여 로깅 서비스 구성에서 보안 로깅을 활성화하고 변경 내용을 저장합니다. 관리자는 로깅 서비스의 다른 속성에 대한 기본값도 수정할 수 있습니다.

로깅 디렉토리가 기본 디렉토리(/var/opt/SUMWam/logs)에서 변경된 경우 권한이 0700으로 설정되었는지 확인하십시오. 로깅 서비스는 디렉토리가 없으면 만들지만 권한이 0755로 설정된 디렉토리를 생성하게 됩니다.

또한 기본값에서 다른 디렉토리를 지정하는 경우 웹 컨테이너의 server.policy 파일에 있는 다음 매개 변수를 새 디렉토리로 변경해야 합니다.

permission java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”

AccessManager-base/SUNWam/config 디렉토리에 JKS 키 저장소 비밀번호가 포함된 파일을 만들고 이름을 .wtpass로 지정합니다.

주 –
파일 이름 및 이 파일에 대한 경로는 AMConfig.properties 파일에서 구성할 수 있습니다. 자세한 내용은 Access Manager Administration Reference의 AMConfig.properties 파일 참조 장에 있는 "Certificate Database"를 참조하십시오.

보안을 위해 배포 컨테이너 사용자가 이 파일에 대한 읽기 권한을 가진 유일한 관리자임을 확인합니다.

AccessManager-base/config/xml 디렉토리에 있는 amLogging.xml 파일에서 다음 항목을 편집합니다:

sun-am-logging-secure-log-helper

                <AttributeSchema name="iplanet-am-logging-secure-log-helper"
                    type="single"
                    syntax="string"
                    i18nKey="">
                    <DefaultValues>
                        <Value>com.sun.identity.log.secure.impl.SecureLogHelperJCEImpl</Value>
                    </DefaultValues>
                </AttributeSchema>

 sun-am-logging-secure-certificate-store

                <AttributeSchema name="iplanet-am-logging-secure-certificate-store"
                    type="single"
                    syntax="string"
                    i18nKey="">
                    <DefaultValues>
                        <Value>/dir-to-signing-cert-store/Logger.jks</Value>
                    </DefaultValues>
                </AttributeSchema>

기존 서비스 스키마인 iPlanetAMLoggingService를 삭제합니다. 예를 들면 다음과 같습니다.

./amadmin -u amadmin -w netscape -r iPlanetAMLoggingService

amadmin 명령줄 도구를 사용하여 편집된 amLogging.xml 파일을 Access Manager로 로드합니다. 예를 들면 다음과 같습니다.

./amadmin -u amadmin -w netscape -s /etc/opt/SUNWam/config/xml/amLogging.xml

서버를 다시 시작합니다.

보안 로그에 허용되지 않은 변경 또는 손상이 있는지 알아보려면 확인 프로세스에서 /var/opt/SUNWam/debug/amLog에 기록한 오류 메시지를 확인합니다. 손상을 수동으로 확인하려면 VerifyArchive 유틸리티를 실행합니다. 자세한 내용은 Access Manager Administration Reference의 VerifyArchive 명령줄 장을 참조하십시오.

명령줄 로깅

amadmin 명령줄 도구를 사용해 Directory Server에서 Identity 객체(예: 조직, 사용자 및 역할)를 생성, 수정 및 삭제할 수 있습니다. 이 도구는 또한 서비스 템플리트를 로드, 생성 및 등록할 수 있습니다. 로깅 서비스는 -t 옵션을 호출하여 이러한 작업을 기록할 수 있습니다. AMConfig.properties의 com.iplanet.am.logstatus 등록 정보가 활성(ACTIVE) 상태이면 로그 레코드가 생성됩니다. 이 등록 정보는 기본적으로 사용 가능합니다. 명령줄 로그에는 amAdmin 접두어가 붙습니다. 자세한 내용은 Access Manager Administration Reference의 "The amadmin Command Line Tool"을 참조하십시오.

로깅 등록 정보

AMConfig.properties 파일에는 로깅 출력에 영향을 주는 다음과 같은 등록 정보가 있습니다.

com.iplanet.am.logstatus=ACTIVE: 이 등록 정보는 로깅을 활성 또는 비활성화합니다. 기본값은 ACTIVE입니다.
iplanet-am-logging.service.level= level: service는 서비스의 일반 로그 파일 이름입니다. 예를 들어 amSAML.access의 로깅 수준을 지정하려면 iplanet-am-logging.amSAML.access.level 등록 정보를 사용합니다.level은 java.util.logging.Level 값 중 하나이며 로그 파일에 기록되는 세부 정보의 수준을 나타냅니다. 수준은 OFF, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST 및 ALL이 있습니다. 대부분의 서비스는 INFO 이하의 정보 수준으로 로그를 기록합니다.

원격 로깅

Access Manager는 원격 로깅을 지원합니다. 따라서 클라이언트 응용 프로그램이 Access Manager 서버가 설치된 호스트를 사용하여 원격 시스템에 배포된 Access Manager 인스턴스에 로그 레코드를 만들 수 있습니다. 원격 로깅은 다음 중 하나의 시나리오에 의해 시작됩니다.

Access Manager 인스턴스의 이름 지정 서비스에 있는 로깅 URL이 원격 인스턴스를 가리키고 이 둘 사이에 신뢰 관계가 구성되어 있는 경우 원격 Access Manager 인스턴스에 로그가 기록됩니다.
Access Manager SDK가 원격 Access Manager 인스턴스에 대해 설치되어 있고 클라이언트(또는 단순 Java 클래스)가 로깅 API를 사용하는 SDK 서버에서 실행 중이면 원격 Access Manager 시스템에 로그가 기록됩니다.
Access Manager 에이전트가 로깅 API를 사용하는 경우.

웹 컨테이너를 사용하여 원격 로깅을 활성화하려면

Application Server 또는 Web Server의 관리 콘솔에 로그인하고 다음 JVM 옵션을 추가합니다.
- java.util.logging.manager=com.sun.identity.log.LogManager
- java.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties
  
  Application Server 관리 콘솔에 대한 자세한 내용은 Sun Java System Application Server Enterprise Edition 8.2 Administration Guide를 참조하십시오.
  
  Web Server 관리 콘솔에 대한 자세한 내용은 Sun Java System Web Server 7.0 Administrator’s Guide를 참조하십시오.
- 사용 중인 Java™ 2 Platform, Standard Edition이 1.4 이상이면 명령줄에서 다음을 호출하여 수행합니다.
  
  java -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/ AccessManager-base /SUNWam/lib/xercesImpl.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/jaas.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/servlet.jar:/ AccessManager-base /SUNWam/locale:/ AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
  
  -Djava.util.logging.manager=com.sun.identity.log.LogManager
  
  -Djava.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties
- 사용 중인 Java 2 Platform, Standard Edition이 1.4 이전 버전이면 명령줄에서 다음을 호출하여 수행합니다.
  
  java -Xbootclasspath/a:/ AccessManager-base /SUNWam/lib/jdk_logging.jar -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/ AccessManager-base /SUNWam/lib/xercesImpl.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/jaas.jar:/ AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/ AccessManager-base /SUNWam/lib/servlet.jar:/ AccessManager-base /SUNWam/locale:/ AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
  
  -Djava.util.logging.manager=com.sun.identity.log.LogManager
  
  -Djava.util.logging.config.file=/ AccessManager-base /SUNwam/lib/LogConfig.properties

AccessManager-base/SUNWam/lib에 있는 LogConfig.properties에 다음 매개 변수가 구성되어 있는지 확인합니다.
- iplanet-am-logging-remote-handler=com.sun.identity.
  
  log.handlers.RemoteHandler
- iplanet-am-logging-remote-formatter=com.sun.
  
  identity.log.handlers.RemoteFormatter
- iplanet-am-logging-remote-buffer-size=1
  
  원격 로깅은 로그 레코드 수를 기반으로 버퍼링을 지원합니다. 이 값은 레코드의 수에 따라 로그 버퍼 크기를 정의합니다. 버퍼가 꽉 차면 버퍼링된 레코드는 모두 서버로 플러시됩니다.
- iplanet-am-logging-buffer-time-in-seconds=3600
  
  이 값은 로그 버퍼 클리너 스레드를 호출하는 시간 제한 기간을 정의합니다.
- iplanet-am-logging-time-buffering-status=OFF
  
  이 값은 로그 버퍼링 및 버퍼 클리너 스레드의 사용 가능 여부를 정의합니다. 기본적으로 이 기능은 비활성화되어 있습니다.
  
  타이머 기반 버퍼링이 활성화(iplanet-am-logging-time-buffering-status=ON)된 경우 로그 레코드의 수가 iplanet-am-logging-remote-buffer-size에 지정된 값에 도달하거나 타이머가 iplanet-am-logging-buffer-time-in-seconds에 지정된 시간 제한 값이 만료되면 로그 레코드의 버퍼가 로깅 서비스를 제공하는 AM 서버로 플러시됩니다. 버퍼 크기에 도달하기 전에 타이머가 만료되면 버퍼에 들어있는 레코드가 전송됩니다. 원격 로깅의 타이머 기반 버퍼링을 비활성화하면 버퍼 크기에 따라 버퍼를 플러시하는 시기가 결정됩니다. 예를 들어 버퍼 크기가 10이고 응용 프로그램에서 7개 레코드만 보내는 경우 버퍼는 플러시되지 않으며 로그 레코드도 기록되지 않습니다. 응용 프로그램이 종료되면 버퍼의 레코드가 플러시됩니다.
주 –
로그 파일이 비어 있으면 보안 로깅에 "확인 실패" 메시지가 표시될 수 있습니다.이는 생성된 파일의 수가 아카이브 크기와 같기 때문이며, 이 경우 보안 로깅은 이 세트부터 아카이브한 다음 다시 시작합니다. 대부분의 인스턴스에서는 이 오류를 무시해도 됩니다. 레코드 수가 아카이브 크기와 같으면 오류가 표시되지 않습니다.

클라이언트 SDK가 있는 프로그램을 사용하는 경우 AMConfig.properties 파일의 다음 등록 정보를 적절히 설정해야 합니다.
- com.iplanet.am.naming.url
- com.sun.identityagents.app.username
- com.iplanet.am.service.password
- com.iplanet.am.server.protocol
- com.iplanet.am.server.host
- com.iplanet.am.server.port
/opt/SUNWam/war 디렉토리에 있는 클라이언트 SDK 샘플(README.clientsdk)을 참조하십시오. 이 샘플에서는 /opt/SUNWam/war/clientsdk-samples 디렉토리에 대해 AMConfig.properties 및 make 파일을 생성하는 방법에 대해 설명하며,이러한 파일은 샘플의 'makefiles' 컴파일 및 실행 항목에서 사용됩니다.

오류 및 액세스 로그

Access Manager 로그 파일에는액세스 로그 파일 및 오류 로그 파일의 두 가지 유형이 있습니다.

액세스 로그 파일에는 Access Manager 배포와 관련된 일반 감사 정보가 기록됩니다. 로그에는 인증 성공과 같은 이벤트에 대한 단일 레코드가 포함될 수 있습니다. 로그에는 동일한 이벤트에 대해 여러 레코드가 포함될 수 있습니다. 예를 들어 관리자가 콘솔을 사용하여 속성 값을 변경하면 로깅 서비스에서 하나의 레코드에 변경 시도를 기록합니다. 또한 로깅 서비스는 두 번째 레코드에 변경의 실행 결과를 기록합니다.

오류 로그 파일에는 응용 프로그램에서 발생한 오류가 기록됩니다. 작업 오류는 오류 로그에 기록되고, 작업 시도는 액세스 로그 파일에 기록됩니다.

플랫 로그 파일에는 .error 또는 .access 확장자가 붙습니다. 데이터베이스 테이블 이름은 _ERROR 또는 _ACCESS로 끝납니다. 예를 들어 플랫 파일 로깅 콘솔 이벤트의 이름은 amConsole.access이지만 동일한 이벤트를 기록하는 데이터베이스 테이블의 이름은 AMCONSOLE_ACCESS 또는 amConsole_access입니다.

다음 표에는 Access Manager의 각 구성 요소에서 생성되는 로그 파일에 대해 간략히 정리되어 있습니다.

표 10–1 Access Manager 구성 요소 로그


구성 요소	로그 파일 이름 접두어	기록된 정보
세션	`amSSO`	로그인 시간, 로그아웃 시간, 시간 초과 제한과 같은 세션 관리 속성 값.
관리 콘솔	`amConsole`	Identity 관련 객체, 영역, 정책의 생성, 삭제, 수정과 같이 관리 콘솔을 통해 수행된 사용자 작업.
인증	`amAuthentication`	사용자 로그인 및 로그아웃.
아이디 연합	`amFederation`	인증 도메인 생성 및 호스트 공급자 생성 등의 연합 관련 이벤트. 연합 로그에는`amFederation` 접두어가 붙습니다.
인증(정책)	`amPolicy`	정책 생성, 삭제 또는 수정 및 정책 평가와 같은 정책 관련 이벤트.
정책 에이전트	`amAgent`	사용자가 액세스했거나 사용자에 대한 액세스가 거부된 자원 관련 예외. `amAgent` 로그는 정책 에이전트가 설치된 서버에 상주합니다. 에이전트 이벤트는 Access Manager 시스템에서 인증 로그에 기록됩니다.
SAML	`amSAML`	명제, 아티팩트 생성 또는 삭제, 응답 및 요청 세부 정보, SOAP 오류와 같은 SAML 관련 이벤트.
명령줄	`amAdmin`	amadmin 명령줄 도구를 사용한 작업 도중 발생한 이벤트 오류. 플랫 파일 로깅을 지정하면 amAdmin 로그 파일이 주 로깅 디렉토리(기본적으로 `/var/opt/SUNWam/logs`)의 `amadmincli` 하위 디렉토리에 저장됩니다. 예: 서비스 스키마 로딩, 정책 생성 및 사용자 삭제.

Access Manager 로그 파일의 목록과 설명에 대한 자세한 내용은 Access Manager Administration Reference의 Access Manager Log File Reference를 참조하십시오.

디버그 파일

디버그 파일은 로깅 서비스의 기능이 아닙니다. 디버그 파일은 로깅 API와는 독립적인 다른 API를 사용하여 작성됩니다. 디버그 파일은 /var/opt/SUNWam/debug에 저장됩니다. 이 위치는 디버그 정보의 수준과 함께 AccessManager-base/SUNWam/lib/ 디렉토리의 AMConfig.properties 파일에서 구성할 수 있습니다. 디버그 등록 정보에 대한 자세한 내용은 Access Manager Administration Reference의 AMConfig.properties 파일 참조 장을 참조하십시오.

디버그 수준

디버그 파일에 기록할 수 있는 정보의 수준에는 여러 가지가 있습니다. 디버그 수준은 AMConfig.properties에 있는 com.iplanet.services.debug.level 등록 정보를 사용하여 설정합니다.

Off—디버그 정보를 기록하지 않습니다.
Error—이 수준은 프로덕션에 사용됩니다. 프로덕션 중에는 디버그 파일에 오류가 있으면 안됩니다.
Warning—현재 이 수준은 사용하지 않는 것이 좋습니다.
Message—이 수준은 코드 추적을 사용하여 가능한 문제를 경고합니다. 대부분의 Access Manager 모듈은 이 수준을 사용하여 디버그 메시지를 보냅니다.

주 –
Warning 및 Message 수준은 프로덕션에서는 사용하면 안됩니다. 이 두 수준은 많은 디버그 메시지와 함께 심각한 성능 저하를 일으킵니다.

디버그 출력 파일

디버그 파일은 모듈에서 기록해야 생성됩니다. 따라서 기본 error 모드에서는 디버그 파일에 생성되지 않습니다. 기본 로그인 시에 디버그 수준이 message로 설정되어 생성되는 디버그 파일은 다음과 같습니다.

amAuth
amAuthConfig
amAuthContextLocal
amAuthLDAP
amCallback
amClientDetection
amConsole
amFileLookup
amJSS
amLog
amLoginModule
amLoginViewBean
amNaming
amProfile
amSDK
amSSOProvider
amSessionEncodeURL
amThreadManager

가장 자주 사용되는 파일은 amSDK, amProfile 및 인증과 관련된 모든 파일입니다. 캡처된 정보에는 날짜, 시간 및 메시지 유형(Error, Warning, Message)이 포함됩니다.

디버그 파일 사용

디버그 수준은 기본적으로 error로 설정됩니다. 디버그 파일은 관리자가 다음과 같은 작업을 수행하는 경우 유용합니다.

사용자 정의 인증 모듈 작성.
Access Manager SDK를 사용하여 사용자 정의 응용 프로그램 작성. amProfile 및 amSDK 디버그 파일은 이 정보를 캡처합니다.
콘솔 또는 SDK 사용 중에 액세스 권한 문제 해결. amProfile 및 amSDK 디버그 파일은 이 정보도 캡처합니다.
SSL 문제 해결
LDAP 인증 모듈 문제 해결. amAuthLDAP 디버그 파일은 이 정보를 캡처합니다.

디버그 파일은 향후 제공될 수 있는 모든 문제 해결 설명서와 함께 사용되어야 합니다. 예를 들어 SSL이 실패하는 경우, 디버그를 message로 활성화하고 amJSS 디버그 파일을 확인하여 특정 인증서 오류를 찾을 수 있습니다.

11장 알림 서비스

Sun Java System Access Manager 7.1 알림 서비스를 사용하면 세션 알림을 원격 웹 컨테이너로 보낼 수 있습니다. Access Manager 서버 자체에서 원격으로 실행되는 SDK 응용 프로그램에서 이 서비스를 활성화하여 사용해야 합니다. 이 장에서는 알림을 수신하도록 원격 웹 컨테이너를 활성화하는 방법을 설명하며, 다음 내용으로 구성되어 있습니다.

개요

알림 서비스를 사용하면 Access Manager SDK를 원격으로 실행하는 웹 컨테이너로 세션 알림을 보낼 수 있습니다. 알림은 세션, 정책 및 이름 지정 서비스에만 적용됩니다. 또한 원격 응용 프로그램이 웹 컨테이너에서 실행되고 있어야 합니다. 알림의 목적은 다음과 같습니다.

개별 서비스의 클라이언트측 캐시 동기화
클라이언트에 대한 더욱 효율적인 실시간 업데이트(알림이 없는 경우 폴링 사용)
어떤 클라이언트 응용 프로그램도 변경하지 않고 알림 지원

원격 SDK가 웹 컨테이너에 설치되어 있는 경우에만 알림을 수신할 수 있습니다.

알림 서비스 활성화

다음 단계에 따라 세션 알림을 수신하도록 원격 SSO SDK를 구성할 수 있습니다.

세션 알림을 수신하려면

시스템 1에 Access Manager를 설치합니다.

시스템 2에 Sun Java System Web Server를 설치합니다.

같은 시스템에 SUNWamsdk를 Web Server로 설치합니다.

Access Manager SDK를 원격으로 설치하기 위한 지침은 Sun Java Enterprise System 5 설치 설명서를 참조하십시오.

SDK가 설치된 시스템과 관련하여 다음 사항을 확인합니다.

SDK가 설치된 서버에서 /remote_SDK_server/SUNWam/lib 및 /remote_SDK_server/SUNWam/locale 디렉토리에 대한 액세스 권한이 올바르게 설정되었는지 확인합니다.

이들 디렉토리에는 원격 서버의 파일과 jar 파일이 있습니다.

Web Server에 있는 server.policy 파일의 Grant 섹션에 다음 권한이 설정되었는지 확인합니다.

server.policy는 설치된 Web Server의 config 디렉토리에 있습니다. 필요한 경우 다음 권한을 복사하여 붙여넣습니다.

permission java.security.SecurityPermission "putProviderProperty.Mozilla-JSS"

permission java.security.SecurityPermission "insertProvider.Mozilla-JSS";

server.xml에 클래스 경로가 올바르게 설정되었는지 확인합니다.

server.xml 역시 설치된 Web Server의 config 디렉토리에 있습니다. 일반적으로 클래스 경로는 다음과 같습니다.

<JAVA javahome="/export/home/ws61/bin/https/jdk" 
serverclasspath="/export/home/ws61/bin/https/jar/webserv-rt.jar:${java.home}/lib/tools.jar:/export/home/ws61/bin/https/jar/webserv-ext.jar:/export/home/ws61/bin/https/jar/webserv-jstl.jar:/export/home/ws61/
	bin/https/jar/nova.jar"
classpathsuffix="::/IS_CLASSPATH_BEGIN_DELIM:				//usr/share/lib/xalan.jar:				//export/SUNWam/lib/xmlsec.jar:				//usr/share/lib/xercesImpl.jar:				//usr/share/lib/sax.jar:				//usr/share/lib/dom.jar:				//export/SUNWam/lib/dom4j.jar:				//export/SUNWam/lib/jakarta-log4j1.2.6.jar:				//usr/share/lib/jaxm-api.jar:				//usr/share/lib/saaj-api.jar:				//usr/share/lib/jaxrpc-api.jar:				//usr/share/lib/jaxrpc-impl.jar:				//export/SUNWam/lib/jaxm-runtime.jar:				//usr/share/lib/saaj-impl.jar:/export/SUNWam
				//lib:/export/SUNWam/locale:				//usr/share/lib/mps/jss3.jar:				//export/SUNWam/lib/	am_sdk.jar:				//export/SUNWam/lib/am_services.jar:				//export/SUNWam/lib/am_sso_provider.jar:				//export/SUNWam/lib/swec.jar:				//export/SUNWam/lib/acmecrypt.jar:				//export/SUNWam/lib/iaik_ssl.jar:				//usr/share/lib/jaxp-api.jar:				//usr/share/lib/mail.jar:				//usr/share/lib/activation.jar:				//export/SUNWam/lib/servlet.jar:				//export/SUNWam/lib/am_logging.jar:				//usr/share/lib/commons-logging.jar:				//IS_CLASSPATH_END_DELIM:" 
envclasspathignored="true" debug="false"
debugoptions="-Xdebug -Xrunjdwp:transport=dt_socket,
server=y,suspend=n" 
javacoptions="-g" 
dynamicreloadinterval="2">

구성 용도로는 원격 SDK 서버에 설치된 SSO 샘플을 사용합니다.
1. /remote_SDK_server/SUNWam/samples/sso 디렉토리로 변경합니다.
2. gmake를 실행합니다.
3. /remote_SDK_server/SUNWam/samples/sso에서 생성된 클래스 파일을 /remote_SDK_server/SUNWam/lib/로 복사합니다.

Access Manager와 함께 설치된 AMConfig.properties 파일의 am.encryption.pwd 암호화 값을 SDK가 설치된 원격 서버의 AMConfig.properties 파일에 복사합니다.

am.encryption.pwd 값은 비밀번호를 암호화하고 해독하는 데 사용됩니다.

amadmin으로 Access Manager에 로그인합니다.

http://AcceessManager-HostName :3000/amconsole

브라우저 위치 필드에 http://remote_SDK_host:58080/servlet/SSOTokenSampleServlet을 입력하고 SSOToken을 확인하여 서블릿을 실행합니다.

SSOTokenSampleServlet은 세션 토큰을 확인하고 수신기를 추가하는 데 사용됩니다. 서블릿를 실행하면 다음과 같은 메시지가 출력됩니다.

SSOToken host name: 192.18.149.33 SSOToken Principal name: uid=amAdmin,ou=People,dc=red,dc=iplanet,dc=com Authentication type used: LDAP IPAddress of the host: 192.18.149.33 The token id is AQIC5wM2LY4SfcyURnObg7vEgdkb+32T43+RZN30Req/BGE= Property: Company is - Sun Microsystems Property: Country is - USA SSO Token Validation test Succeeded

클라이언트 SDK가 설치된 컴퓨터의 AMConfig.properties에서 com.iplanet.am.notification.url= 등록 정보를 다음과 같이 설정합니다.
com.iplanet.am.notification.url=http://clientSDK_host.domain:port /servlet com.iplanet.services.comm.client.PLLNotificationServlet

Web Server를 다시 시작합니다.

amadmin으로 Access Manager에 로그인합니다.

http://AcceessManager-HostName :3000/amconsole

브라우저 위치 필드에 http://remote_SDK_host:58080/servlet/SSOTokenSampleServlet을 입력하고 SSOToken을 확인하여 서블릿을 다시 실행합니다.

원격 SDK가 실행되고 있는 컴퓨터에서 알림을 수신하는 경우 세션 상태가 변경되면 각각의 수신기가 호출됩니다. 원격 SDK가 웹 컨테이너에 설치되어 있는 경우에만 알림을 수신할 수 있습니다.

포털 전용 설치에서 알림 서비스를 활성화하려면

이 절에서는 기본적으로 폴링 모드에서 실행되는 포털 전용 설치 시 WebLogic 8.1에서 알림을 활성화하는 단계를 설명합니다. 또한 amserver 구성 요소가 포함된 포털 인스턴스에는 이 절차가 필요하지 않습니다. amserver 구성 요소의 경우 알림을 수행하도록 자동으로 구성되기 때문입니다.

WebLogic에 PLLNotificationServlet을 등록합니다.

WebLogic 8.1을 사용하려면 웹 응용 프로그램을 배포해야 합니다. 또한 브라우저에서 액세스하는 경우 다음 메시지가 반환되도록 하려면 서블릿 URL이 유효해야 합니다.
Webtop 2.5 Platform Low Level 알림 서블릿

다음과 같이 등록된 URL을 AMConfig.properties에 입력합니다.

com.iplanet.am.notifaction.url=http:// weblogic_instance-host.domain:port/notification/PLLNotificationServlet

AMConfig.properties에서 폴링을 비활성화합니다. 이렇게 하면 알림이 자동으로 활성화됩니다.

com.iplanet.am.session.client.polling.enable=false

WebLogic을 다시 시작하고 구성을 테스트합니다.

디버그 모드를 message로 설정한 경우 트리거될 때 포털에 도착하는 세션 알림이 표시됩니다. 예를 들어 Access Manager 콘솔에서 사용자가 종료되면 알림 이벤트가 발생합니다.

Previous: 1 액세스 제어