Sun Java System Access Manager 7 2005Q4 관리 설명서

파트 II 액세스 제어

Sun Java System Access Manager^TM 7 2005Q4 관리 설명서의 제2부입니다. Access Control 인터페이스는 인증 및 권한 부여 서비스를 만들고 관리하는 방법을 제공하여 영역 기반 자원을 보호하고 규제합니다. 기업 사용자가 정보를 요청하면 Access Manager는 사용자의 아이디를 확인하고 요청한 특정 자원에 액세스할 수 있는 권한을 부여합니다. 다음과 같은 장으로 구성됩니다.

4장 Access Manager 콘솔

Access Manager 콘솔은 다양한 액세스 수준을 가진 관리자가 이를 사용하여 영역 및 조직을 생성하고 이 영역에서 사용자를 생성 및 삭제하며, 영역의 자원을 보호하고 이에 대한 액세스를 제한하기 위한 적용 정책을 설정할 수 있는 웹 인터페이스입니다. 또한 관리자는 현재 사용자 세션을 확인 및 종료할 수 있으며 사용자의 연합 구성(인증 도메인 및 공급자 생성, 삭제 및 수정)을 관리할 수 있습니다. 반면 관리 권한이 없는 사용자는 개인 정보(이름, 전자 메일 주소, 전화 번호 등)를 관리하고 비밀번호를 변경하며, 그룹에 가입 및 탈퇴하고 자신의 역할을 확인할 수 있습니다. Access Manager에는 다음과 같은 두 개의 기본 보기가 있습니다.

관리 보기

관리 역할이 있는 사용자가 Access Manager에 인증하는 경우 기본 보기는 관리 보기입니다. 이 보기에서 관리자는 Access Manager와 관련된 대부분의 관리 작업을 수행할 수 있습니다. Access Manager는 영역 모드와 레거시 모드, 두 개의 다른 모드로 설치할 수 있습니다. 각 모드에는 고유의 콘솔이 있습니다. 영역 및 레거시 모드에 대한 자세한 내용은 Sun Java System Access Manager 7 2005Q4 Technical Overview를 참조하십시오.

영역 모드 콘솔

영역 모드 콘솔에서 관리자는 영역 기반 액세스 제어, 기본 서비스 구성, 웹 서비스 및 연합을 관리할 수 있습니다. 관리자 로그인 화면에 액세스하려면 브라우저에서 다음 주소 구문을 사용하십시오.

protocol://servername/amserver/UI/Login

protocol은 배포 방법에 따라 http: 또는https입니다.

그림 4–1 영역 모드 관리 보기

레거시 모드 콘솔

레거시 모드 콘솔은 Access Manager 6.3 아키텍처를 기반으로 합니다. 레거시 Access Manager 아키텍처는 Sun Java System Directory Server와 함께 제공되는 LDAP 디렉토리 정보 트리(DIT)를 사용합니다. 레거시 모드에서 사용자 정보 및 액세스 제어 정보는 모두 LDAP 조직에 저장됩니다. 레거시 모드를 선택하는 경우 LDAP 조직은 액세스 제어 영역에 해당합니다. 영역 정보는 LDAP 조직 내에 통합됩니다. 레거시 모드에서는 Access Manager 기반의 identity 관리에 대해 디렉토리 관리 탭을 사용할 수 있습니다.

관리자 로그인 화면에 액세스하려면 브라우저에서 다음 주소 구문을 사용하십시오.

protocol://servername /amserver/console

protocol은 배포 방법에 따라 http: 또는https입니다.

그림 4–2 레거시 모드 관리 보기

레거시 모드 6.3 콘솔

Access Manager 6.3의 일부 기능은 Access Manager 7.0 콘솔에서 사용할 수 없습니다. 이런 이유로 관리자는 7.0 레거시 배포를 통해 6.3 콘솔에 로그인할 수 있습니다. 이 콘솔은 Access Manager가 Sun Java System Portal Server 또는 Sun Java System Directory Server를 중앙 아이디 저장소로 사용해야 하는 기타 Sun Java System 통신 제품 상에 구축된 경우 일반적으로 사용됩니다. Delegated Administration 및 Class of Service와 같은 다른 기능은 이 콘솔을 통해서만 액세스할 수 있습니다.

주 –

6.3과 7.0 레거시 모드 콘솔을 번갈아 사용하지 마십시오.

6.3 콘솔에 액세스하려면 브라우저에서 다음 주소 구문을 사용합니다.

protocol://servername /amconsole

protocol은 배포 방법에 따라 http: 또는https입니다.

그림 4–3 Legacy 6.3 기반 콘솔

사용자 프로필 보기

관리 역할이 할당되지 않은 사용자가 Access Manager에 대해 인증을 수행할 때는 사용자 자신의 사용자 프로필이 기본 보기가 됩니다. 사용자 프로필 보기는 영역 또는 레거시 모드에서 액세스할 수 있습니다. 사용자는 이 보기에 액세스하려면 로그인 페이지에서 자신의 사용자 이름과 비밀번호를 입력해야 합니다.

이 보기에서 사용자는 개인 프로필 특정의 속성 값을 수정할 수 있습니다. 여기에는 이름, 주소, 집, 비밀번호 등이 포함될 수 있지만 이에 제한되지는 않습니다. 사용자 프로필 보기에 표시되는 속성은 확장할 수 있습니다.

그림 4–4 사용자 프로필 보기

5장 영역 관리

액세스 제어 영역은 사용자 또는 사용자의 그룹에 연결할 수 있는 인증 등록 정보 및 권한 부여 정책의 그룹입니다. 영역 데이터는 사용자가 지정한 데이터 저장소 내에 Access Manager가 생성한 소유 정보 트리에 저장됩니다. Access Manager 프레임워크는 Access Manager 정보 트리 내 각 영역에 있는 정책 및 속성을 종합합니다. 기본적으로 Access Manager 7은 사용자 데이터와는 별도로 Access Manager 정보 트리를 특수 분기로 Sun Java Enterprise System Directory Server에 자동으로 삽입합니다. 어떤 LDAPv3 데이터베이스를 사용하는 중이라도 액세스 제어 영역을 사용할 수 있습니다.

영역에 대한 자세한 내용은 Sun Java System Access Manager 7 2005Q4 Technical Overview를 참조하십시오.

영역 탭에서 액세스 제어에 대한 다음과 같은 등록 정보를 구성할 수 있습니다.

영역 만들기 및 관리

이 절에서는 영역을 만들고 관리하는 방법을 설명합니다.

새 영역을 만들려면

단계

액세스 제어 탭 아래에 있는 영역 목록에서 새로 만들기를 선택합니다.

다음과 같은 일반 속성을 정의합니다.

이름

영역 이름을 입력합니다.

부모

생성하는 영역의 위치를 정의합니다. 새 영역이 위치할 부모 영역을 선택합니다.

다음과 같은 영역 속성을 지정합니다.

영역 상태

활성 또는 비활성 상태를 선택합니다. 기본값은 활성입니다. 이 값은 영역의 수명 동안 등록 정보 아이콘을 선택하여 언제든지 변경할 수 있습니다. 비활성을 선택하면 로그인 시 사용자 액세스를 사용할 수 없습니다.

영역/DNS 별칭

영역의 DNS 이름에 대한 별칭 이름을 추가할 수 있습니다. 이 속성은 "실제" 도메인 별칭(임의의 문자열은 허용 안 됨)만 수락합니다.

저장하려면 확인을 누르고 이전 페이지로 돌아가려면 취소를 누릅니다.

일반 등록 정보

일반 등록 정보 페이지에는 영역에 대한 기본 속성이 표시됩니다. 이 등록 정보를 수정하려면 액세스 제어 탭 아래에 있는 영역 이름 목록에서 해당 영역을 누릅니다. 그리고 나서 다음 등록 정보를 편집합니다.

영역 상태: 활성 또는 비활성 상태를 선택합니다. 기본값은 활성입니다. 이 값은 영역의 수명 동안 등록 정보 아이콘을 선택하여 언제든지 변경할 수 있습니다. 비활성을 선택하면 로그인 시 사용자 액세스를 사용할 수 없습니다.
영역/DNS 별칭: 영역의 DNS 이름에 대한 별칭 이름을 추가할 수 있습니다. 이 속성은 "실제" 도메인 별칭(임의의 문자열은 허용 안 됨)만 수락합니다.

등록 정보을 편집한 다음 저장을 누릅니다.

인증

사용자가 다른 인증 모듈을 사용하여 로그인하기 전에 일반 인증 서비스를 영역에 대한 서비스로 등록해야 합니다. 핵심 인증 서비스를 사용하면 Access Manager 7 관리자가 영역의 인증 매개 변수에 대한 기본값을 지정할 수 있습니다. 지정된 인증 모듈에 정의된 대체 값이 없는 경우 이러한 값을 사용할 수 있습니다. 핵심 인증 서비스의 기본값은 amAuth.xml 파일에 정의되며 설치 후에 Directory Server에 저장됩니다.

자세한 내용은 7 장, 인증 관리를 참조하십시오.

서비스

Access Manager에서 서비스는 Access Manager 콘솔에서 함께 관리되는 속성의 그룹입니다. 속성은 직원 이름, 직위 및 전자 메일 주소와 같은 관련 정보입니다. 속성은 일반적으로 메일 응용 프로그램 또는 급여 서비스와 같은 소프트웨어 모듈의 구성 매개 변수로 사용됩니다.

서비스 탭을 사용하여 몇 가지 Access Manager 기본 서비스를 영역에 추가 및 구성할 수 있습니다. 다음과 같은 서비스를 추가할 수 있습니다.

관리
검색 서비스
국제화 설정
비밀번호 재설정
세션
사용자

주 –

Access Manager는 서비스 .xml 파일에서 필요한 속성을 일부 기본값으로 실행합니다. 서비스에서 필요한 속성에 값이 없는 경우 기본값을 추가하고 서비스를 다시 로드해야 합니다.

영역에 서비스를 추가하려면

단계

새 서비스를 추가할 영역 이름을 누릅니다.

서비스 탭을 선택합니다.

서비스 목록에서 추가를 누릅니다.

영역에 추가할 서비스를 선택합니다.

다음을 누르십시오.

영역 속성을 정의하여 서비스를 구성합니다. 서비스 속성에 대한 설명은 온라인 도움말에서 구성 부분을 참조하십시오.

마침을 누릅니다.

서비스의 등록 정보를 편집하려면 서비스 목록에서 이름을 누릅니다.

권한

권한은 영역 내에 존재하는 역할 또는 그룹에 대한 액세스 권한을 지정합니다. 역할 또는 그룹은 Access Manager 아이디 주제 유형의 정책 주제 정의로 사용됩니다. 권한을 할당 또는 수정하려면 편집할 역할 또는 그룹의 이름을 누릅니다. 다음과 같은 권한을 할당할 수 있습니다.

정책 등록 정보 전용의 읽기 및 쓰기 액세스
모든 영역 및 정책 등록 정보에 대한 읽기 및 쓰기 권한
모든 등록 정보 및 서비스에 대한 읽기 전용 액세스

6장 데이터 저장소

데이터 저장소는 사용자 속성 및 사용자 구성 데이터를 저장할 수 있는 데이터베이스입니다.

Access Manager는 아이디 저장소 프레임워크에 연결하는 아이디 저장소 플러그인을 제공합니다. 이 새 모델을 사용하면 기존 사용자 데이터베이스를 변경하지 않고도 Access Manager 사용자 정보를 확인하고 불러올 수 있습니다. Access Manager 프레임워크는 아이디 저장소 플러그인에서 얻은 데이터를 다른 Access Manager 플러그인에서 얻은 데이터와 통합하여 각 사용자의 가상 아이디를 구성합니다. Access Manager는 이제 두 개 이상의 아이디 저장소 간의 인증 및 권한 부여 과정에 이러한 범용 아이디를 사용할 수 있습니다. 가상 사용자 아이디는 사용자 세션이 종료되면 소멸됩니다.

LDAPv3 데이터 저장소

Access Manage가 영역 및 레거시 모드 모두로 설치된 경우 일반 LDAPv3 저장소에 대해 새 데이터 저장소 인스턴스를 만들 수 있습니다. 다음 조건에서 LDAPv3 저장소 유형을 선택해야 합니다.

역할, 서비스 클래스(CoS) 및 이전 버전의 Access Manager와의 호환성이 필요하지 않은 경우
기존 디렉토리를 사용하려는 경우
아이디 저장소에 대해 Sun Java System Directory Server가 아닌 디렉토리 서버를 사용하려는 경우
Access Manager가 아이디 저장소에 쓰지 않게 하려는 경우
플랫 디렉토리 정보 트리(DIT)를 사용하려는 경우

새 LDAPv3 데이터 저장소를 만들려면

다음 절에서는 일반 LDAPv3 데이터 저장소를 연결하는 단계에 대해 설명합니다.

단계

새 데이터 저장소를 만들 영역을 선택합니다.

데이터 저장소 탭을 누릅니다.

데이터 저장소 목록에서 새로 만들기를 누릅니다.

데이터 저장소의 이름을 입력합니다.

LDAPv3 저장소 플러그인을 위한 속성를 정의합니다.

마침을 누릅니다.

LDAPv3 저장소 플러그인 속성

다음과 같은 변수를 사용하여 LDAPv3 저장소 플러그인을 구성할 수 있습니다.

기본 LDAP 서버

연결할 LDAP 서버의 이름을 입력하며hostname.domainname:portnumber 형식이어야 합니다.

두 개 이상의 host:portnumber 항목을 입력한 경우 목록의 첫 번째 호스트로 연결이 시도됩니다. 현재 호스트에 대한 연결 시도가 실패한 경우에만 목록의 다음 항목에 대한 연결을 시도합니다.

LDAP 바인드 DN

현재 사용자가 연결된 LDAP 서버에 대한 인증에 Access Manager가 사용할 DN 이름을 지정합니다. DN 이름이 바인드된 사용자는 LDAPv3 지원 유형 및 작업 속성에서 구성한 올바른 추가, 수정 및 삭제 권한을 가져야 합니다.

LDAP 바인드 비밀번호

현재 사용자가 연결된 LDAP 서버에 대한 인증에 Access Manager가 사용할 DN 비밀번호를 지정합니다.

LDAP 바인드 비밀번호(확인)

비밀번호를 확인합니다.

LDAP 조직 DN

해당 데이터 저장소의 저장소가 매핑될 DN으로 데이터 저장소에서 수행되는 모든 작업의 기본 DN이 됩니다.

LDAP SSL 사용 가능

활성화된 경우 Access Manager는 HTTPS 프로토콜을 사용하여 기본 서버에 연결합니다.

LDAP 연결 풀 최소 크기

연결 풀의 초기 연결 수를 지정합니다. 연결 풀을 사용하면 매번 새로 연결할 필요가 없습니다.

LDAP 연결 풀 최대 크기

허용된 최대 연결 수를 지정합니다.

최대 검색 반환 결과

검색 작업에서 반환된 최대 항목 수를 지정합니다. 해당 제한값에 도달하면 Directory Server는 검색 요청과 일치하는 모든 항목을 반환합니다.

검색 시간 초과

검색 요청에 할당할 최대 시간(초)을 지정합니다. 해당 제한값에 도달하면 Directory Server는 검색 요청과 일치하는 모든 항목을 반환합니다.

LDAP에서 참조를 따름

이 옵션이 활성화되면 다른 LDAP 서버로의 참조를 자동으로 따라갑니다.

LDAPv3 저장소 플러그인 클래스 이름

LDAPv3 저장소를 구현할 클래스 파일의 위치를 지정합니다.

속성 이름 매핑

프레임워크에 알려진 공통 속성을 기본 데이터 저장소에 매핑할 수 있도록 합니다. 예를 들어 프레임워크에서 사용자 상태를 결정하는 데 inetUserStatus를 사용한다면 기본 데이터 저장소에서는 userStatus를 사용할 수 있습니다. 속성 정의는 대소문자를 구분합니다.

LDAPv3 플러그인 지원 유형 및 작업

해당 LDAP 서버상에서 허용되거나 수행할 수 있는 작업을 지정합니다. 해당 LDAPv3 저장소 플러그인이 지원하는 작업만 기본 작업입니다. LDAPv3 저장소 플러그인이 지원하는 작업은 다음과 같습니다.

그룹 — 읽기, 만들기, 편집, 삭제
영역 — 읽기, 만들기, 편집, 삭제, 서비스
사용자 — 읽기, 만들기, 편집, 삭제, 서비스
에이전트 — 읽기, 만들기, 편집, 삭제

LDAP 서버 설정 및 작업에 따라 권한을 제거하는 것은 가능하지만

권한을 추가할 수는 없습니다.

LDAP 사용자 검색 속성

이 필드는 사용자에 대해 검색을 수행하는 속성 유형을 정의합니다. 예를 들어 사용자 DN이 uid=k user5,ou=people,dc=iplanet,dc=com인 경우 이름 지정 속성은 uid입니다. (uid=*)는 사용자에 대한 검색 필터에 추가됩니다.

LDAP 사용자 검색 필터

사용자 항목을 찾는 데 사용되는 검색 필터를 지정합니다. 예를 들어 LDAP 사용자 검색 속성은 uid이고 LDAP 사용자 검색 필터는 (objectClass=inetorgperson)인 경우 실제 사용자 검색 필터는 다음과 같습니다. (&(uid=*)(objectClass=inetorgperson)).

LDAP 사용자 객체 클래스

사용자를 위한 객체 클래스를 지정합니다. 사용자가 생성되면 사용자 객체 클래스의 해당 목록이 사용자의 속성 목록에 추가됩니다.

LDAP 사용자 속성

사용자와 연결된 속성의 목록을 정의합니다. 해당 목록에 없는 사용자 속성에 대한 읽기/쓰기 시도는 허용되지 않습니다. 속성은 대소문자를 구분합니다. 객체 클래스 및 속성 스키마는 사용자가 객체 클래스 및 속성 스키마를 지정하기 전에 Directory Server에서 정의되어야 합니다.

LDAP 그룹 검색 속성

이 필드는 그룹에서 검색을 수행하는 속성 유형을 정의합니다. 예를 들어 그룹 DN이 cn=group1,ou=groups,dc=iplanet,dc=com인 경우 그룹에 대한 이름 지정 속성은 cn이고 (cn=*)이 그룹 검색 필터에 추가됩니다.

LDAP 그룹 검색 필터

그룹 항목을 찾는 데 사용되는 검색 필터를 지정합니다. 예를 들어 "LDAP 그룹 검색 속성"은 cn이고 "LDAP 그룹 검색 필터"는 (objectclass=groupOfUniqueNames)인 경우 실제 그룹 검색 필터는 (&(cn=*)(objectclass=groupOfUniqueNames))입니다.

LDAP 그룹 컨테이너 이름 지정 속성

그룹이 컨테이너에 있는 경우 그룹 컨테이너를 위한 이름 지정 속성을 지정합니다. 그렇지 않으면 이 속성은 비어 있습니다. 예를 들어 cn=group1,ou=groups,dc=iplanet,dc=com의 그룹 DN이 ou=groups에 상주하는 경우 그룹 컨테이너 이름 지정 속성은 ou입니다.

LDAP 그룹 컨테이너 값

그룹 컨테이너 값을 지정합니다. 예를 들어 cn=group1,ou=groups,dc=iplanet,dc=com의 그룹 DN이 ou=groups에 상주하는 경우 그룹 컨테이너 값은 groups입니다.

LDAP 그룹 객체 클래스

그룹에 대한 객체 클래스를 지정합니다. 그룹이 생성되면 그룹 객체 클래스의 해당 목록이 그룹의 속성 목록에 추가됩니다.

LDAP 그룹 속성

그룹과 연결된 속성의 목록을 정의합니다. 목록에 없는 그룹 속성에 대한 읽기/쓰기 시도는 허용되지 않습니다. 속성은 대소문자를 구분합니다. 객체 클래스 및 속성 스키마는 사용자가 객체 클래스 및 속성 스키마를 지정하기 전에 Directory Server에서 정의되어야 합니다.

그룹 구성원에 대한 속성 이름

DN이 속한 모든 그룹 이름을 값으로 가지는 속성의 이름을 지정합니다. 기본값은 memberOf입니다.

그룹 구성원의 속성 이름

해당 그룹에 속한 DN을 값으로 가지는 속성의 이름을 지정합니다. 기본값은 uniqueMember입니다.

그룹 구성원 URL의 속성 이름

해당 그룹에 속한 구성원을 확인하는 LDAP URL을 값으로 가지는 속성의 이름을 지정합니다. 기본값은 memberUrl입니다.

LDAP 사용자 컨테이너 이름 지정 속성

사용자가 사용자 컨테이너에 있는 경우 사용자 컨테이너의 이름 지정 속성을 지정합니다. 사용자가 사용자 컨테이너에 없으면 이 필드는 비어 있습니다. 예를 들어 사용자 DN에 uid=kuser5,ou=people,dc=iplanet,dc=com이 지정되어 있고 ou=people이 사용자 컨테이너의 이름인 경우 이름 지정 속성은 ou입니다.

LDAP 사용자 컨테이너 값

사용자 컨테이너의 값을 지정합니다. 기본값은 people입니다. 예를 들어 사용자 DN에 uid=kuser5,ou=people,dc=iplanet,dc=com이 지정되어 있고 ou=people이 사용자 컨테이너의 이름인 경우 이름 지정 속성은 ou이고 people은 "LDAP 사용자 컨데이터 값"입니다.

LDAP 에이전트 검색 속성

이 필드는 에이전트에서 검색을 수행하는 속성 유형을 정의합니다. 기본값은 uid입니다. 예를 들어 에이전트 DN이 uid=kagent1,ou=agents,dc=iplanet,dc=com인 경우 에이전트의 이름 지정 속성은 uid입니다. (uid=*)는 에이전트에 대한 검색 필터에 추가됩니다.

LDAP 에이전트 컨테이너 이름 지정 변수

에이전트가 에이전트 컨테이너에 있는 경우 에이전트 컨테이너의 이름 지정 변수입니다. 에이전트가 에이전트 컨테이너에 없으면 이 필드는 비어 있습니다. 예를 들어 사용자 DN에 uid=kagent1,ou=agents,dc=iplanet,dc=com이 지정된 경우 에이전트 이름 지정 속성은 ou입니다.

LDAP 에이전트 컨테이너 값

에이전트 컨테이너 값을 지정합니다. 에이전트가 에이전트 컨테이너에 없으면 이 필드는 비어 있습니다. 앞에서 설명한 예에서 에이전트 컨테이너 값은 agents입니다.

LDAP 에이전트 검색 필터

에이전트 검색에 사용되는 필터를 정의합니다. 이 필드에 LDAP 에이전트 검색 변수를 추가하여 실제 에이전트 검색 필터를 만듭니다.

예를 들어 LDAP 에이전트 검색 속성은 uid이고 LDAP 사용자 검색 필터는 (objectClass=sunIdentityServerDevice)인 경우 실제 사용자 검색 필터는 (&(uid=*)(objectClass=sunIdentityServerDevice))입니다.

LDAP 에이전트 객체 클래스

에이전트에 대한 객체 클래스를 지정합니다. 에이전트가 생성되면 사용자 객체 클래스가 에이전트의 속성 목록에 추가됩니다.

LDAP 에이전트 속성

에이전트와 연결된 속성의 목록을 정의합니다. 목록에 없는 에이전트 속성에 대한 읽기/쓰기 시도는 허용되지 않습니다. 속성은 대소문자를 구분합니다. 객체 클래스 및 속성 스키마는 사용자가 객체 클래스 및 속성 스키마를 지정하기 전에 Directory Server에서 정의되어야 합니다.

지속적 검색 기본 DN

지속적 검색에 사용할 기본 DN을 지정합니다. 일부 LDAPv3 서버는 루트 접미사 수준의 지속적 검색만 지원합니다.

재시작 전 지속적 검색 최대 유휴 시간

지속성 검색을 다시 시작하기 전 최대 유휴 시간을 지정합니다. 1보다 큰 값을 사용해야 합니다. 값이 1 이하인 경우 연결 유휴 시간에 관계 없이 검색을 다시 시작합니다.

Access Manager가 로드 밸런서와 함께 배포된 경우 지정된 시간 동안 유휴 상태이면 일부 로드 밸런서에서 시간 초과가 일어납니다. 이 경우 재시작 전 지속성 검색 최대 유휴 시간을 로드 밸런서에 지정한 값보다 작은 값으로 설정해야 합니다.

오류 코드 후 최대 재시도 횟수

재시도 대상 LDAPException 오류 코드에서 지정된 오류 코드가 발생하는 경우 지속적 검색 작업에 대한 최대 재시도 횟수를 지정합니다.

재시도 간 지연 시간

각 재시도 전 대기 시간을 지정합니다. 지속적 검색 연결에만 적용됩니다.

재시도 대상의 LDAPException 오류 코드

지속적 검색 작업을 재시도할 오류 코드를 지정합니다. 이 속성은 지속적 검색에만 적용되며 모든 LDAP 작업에는 적용되지 않습니다.

AMSDK 저장소 플러그인

AMSDK 아이디 저장소는 Access Manager가 레거시 모드로 설치된 경우 Access Manager 정보 트리와 자동으로 통합됩니다. 영역 모드에서는 AMSDK 저장소를 설치하도록 선택할 수 있지만 아이디 저장소는 Access Manager 정보 트리와 통합되지 않습니다. 다음 조건에서 AMSDK 저장소 유형을 선택해야 합니다.

역할 및 CoS와 같은 Sun Java System Directory Server 고유 기능을 활용하려는 경우
이전 버전의 Access Manager와의 호환성을 확보하려는 경우

새 AMSDK 저장소 플러그인을 만들려면

단계

Access Manager 저장소 플러그인을 구성할 영역을 선택합니다.

데이터 저장소 탭을 누릅니다.

데이터 저장소 목록에서 새로 만들기를 누릅니다.

저장소 플러그인 이름을 입력합니다.

Access Manager 저장소 플러그인을 선택합니다.

다음을 누르십시오.

다음 필드를 정의합니다.

Access Manager 플러그인 클래스 이름

Access Manager 저장소 플러그인을 구현할 클래스 파일의 위치를 지정합니다.

Access Manager 조직

Access Manager가 관리할 Directory Server 내의 조직을 가리키는 DN으로 데이터 저장소에서 수행되는 모든 작업의 기본 DN이 됩니다.

마침을 누릅니다.

7장 인증 관리

인증 서비스는 Access Manager 배포 시 설치되는 모든 기본 인증 유형에 사용할 웹 기반 사용자 인터페이스를 제공합니다. 이 인터페이스는 액세스를 요청한 사용자에게 호출된 인증 모듈에 따라 로그인 요구 사항 화면을 표시함으로써 인증 자격 증명을 수집하는 동적/사용자 정의 가능 수단을 제공합니다. 이러한 인터페이스는 Sun Java System™ Application Framework(JATO라고도 함)를 사용하여 구축되는데, 이는 개발자들이 기능적 웹 응용 프로그램 구축 시 사용하는 J2EE(Java 2 Enterprise Edition) 표현 프레임워크입니다.

인증 구성

이 절에서는 배포를 위한 인증을 구성하는 방법에 대해 설명합니다. 첫 번째 절에서는 기본 인증 모듈에 대해 간략히 설명하고 필요한 구성 전 지침을 제공합니다. 영역, 사용자, 역할 등에 대해 같은 인증 모듈 유형의 여러 구성 인스턴스를 구성할 수 있습니다. 또한 인증 체인을 추가해서 성공적인 인증을 위해 인증이 여러 인스턴스의 기준을 통과하도록 할 수 있습니다. 이 절에는 다음 내용이 포함되어 있습니다.

인증 모듈 유형

인증 모듈은 사용자 아이디와 비밀번호와 같은 사용자 정보를 수집하고 이 정보를 데이터베이스의 항목과 비교하여 확인하는 플러그인입니다. 사용자가 인증 기준을 충족하는 정보를 제공하면 사용자에게 요청한 자원에 대한 액세스 권한이 허용됩니다. 사용자가 인증 기준을 충족하지 않는 정보를 제공하면 요청한 자원에 대한 액세스가 거부됩니다. Access Manager는 다음 15가지 유형의 인증 모듈과 함께 설치됩니다.

주 –

일부 인증 모듈의 경우 인증 인스턴스로 사용할 수 있으려면 사전 구성이 필요합니다. 필요한 경우 구성 단계가 모듈 유형 설명에 나열됩니다.

핵심

Access Manager는 기본적으로 핵심 인증 모듈과 15개의 다른 인증 모듈을 제공합니다. 핵심 인증 모듈은 인증 모듈에 대한 전체 구성을 제공합니다. 활성 디렉토리, 익명, 인증서 기반, HTTP 기본, JDBC, LDAP 및 인증 모듈을 추가하고 활성화하기 전에 먼저 핵심 인증을 추가하고 활성화해야 합니다. 핵심 및 LDAP 인증 모듈은 모두 기본 영역에 대해 자동으로 활성화됩니다.

고급 등록 정보 버튼을 누르면 영역에 대해 정의할 수 있는 핵심 인증 속성이 표시됩니다. 전역 속성은 영역에 적용되지 않으므로 표시되지 않습니다.

활성 디렉토리

활성 디렉토리 인증 모듈은 LDAP 모듈과 비슷한 방법으로 인증을 수행하지만 LDAP 인증 모듈의 Directory Server와 반대되는 Microsoft의 Active Directory™ 서버를 사용합니다. 활성 디렉토리 서버에 대해 LDAP 인증 모듈을 구성할 수는 있지만 이 모듈을 사용하면 LDAP 및 활성 디렉토리 인증이 모두 같은 영역 아래에 있게 됩니다.

주 –

이 릴리스의 경우 활성 디렉토리 인증 모듈만 사용자 인증을 지원합니다. 비밀번호 정책은 LDAP 인증 모듈에서만 지원됩니다.

익명

기본적으로 이 모듈이 활성화되면 사용자는 Access Manager에 익명 사용자로 로그인할 수 있습니다. 또한 유효한 익명 사용자 목록 속성을 구성하여 이 모듈에 대한 익명 사용자 목록을 정의할 수 있습니다. 익명 액세스를 허용한다는 것은 비밀번호를 입력하지 않고 액세스할 수 있다는 의미입니다. 특정 액세스 유형(예: 읽기 액세스, 검색 액세스) 또는 디렉토리 내의 개별 항목이나 특정 하위 트리로 익명 액세스를 제한할 수 있습니다.

인증서

인증서 기반 인증에는 PDC(Personal Digital Certificate)를 사용한 사용자 식별 및 인증이 포함됩니다. Directory Server에 저장된 PDC에 대한 일치 및 인증서 해지 목록에 대한 확인을 수행하도록 PDC를 구성할 수 있습니다.

인증서 기반 인증 모듈을 영역에 추가하기 전에 여러가지 작업을 수행해야 합니다. 먼저, Access Manager와 함께 설치되는 웹 컨테이너를 보호하고 인증서 기반 인증에 맞게 구성해야 합니다. 인증서 기반 모듈을 활성화하기 전에 Sun ONE Web Server 6.1 관리자 설명서 6장 "인증서 및 키 사용"에서 이러한 초기 웹 서버 구성 단계를 참조하십시오. 이 문서는 다음 위치에서 확인할 수 있습니다.

http://docs.sun.com/db/prod/s1websrv#hic

또는 다음 위치에서 Sun ONE Application Sever 관리자 보안 설명서를 참조하십시오.

http://docs.sun.com/db/prod/s1appsrv#hic

주 –

인증서 기반 모듈을 사용하여 인증할 각 사용자는 사용자의 브라우저에 대한 PDC를 요청해야 합니다. 지침은 사용되는 브라우저에 따라 다릅니다. 자세한 내용은 해당 브라우저의 설명서를 참조하십시오.

이 모듈을 추가하려면 Access Manager에 영역 관리자로 로그인해야 하며 Access Manager와 웹 컨테이너에서 SSL을 구성하고 클라이언트 인증을 활성화해야 합니다. 자세한 내용은 3 장, SSL 모드에서 Access Manager 구성을 참조하십시오.

HTTP 기본

이 모듈은 HTTP 프로토콜에서 지원하는 기본 제공 인증인 기본 인증을 사용합니다. 웹 서버는 아이디 및 비밀번호에 대한 클라이언트 요청을 발급하고, 해당 정보를 인증된 요청에 포함하여 서버로 다시 보냅니다. Access Manager는 사용자 아이디와 비밀번호를 수신한 다음 LDAP 인증 모듈에 대해 사용자를 내부적으로 인증합니다. HTTP 기본이 제대로 작동하게 하려면 LDAP 인증 모듈을 추가해야 합니다(HTTP 기본 모듈만 추가하면 작동되지 않음). 성공적으로 인증한 사용자는 사용자 아이디와 비밀번호를 묻는 메시지를 표시하지 않고 다시 인증할 수 있습니다.

JDBC

JDBC(Java Database Connectivity) 인증 모듈은 Access Manager가 JDBC 기술 사용 드라이버를 제공하는 SQL 데이터베이스를 통해 사용자를 인증하는 기법을 지원합니다. SQL 데이터베이스에 대한 연결은 JDBC 드라이버나 JNDI 연결 풀을 통해 수행될 수 있습니다.

주 –

이 모듈은 MySQL4.0 및 Oracle 8i에서 테스트되었습니다.

LDAP

LDAP 인증 모듈에서는 사용자가 로그인할 때 특정 사용자 DN 및 비밀번호를 사용하여 LDAP Directory Server에 바인드해야 합니다. 이는 모든 영역 기반 인증에 대한 기본 인증 모듈입니다. 사용자는 Directory Server에 있는 사용자 아이디와 비밀번호를 입력하여 유효한 Access Manager 세션에 액세스할 수 있으며 해당 세션을 사용하여 사용자를 설정할 수 있습니다. 기본 영역에서는 핵심 및 LDAP 인증 모듈을 모두 자동으로 사용할 수 있게 됩니다.

구성원

구성원 인증은 my.site.com, mysun.sun.com 등과 같은 사용자 설정 사이트와 비슷하게 구현됩니다. 이 모듈이 사용 가능한 경우 사용자는 관리자의 도움 없이 계정을 만들어 사용자 설정할 수 있습니다. 사용자는 이 새 계정에 추가된 사용자로 액세스할 수 있습니다. 또한 사용자 프로필 데이터베이스에 인증 데이터 및 사용자 기본 설정으로 저장된 뷰어 인터페이스에 액세스할 수 있습니다.

MSISDN

MSISDN(Mobile Station Integrated Services Digital Network) 인증 모듈을 사용하면 휴대 전화와 같은 장치의 이동 가입자 ISDN을 사용하여 인증할 수 있습니다. 이 모듈은 비대화식 모듈입니다. 가입자 ISDN을 검색하고 이를 Directory Server에서 검증하여 번호에 맞는 사용자를 찾습니다.

RADIUS

Access Manager를 구성하여 이미 설치된 RADIUS 서버에서 작업할 수 있습니다. 이렇게 하면 회사에서 레거시 RADIUS 서버를 사용하여 인증하는 경우에 유용합니다. RADIUS 인증 모듈을 활성화하려면 두 단계 프로세스를 거쳐야 합니다.

RADIUS 서버를 구성합니다.

자세한 내용은 RADIUS 서버 설명서를 참조하십시오.
RADIUS 인증 모듈을 등록하여 사용 가능하게 합니다.

Sun Java System Application Server에서 RADIUS 구성

RADUIS 클라이언트가 서버에 대한 소켓 연결을 형성할 경우 기본적으로 SocketPermissions 연결 권한만 Application Server의 server.policy 파일에 허용됩니다. RADUIS 인증이 제대로 작동하게 하려면 다음 작업에 대한 권한을 허용해야 합니다.

적용
연결
수신
결정

소켓 연결 권한을 부여하려면 Application Server의 server.policy 파일에 항목을 추가해야 합니다. SocketPermission은 호스트 사양과 해당 호스트에 연결하는 방법을 지정하는 작업 집합으로 구성됩니다. 호스트를 지정하는 구문은 다음과 같습니다.

host = hostname | IPaddress:portrange:portrange = portnumber 

| -portnumberportnumber-portnumber

호스트는 DNS 이름, 숫자 IP 주소 또는 로컬 호스트(로컬 시스템의 경우)로 표현됩니다. 와일드카드 “*”는 DNS 이름 호스트 규격에 한 번 포함될 수 있습니다. 와일드카드가 포함되는 경우 가장 왼쪽 위치(예: *.example.com)에 와일드카드가 있어야 합니다.

포트(또는 포트 범위)는 선택 사항입니다. 형식이 N-인 포트 사양은 번호가 N 이상인 모든 포트를 나타냅니다. 여기서 N은 포트 번호입니다. 형식이 -N인 사양은 번호가 N 이하인 모든 포트를 나타냅니다.

listen 작업은 로컬 호스트에서 사용될 때만 적용됩니다. 결정(호스트/IP 이름 서비스 조회 결정) 작업은 다른 작업이 있을 때 적용됩니다.

예를 들어, SocketPermissions을 만들 때 일부 코드에 다음 권한이 허용되는 경우 해당 코드를 machine1.example.com의 port 1645에 연결하고 해당 포트에서 연결을 적용할 수 있습니다.

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

마찬가지로 일부 코드에 다음 권한이 허용되는 경우 해당 코드를 사용하여 로컬 호스트의 1024에서 65535 사이의 포트에서 연결을 적용, 연결 또는 수신할 수 있습니다.

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

주 –

원격 호스트에 연결을 적용하거나 연결하도록 코드 권한을 허용하면 유해 코드로 해당 데이터에 대한 액세스 권한이 없는 당사자 간에 기밀 데이터를 쉽게 전송 및 공유할 수 있기 때문에 문제가 발생할 수 있습니다. 포트 번호의 범위 대신 정확한 포트 번호를 지정하여 해당 사용 권한만 부여해야 합니다.

SafeWord

Access Manager를 구성하여 Secure Computing의 SafeWord™ 또는 SafeWord PremierAccess™ 인증 서버에 대한 SafeWord 인증 요청을 처리할 수 있습니다. Access Manager는 SafeWord 인증의 클라이언트 부분을 제공합니다. SafeWord 서버는 Access Manager가 설치되는 시스템이나 별도의 시스템에 위치할 수 있습니다.

Sun Java System Application Server에서 SafeWord 구성

SafeWord 클라이언트에서 이 서버에 소켓 연결을 수행할 경우 기본적으로 Application Server’의 server.policy 파일에 SocketPermissions 연결 권한만 허용됩니다. SafeWord 인증이 제대로 작동하게 하려면 다음 작업에 대한 권한을 허용해야 합니다.

적용
연결
수신
결정

host = (hostname | IPaddress)[:portrange] portrange = 

portnumber | -portnumberportnumber-[portnumber]

host는 DNS 이름, 숫자 IP 주소 또는 로컬 호스트(로컬 시스템의 경우)로 표현됩니다. 와일드카드 “*”는 DNS 이름 호스트 규격에 한 번 포함될 수 있습니다. 와일드카드가 포함되는 경우 가장 왼쪽 위치(예: *.example.com)에 와일드카드가 있어야 합니다.

port(또는 portrange)는 선택 사항입니다. 형식이 N-인 포트 사양은 번호가 N 이상인 모든 포트를 나타냅니다. 여기서 N은 포트 번호입니다. 형식이 -N인 사양은 번호가 N 이하인 모든 포트를 나타냅니다.

listen 작업은 로컬 호스트에서 사용될 때만 적용됩니다. 결정(호스트/IP 이름 서비스 조회 결정) 작업은 다른 작업이 있을 때 적용됩니다.

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

주 –

SAML

SAML(Security Assertion Markup Language) 인증 모듈은 대상 서버에서 SAML 명제를 받아 검증합니다. SAML SSO는 업그레이드(예: Access Manager 2005Q1을 Access Manager 2005Q4로 업그레이드)한 경우를 포함하여 대상 시스템에 이 모듈을 구성한 경우에만 작동합니다.

SecurID

Access Manager를 구성하여 RSA의 ACE/Server 인증 서버에 대한 SecurID 인증 요청을 처리할 수 있습니다. Access Manager는 SecurID 인증의 클라이언트 부분을 제공합니다. ACE/Server는 Access Manager가 설치되는 시스템이나 별도의 시스템에 위치할 수 있습니다. 로컬로 관리되는 사용자 아이디(admintool(1M) 참조)를 인증하려면 루트로 액세스해야 합니다.

SecurID 인증에서는 인증 도우미 amsecuridd가 사용됩니다. 이 프로세스는 메인 Access Manager 프로세스와 별도의 프로세스입니다. 시작 시에 이 도우미는 하나의 포트에서 구성 정보를 수신합니다. Access Manager를 설치하여 nobody 또는 루트가 아닌 사용자 아이디로 실행할 경우에도 AccessManager-base/SUNWam/share/bin/amsecuridd 프로세스는 여전히 루트로 실행되어야 합니다. amsecuridd 도우미에 대한 자세한 내용은 20 장, amsecuridd 도우미을 참조하십시오.

주 –

이 릴리스의 Access Manager에서는 Linux 또는 Solaris x86 플랫폼에 대해 SecurID 인증 모듈을 사용할 수 없으며, 이 두 플랫폼에서 등록, 구성 및 사용해서는 안됩니다. SPARC 시스템용으로만 사용할 수 있습니다.

UNIX

Access Manager를 구성하여 Access Manager가 설치된 Solaris 또는 Linux 시스템에 알려진 Unix 사용자 아이디와 비밀번호에 대한 인증 요청을 처리할 수 있습니다. 영역 속성은 하나만 있지만 Unix 인증을 위한 전역 속성이 여러 개인 경우 몇 가지 시스템 고려 사항이 있습니다. 로컬로 관리되는 사용자 아이디(admintool(1M) 참조)를 인증하려면 루트로 액세스해야 합니다.

Unix 인증에서는 인증 도우미 amunixd가 사용됩니다. 이 프로세스는 메인 Access Manager 프로세스와 별도의 프로세스입니다. 시작 시에 이 도우미는 하나의 포트에서 구성 정보를 수신합니다. 각 Access Manager에는 모든 영역에 서비스를 제공하는 Unix 도우미가 하나씩만 있습니다.

Access Manager를 설치하여 nobody 또는 루트가 아닌 사용자 아이디로 실행할 경우에도 AccessManager-base/SUNWam/share/bin/amunixd 프로세스는 여전히 루트로 실행되어야 합니다. Unix 인증 모듈은 localhost:58946에 대한 소켓을 열어 amunixd 데몬을 호출하여 Unix 인증 요청을 수신합니다. 기본 포트에서 amunixd 도우미 프로세스를 실행하려면 다음 명령을 입력합니다.

./amunixd

기본 포트가 아닌 포트에서 amunixd를 실행하려면 다음 명령을 입력합니다.

./amunixd [-c portnm] [ipaddress]

ipaddress 및 portnumber는AMConfig.properties의 UnixHelper.ipadrs(IPV4 형식) 및 UnixHelper.port 속성에 있습니다. amserver 명령줄 유틸리티를 통해 amunixd를 실행할 수 있습니다(amserver는 프로세스를 자동으로 실행하여 AMConfig.properties에서 포트 번호 및 IP 주소를 검색함).

/etc/nsswitch.conf 파일의 passwd 항목에 따라 인증에/etc/passwd 및 /etc/shadow 파일을 참조하는지 NIS를 참조하는지가 결정됩니다.

Windows 데스크탑 SSO

Windows 데스크탑 SSO 인증 모듈은 Windows 2000™에 사용되는 커버로스 기반 인증 플러그 인 모듈입니다. 이 모듈을 사용하면 KDC(Kerberos Distribution Center)에 대해 이미 인증을 받은 사용자는 로그인 조건(싱글 사인 온)을 다시 제출하지 않고도 Access Manager에 대해 인증을 받을 수 있습니다.

사용자는 SPNEGO(Simple and Protected GSS-API Negotiation Mechanism) 프로토콜을 통해 Access Manager에 커버로스 토큰을 제공합니다. 이 인증 모듈을 통해 Access Manager에 커버로스 기반 싱글 사인 온을 수행하려면 사용자는 클라이언트측에서 자신을 인증하도록 SPNEGO 프로토콜을 지원해야 합니다. 일반적으로 이 프로토콜을 지원하는 사용자는 이 모듈을 사용하여 Access Manager에 인증할 수 있습니다. 클라이언트측 토큰의 가용성에 따라 이 모듈은 SPENGO 토큰 또는 커버로스 토큰(두 경우 모두 동일한 프로토콜)을 제공합니다. Windows 2000 이상에서 실행되는 Microsoft Internet Explorer(5.01 이상)는 현재 이 프로토콜을 지원합니다. 또한 Mozilla 1.4 on Solaris(9 및 10)도 SPNEGO 지원 기능이 있으나 Solaris에서 SPNEGO를 지원하지 않으므로 반환되는 토큰은 커버로스 토큰뿐입니다.

주 –

커버로스 V5 인증 모듈의 새 기능을 활용하려면 JDK 1.4 이상을 사용하고 이 SPNEGO 모듈에서 커버로스 기반 SSO를 수행하려면 Java GSS API를 사용해야 합니다.

Internet Explorer의 알려진 제한 사항

WindowsDesktopSSO 인증용으로 Microsoft Internet Explorer 6.x를 사용하고, 브라우저에 WindowsDesktopSSO 모듈에서 구성된 KDC 영역과 일치하는 사용자의 커버로스/SPNEGO 토큰에 대한 액세스 권한이 없는 경우 브라우저가 WindowsDesktopSSO 모듈 인증에 실패하면 다른 모듈에 대해 올바르게 작동하지 않습니다. 이 문제의 직접적인 원인은 Internet Explorer에서 WindowsDesktopSSO 모듈 실패 후 다른 모듈의 콜백이 프롬프트에 표시되는 경우에도 브라우저에서 이를 Access Manager에 전달할 수 없기 때문이며, 이러한 불능 상태는 브라우저를 다시 시작할 때까지 계속됩니다. 즉 null 사용자 자격 증명 때문에 WindowsDesktopSSO 실패 후 수신한 모든 모듈도 실패합니다.

자세한 내용은 다음 설명서를 참조하십시오.

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Windows 데스크탑 SSO 구성

Windows 데스크탑 SSO 인증을 활성화하는 두 단계 프로세스는 다음과 같습니다.

Windows 2000 도메인 제어기에서 사용자를 생성합니다.
Internet Explorer를 설정합니다.

Windows 2000 도메인 제어기에서 사용자를 생성하려면

단계

도메인 제어기에서 Access Manager 인증 모듈에 사용할 사용자 계정을 만듭니다.
1. 시작 메뉴에서 프로그램>관리 도구로 이동합니다.
2. 활성 디렉토리 사용자 및 컴퓨터를 선택합니다.
3. 사용자 아이디(로그인 이름)가 Access Manager 호스트 이름인 새 사용자를 만듭니다. Access Manager 호스트 이름에는 도메인 이름이 포함되지 않아야 합니다.

사용자 계정을 서비스 공급자 이름과 연결하고 Access Manager가 설치된 시스템으로 키탭 파일을 내보냅니다. 이를 수행하려면 다음 명령을 실행합니다.

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 

hostname.host.keytab

ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 

password -mapuser userName-out hostname

.HTTP.keytab

ktpass 명령에는 다음과 같은 매개 변수가 사용됩니다.

hostname. Access Manager를 실행하는 호스트 이름(도메인 이름 없음)입니다.

domainname . Access Manager 도메인 이름

DCDOMAIN. 도메인 제어기의 도메인 이름입니다. Access Manager 도메인 이름과 다를 수도 있습니다.

password . 사용자 계정의 비밀번호입니다. ktpass에서는 비밀번호를 확인하지 않으므로 비밀번호가 정확한지 확인합니다.

userName. 사용자 계정 아이디입니다. 호스트 이름과 같아야 합니다.

주 –

두 키탭 파일이 모두 안전하게 보존되는지 확인합니다.

서비스 템플리트 값은 다음 예와 비슷해야 합니다.

서비스 기본: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

키탭 파일 이름:/tmp/machine1.HTTP.keytab

커버로스 영역: ISQA.EXAMPLE.COM

커버로스 서버 이름:machine2.EXAMPLE.com

도메인 이름과 함께 기본 반환:false

인증 수준: 22

서버를 다시 시작합니다.

Internet Explorer를 설정하려면

이 단계는 Microsoft Internet Explorer™ 6 이상에 적용됩니다. 이전 버전을 사용하는 경우 Access Manager가 브라우저의 인터넷 영역에 있고 고유 Windows 인증을 사용하는지 확인하십시오.

단계

도구 메뉴에서 인터넷 옵션>고급/보안>보안으로 이동합니다.

통합된 Windows 인증 사용 옵션을 선택합니다.

보안>로컬 인터넷으로 이동합니다.
1. 사용자 지정 수준을 선택합니다. 사용자 인증/로그온 창에서 인트라넷 영역에서만 자동으로 로그온 옵션을 선택합니다.
2. 사이트로 가서 옵션을 모두 선택합니다.
3. 고급을 누르고 로컬 영역에 Access Manager를 추가합니다(아직 추가되지 않은 경우).

Windows NT

Access Manager를 구성하여 이미 설치된 Windows NT /Windows 2000 서버에서 작업할 수 있습니다. Access Manager는 NT 인증의 클라이언트 부분을 제공합니다.

NT 서버를 구성합니다. 자세한 내용은 Windows NT 서버 설명서를 참조하십시오.
Windows NT 인증 모듈을 추가하여 활성화하려면 Solaris 시스템의 Access Manager와 통신하도록 Samba 클라이언트를 설치해야 합니다.

Samba 클라이언트 설치

Windows NT 인증 모듈을 활성화하려면 Samba Client2.2.2를 다음 디렉토리에 다운로드하여 설치해야 합니다.

AccessManager-base/SUNWam/bin

Samba Client는 별도의 Windows NT/2000 Server를 필요로 하지 않고 Windows 시스템과 UNIX 시스템을 블렌딩하는 파일 및 인쇄 서버입니다. 자세한 내용을 보거나 Samba Client를 다운로드하려면 http://wwws.sun.com/software/download/products/3e3af224.html에 액세스하십시오.

Red Hat Linux는 Samba 클라이언트와 함께 제공됩니다. 이 클라이언트는 다음 디렉토리에 있습니다.

/usr/bin

Linux용 Windows NT 인증 모듈을 사용하여 인증하려면 다음 Access Manager 디렉토리에 클라이언트 바이너리를 복사합니다.

AccessManager-base/sun/identity/bin

주 –

인터페이스가 여러 개인 경우에는 추가 구성이 필요합니다. smb.conf 파일에서 구성에 의해 다수의 인터페이스가 설정될 수 있으므로 mbclient로 전달됩니다.

인증 모듈 인스턴스

기본 인증 모듈을 기반으로 영역에 대해 여러 인증 모듈 인스턴스를 만들 수 있습니다. 개별적으로 구성된 같은 인증 모듈의 여러 인스턴스를 추가할 수 있습니다.

새 인증 모듈 인스턴스를 만들려면

단계

새 인증 모듈 인스턴스를 추가할 영역의 이름을 누릅니다.

인증 탭을 선택합니다.

주 –
관리자 인증 구성 버튼은 관리자에 대해서만 인증 서비스를 정의합니다. 관리자 인증 모듈이 최종 사용자의 모듈과 달라야 하는 경우 이 속성을 사용할 수 있습니다. 이 속성에 구성된 모듈은 콘솔에 액세스할 때 선택됩니다.

모듈 인스턴스 목록에서 새로 만들기를 누릅니다.

인증 모듈 인스턴스의 이름을 입력합니다. 이름은 고유해야 합니다.

영역에 대한 인증 모듈의 유형을 선택합니다.

만들기를 누릅니다.

새로 만든 모듈 인스턴스의 이름을 누르고 해당 모듈의 등록 정보를 편집합니다. 각 모듈 유형의 등록 정보에 대한 정의는 온라인 도움말의 인증 절을 참조하십시오.

이러한 단계를 반복하여 여러 개의 모듈 인스턴스를 추가합니다.

인증 체이닝

인증을 하나 이상 구성할 수 있으므로 사용자는 모든 인증에 인증 자격 증명을 전달해야 합니다. 이를 인증 체이닝이라고 합니다. Access Manager의 인증 체이닝은 인증 서비스에 통합된 JAAS 프레임워크를 사용하여 수행됩니다. 모듈 체이닝은 인증 구성 서비스 아래에 구성되어 있습니다.

새 인증 체인을 만들려면

단계

새 인증 체인을 추가할 영역의 이름을 누릅니다.

인증 탭을 선택합니다.

인증 체이닝 목록에서 새로 만들기를 누릅니다.

인증 체인의 이름을 입력합니다.

만들기를 누릅니다.

추가를 눌러 체인에 포함할 인증 모듈 인스턴스를 정의합니다. 이를 수행하려면 인스턴스 목록에서 모듈 인스턴스 이름을 선택합니다. 이 목록에 표시된 모듈 인스턴스 이름은 모듈 인스턴스 속성에서 만들어집니다.

체인의 기준을 선택합니다. 이러한 플래그는 플래그가 정의된 인증 모듈에 대한 적용 기준을 설정합니다. 실행을 위한 단계가 있습니다. 필수는 가장 높고 옵션은 가장 낮습니다.

필요

모듈 인스턴스가 성공적이어야 합니다. 성공한 경우 인증 체이닝 목록의 그 다음 항목에 대해 인증이 계속됩니다. 실패한 경우 컨트롤이 응용 프로그램에 반환됩니다(인증 체이닝 목록의 그 다음 항목에 대해 인증이 진행되지 않음).

필수

이 모듈에 대한 인증이 성공적이어야 합니다. 체인의 필수 모듈 중 하나라도 실패하면 결과적으로 전체 인증 체인이 실패합니다. 그러나 필수 모듈이 성공하든 실패하든 컨트롤은 체인에서 그 다음 모듈에 대해 계속 진행됩니다.

충분

모듈 인스턴스가 반드시 성공적이지 않아도 됩니다. 성공한 경우 컨트롤이 즉시 응용 프로그램에 반환됩니다(인증 모듈 목록의 그 다음 항목에 대해 인증이 진행되지 않음). 실패한 경우 인증 체이닝 목록의 그 다음 항목에 대해 인증이 계속됩니다.

선택 사항

모듈 인스턴스가 반드시 성공적이지 않아도 됩니다. 성공 또는 실패한 경우 인증 체이닝 목록의 그 다음 항목에 대해 인증이 계속 진행됩니다.

체인에 대한 옵션을 입력합니다. 이렇게 하면 키=값 쌍으로 모듈에 대한 추가 옵션을 허용합니다. 여러 옵션을 사용할 경우 공백으로 구분합니다.

다음 속성을 정의합니다.

성공한 로그인 URL

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

실패한 로그인 URL

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

인증 사후 처리 클래스

로그인 성공 또는 실패 후에 인증 사후 처리를 사용자 정의하는 데 사용되는 Java 클래스의 이름을 정의합니다.

저장을 누릅니다.

인증 유형

Sun Java System Access Manager 7 2005Q4 Developer’s Guide의 5 장, Using Authentication APIs and SPIs의 5장 Using Authentication APIs and SPIs를 참조하십시오. 인증 모듈을 구성하기 전에 특정 인증 모듈 이름을 포함하도록 핵심 인증 서비스 속성인 영역 인증 모듈을 수정해야 합니다.

인증 구성 서비스는 다음 인증 유형에 대한 인증 모듈을 정의하는 데 사용됩니다.

이러한 인증 유형 중 하나에 대해 인증 모듈을 정의한 경우, 인증 프로세스의 성공 또는 실패 여부에 따라 사후 처리 Java 클래스 사양뿐만 아니라 리디렉션 URL을 제공하도록 해당 모듈을 구성할 수 있습니다.

인증 유형에 따른 액세스 결정 방법

이러한 방법마다 사용자 인증이 성공하기도 하고 실패하기도 합니다. 그러나 방법이 결정된 다음에는 다음 절차를 따르게 됩니다. 단계 1에서부터 단계 3까지는 인증 성공 후, 단계 4는 인증 성공 및 실패 후에 모두 나타납니다.

Access Manager는 인증된 사용자가 Directory Server 데이터 저장소에 정의되어 있고 프로필이 활성 상태인지 여부를 확인합니다.

핵심 인증 모듈의 사용자 프로필 속성은 Required, Dynamic, Dynamic with User Alias 또는 Ignored 중 하나로 정의될 수 있습니다. 인증 성공 후 Access Manager는 인증된 사용자가 Directory Server 데이터 저장소에 정의되어 있는지 확인하고, 사용자 프로필 값이 Required인 경우 해당 프로필이 활성 상태인지 확인합니다(이는 기본적인 경우입니다). 사용자 프로필이 Dynamically Configured 인 경우에는 인증 서비스에서 Directory Server 데이터 저장소에 사용자 프로필을 작성합니다. 사용자 프로필이 Ignore로 설정되어 있으면 사용자 검증이 수행되지 않습니다.
인증 사후 처리 SPI의 실행이 완료되었습니다.

핵심 인증 모듈에는 인증 사후 처리 클래스 이름이 그 값으로서 포함되는 인증 사후 처리 클래스 속성이 들어 있습니다. AMPostAuthProcessInterface는 사후 처리 인터페이스로서인증 성공/실패 시 또는 로그아웃 시 실행될 수 있습니다.
다음 등록 정보가 세션 토큰에 추가되거나 세션 토큰에서 업데이트된 후 사용자의 세션이 활성화됩니다.

realm. 사용자가 속한 영역의 DN입니다.

Principal. 사용자의 DN입니다.

Principals. 사용자가 인증한 이름의 목록입니다. (이 등록 정보에는 세로줄(|)로 구분한 목록으로 정의된 둘 이상의 값이 있을 수 있습니다.)

UserId. 모듈에서 반환된 사용자의 DN이거나, LDAP 또는 구성원 이외의 모듈의 경우 사용자 이름입니다. (모든 Principal은 동일한 사용자에 매핑되어야 합니다. UserID는 Principal이 매핑되는 사용자 DN입니다.)

주 –
이 등록 정보는 DN 값이 아닐 수 있습니다.

UserToken. 사용자 이름입니다. (모든 Principal은 동일한 사용자에 매핑되어야 합니다. UserToken은 Principal이 매핑된 사용자 이름입니다.)

Host. 클라이언트의 호스트 이름이나 IP 주소입니다.

authLevel. 사용자의 최고 인증 수준입니다.

AuthType. 사용자가 인증한 인증 모듈을 세로줄(|)로 구분한 목록(예: module1|module2|module3)입니다.

clientType. 클라이언트 브라우저의 장치 유형입니다.

Locale. 클라이언트의 로켈입니다.

CharSet. 클라이언트에 대해 결정된 문자 집합입니다.

Role. 역할 기반의 인증에만 적용될 수 있으며 사용자가 속한 역할입니다.

Service. 서비스 기반의 인증에만 적용될 수 있으며 사용자가 속한 서비스입니다.
Access Manager에서는 인증 성공 또는 실패 후 사용자를 리디렉션할 위치에 대한 정보를 찾습니다.

URL 리디렉션 위치는 Access Manager 페이지 또는 URL이 될 수 있습니다. 리디렉션은 Access Manager가 인증 방법을 기준으로 찾은 리디렉션의 우선 순위 순서와 해당 인증이 성공 또는 실패했는지 여부에 따라 달라집니다. 이러한 순서는 다음 인증 방법 절에서 URL 리디렉션 부분에 자세히 설명되어 있습니다.

URL 리디렉션

인증 구성 서비스에서 성공적인 인증 또는 실패한 인증에 대한 URL 리디렉션을 할당할 수 있습니다. URL은 이 서비스의 로그인 성공 URL 및 로그인 실패 URL 속성에 자동으로 정의됩니다. URL 리디렉션을 사용 가능하게 하려면 영역에 인증 구성 서비스를 추가하여 해당 서비스를 역할, 영역 또는 사용자에 대해 구성 가능하게 만들어야 합니다. 인증 구성 서비스를 추가할 경우 LDAP - 필수와 같은 인증 모듈을 추가해야 합니다.

영역 기반 인증

이 인증 방법을 사용하면 영역 또는 하위 영역에 대해 인증할 수 있습니다. Access Manager에 대한 기본 인증 방법입니다. 영역 인증 방법은 핵심 인증 모듈을 영역에 등록하고 영역 인증 구성 속성을 정의함으로써 설정됩니다.

영역 기반 인증 로그인 URL

인증 영역은 realm 매개 변수 또는 domain 매개 변수를 정의하여 사용자 인터페이스 로그인 URL에서 지정될 수 있습니다. 인증 요청 영역은 다음 매개 변수/속성에 의해 여기에 표시된 순서대로 결정됩니다.

domain 매개 변수
realm 매개 변수

관리자 서비스의 DNS Alias Names 속성 값

영역을 정확하게 호출한 다음에는 사용자가 인증할 인증 모듈을 핵심 인증 서비스의 영역 인증 구성 속성에서 검색합니다. 영역 기반 인증을 지정하고 초기화하는 데 사용하는 로그인 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login

http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name

정의된 매개 변수가 없을 때는 로그인 URL에 지정된 서버 호스트와 도메인으로부터 영역이 결정됩니다.

영역 기반 인증 리디렉션 URL

조직 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 영역 기반 인증 리디렉션 URL

성공한 영역 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 영역 기반 인증 리디렉션 URL

실패한 영역 기반 인증의 리디렉션 URL은 다음 장소를 다음과 같은 순서 대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
gotoOnFail 로그인 URL 매개 변수에서 설정한 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

영역 기반 인증을 구성하려면

먼저 핵심 인증 서비스를 영역에 추가하여 영역에 인증 모듈을 설정합니다.

영역의 인증 속성을 구성하려면

단계

인증 체인을 추가할 영역으로 이동합니다.

인증 탭을 누릅니다.

풀다운 메뉴에서 기본 인증 체인을 선택합니다.

풀다운 메뉴에서 관리자 인증 체인을 선택합니다. 관리자의 인증 모듈이 최종 사용자의 모듈과 달라야 하는 경우 이 속성을 사용할 수 있습니다. 기본 인증 모듈은 LDAP입니다.

인증 체인을 정의한 후 저장을 누릅니다.

조직 기반 인증

이 인증 유형은 레거시 모드로 설치된 Access Manager 배포에만 적용됩니다.

이 인증 방법을 사용하면 조직 또는 하위 조직에 사용자를 인증할 수 있습니다. 이는 Access Manager 인증의 기본 방법입니다. 조직 인증 방법은 핵심 인증 모듈을 조직에 등록하고 조직 인증 구성 속성을 정의함으로써 설정됩니다.

조직 기반 인증 로그인 URL

인증 조직은 사용자 인터페이스 로그인 URL에서 org 매개 변수나 domain 매개 변수를 정의하는 방법으로 지정할 수 있습니다. 인증 요청 조직은 다음 매개 변수/속성에 의해 여기에 표시된 순서대로 결정됩니다.

domain 매개 변수
org 매개 변수

관리 서비스의 DNS Alias Names(조직 별칭 이름) 속성 값

조직을 정확하게 호출한 다음에는 사용자가 인증할 인증 모듈을 핵심 인증 서비스의 조직 인증 구성 속성에서 검색합니다. 조직 기반 인증을 지정하고 초기화하는 데 사용되는 로그인 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login

http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name

http://server_name.domain_name:port/amserver/UI/Login?org=org_name

정의된 매개 변수가 없을 때는 로그인 URL에 지정된 서버 호스트와 도메인으로부터 조직이 결정됩니다.

조직 기반 인증 리디렉션 URL

성공한 조직 기반 인증 리디렉션 URL

성공한 조직 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 조직 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 조직 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 조직 기반 인증 리디렉션 URL

실패한 조직 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
gotoOnFail 로그인 URL 매개 변수에서 설정한 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 조직 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 조직 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

조직 기반 인증을 구성하려면

먼저 핵심 인증 서비스를 조직에 추가하여 조직에 인증 모듈을 설정합니다.

조직의 인증 속성을 구성하려면

단계

인증 체인을 추가할 조직으로 이동합니다.

인증 탭을 누릅니다.

풀다운 메뉴에서 기본 인증 체인을 선택합니다.

풀다운 메뉴에서 관리자 인증 체인을 선택합니다. 관리자의 인증 모듈이 최종 사용자의 모듈과 달라야 하는 경우 이 속성을 사용할 수 있습니다. 기본 인증 모듈은 LDAP입니다.

인증 체인을 정의한 후 저장을 누릅니다.

역할 기반 인증

이 인증 방법을 사용하면 영역이나 하위 영역 내의 (정적 또는 필터링된) 역할에 인증할 수 있습니다.

주 –

인증 구성 서비스를 역할의 인스턴스로 등록하기 전에 먼저 영역에 등록해야 합니다.

인증이 성공하려면 사용자는 해당 역할에 속하고 이 역할에 구성된 인증 구성 서비스 인스턴스에 정의된 모듈마다 인증해야 합니다. 역할 기반 인증의 인스턴스마다 다음 속성을 지정할 수 있습니다.

충돌 해결 수준. 같은 사용자의 서로 다른 역할에 정의된 인증 구성 서비스 인스턴스에 대해 우선 순위 수준을 설정합니다. 예를 들어, User1이 Role1 및 Role2에 모두 지정되고 Role1에 더 높은 충돌 해결 수준이 설정될 경우 사용자가 인증을 시도할 때 성공 또는 실패 리디렉션과 인증 사후 프로세스에 대해 Role1에 더 높은 우선 순위가 적용됩니다.

인증 구성.역할의 인증 프로세스에 구성된 인증 모듈을 정의합니다.

로그인 성공 URL.성공한 인증에서 사용자가 리디렉션될 URL을 정의합니다.

로그인 실패 URL. 실패한 인증에서 사용자가 리디렉션될 URL을 정의합니다.

인증 사후 처리 클래스. 인증 사후 인터페이스를 정의합니다.

역할 기반 인증 로그인 URL

역할 기반 인증은 role 매개 변수를 정의하는 방법으로 사용자 인터페이스 로그인 URL에서 지정할 수 있습니다. 역할을 정확하게 호출한 다음에는 사용자가 인증할 인증 모듈을 해당 역할에 대해 정의된 인증 구성 서비스 인스턴스에서 검색합니다.

이 역할 기반 인증을 지정하고 초기화하는 데 사용되는 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?role=role_name

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&role=role_name

realm 매개 변수가 구성되어 있지 않은 경우 역할이 속한 영역은 로그인 URL 자체에 지정된 서버 호스트와 도메인으로 결정됩니다.

역할 기반 인증 리디렉션 URL

역할 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 역할 기반 인증 리디렉션 URL

성공한 역할 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자가 인증한 역할의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
인증된 사용자의 다른 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL(이전 리디렉션 URL이 실패한 경우 이 옵션으로 대체됩니다.)
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자가 인증한 역할의 iplanet-am-auth-login-success-url 속성에 설정된 URL
인증된 사용자의 다른 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL(이전 리디렉션 URL이 실패한 경우 이 옵션으로 대체됩니다.)
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 역할 기반 인증 리디렉션 URL

실패한 역할 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자가 인증한 역할의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
인증된 사용자의 다른 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL(이전 리디렉션 URL이 실패한 경우 이 옵션으로 대체됩니다.)
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자가 인증한 역할의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
인증된 사용자의 다른 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL(이전 리디렉션 URL이 실패한 경우 이 옵션으로 대체됩니다.)
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

역할 기반 인증을 구성하려면

단계

인증 구성 서비스를 추가할 영역(또는 조직)으로 이동합니다.

주제 탭을 누릅니다.

필터링된 역할 또는 역할을 누릅니다.

인증 구성을 설정할 역할을 선택합니다.

인증 구성 서비스가 역할에 추가되지 않은 경우 추가를 누르고 인증 서비스를 선택하고 다음을 누릅니다.

풀다운 메뉴에서 활성화할 기본 인증 체인을 선택합니다.

저장을 누릅니다.

주 –
새 역할을 만들 경우 인증 구성 서비스가 해당 역할에 자동으로 할당되지 않습니다. 새 역할을 만들기 전에 역할 프로필 페이지의 위쪽에 있는 인증 구성 서비스 옵션을 선택하십시오.

역할 기반 인증이 사용 가능한 경우 구성원을 구성할 필요가 없으므로 LDAP 인증 모듈을 기본값으로 그대로 사용할 수 있습니다.

서비스 기반 인증

이 인증 방법을 사용하면 영역 또는 하위 영역에 등록된 특정 서비스나 응용 프로그램에 인증할 수 있습니다. 이러한 서비스는 인증 구성 서비스 내에 서비스 인스턴스로 구성되고 인스턴스 이름과 연관됩니다. 인증이 성공하려면 사용자는 해당 서비스에 구성된 인증 구성 서비스 인스턴스에 정의된 모듈마다 인증해야 합니다. 서비스 기반 인증의 인스턴스마다 다음 속성을 지정할 수 있습니다.

인증 구성.서비스의 인증 프로세스에 구성된 인증 모듈을 정의합니다.

로그인 성공 URL.성공한 인증에서 사용자가 리디렉션될 URL을 정의합니다.

로그인 실패 URL. 실패한 인증에서 사용자가 리디렉션될 URL을 정의합니다.

인증 사후 처리 클래스. 인증 사후 인터페이스를 정의합니다.

서비스 기반 인증 로그인 URL

서비스 기반 인증은 service 매개 변수를 정의하는 방법으로 사용자 인터페이스 로그인 URL에서 지정할 수 있습니다. 서비스를 호출한 다음에는 해당 서비스에 대해 정의된 인증 구성 서비스로부터 사용자가 인증할 인증 모듈을 검색합니다.

서비스 기반 인증을 지정하고 초기화하는 데 사용되는 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/

Login?service=auth-chain-name

및

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

e

org 매개 변수를 지정하지 않은 경우에는 로그인 URL 자체에 지정된 서버 호스트와 도메인으로부터 영역이 결정됩니다.

서비스 기반 인증 리디렉션 URL

서비스 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 서비스 기반 인증 리디렉션 URL

성공한 서비스 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자가 인증한 서비스의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자가 인증한 서비스의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 서비스 기반 인증 리디렉션 URL

실패한 서비스 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자가 인증한 서비스의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자가 인증한 서비스의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

서비스 기반 인증을 구성하려면

인증 구성 서비스를 추가한 다음 서비스에 대한 인증 모듈을 설정합니다. 구성 방법:

단계

서비스 기반 인증을 구성할 영역을 선택합니다.

인증 탭을 누릅니다.

인증 모듈 인스턴스를 만듭니다.

인증 체인을 만듭니다.

저장을 누릅니다.

영역에 대한 서비스 기반 인증에 액세스하려면 다음 주소를 입력합니다.

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

사용자 기반 인증

이 인증 방법을 사용하면 사용자에 대해 특별히 구성된 인증 프로세스를 인증할 수 있습니다. 프로세스는 사용자 프로필의 사용자 인증 구성 속성 값으로 구성됩니다. 인증이 성공하려면 정의된 모듈마다 인증해야 합니다.

사용자 기반 인증 로그인 URL

사용자 기반 인증은 사용자 인터페이스 로그인 URL에서 user 매개 변수를 정의하는 방법으로 지정할 수 있습니다. 사용자를 정확하게 호출한 다음에는 사용자가 인증할 인증 모듈을 정의된 사용자 인증 구성 인스턴스에서 검색합니다.

이 역할 기반 인증을 지정하고 초기화하는 데 사용되는 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?user=user_name

http://server_name.domain_name:port/amserver/UI/Login?org=org_name&user=user_name

realm 매개 변수를 지정하지 않은 경우 역할이 속한 영역은 로그인 URL 자체에 지정된 서버 호스트와 도메인에서 결정됩니다.

사용자 별칭 목록 속성

사용자 기반 인증에 대한 요청을 받으면 인증 서비스에서는 먼저 사용자가 유효한 사용자인지 확인하고 그에 대한 인증 구성 데이터를 검색합니다. 사용자 로그인 URL 매개 변수 값과 관련하여 유효한 사용자 프로필이 둘 이상 있는 경우에는 모든 프로필이 지정된 사용자에 매핑되어야 합니다. 사용자 프로필의 사용자 별칭 속성(iplanet-am-user-alias-list)은 해당 사용자에 속한 다른 프로필을 정의할 수 있는 위치입니다. 매핑이 실패하면 사용자는 유효한 세션에서 거부됩니다. 사용자 중 하나가 최상위 관리자이므로 사용자 매핑 검증이 수행되지 않고 사용자가 최상위 관리자 권한을 가진 경우는 예외가 될 수 있습니다.

사용자 기반 인증 리디렉션 URL

사용자 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 사용자 기반 인증 리디렉션 URL

성공한 사용자 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 사용자 기반 인증 리디렉션 URL

실패한 사용자 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
gotoOnFail 로그인 URL 매개 변수에서 설정한 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

사용자 기반 인증을 구성하려면

단계

사용자에 대해 인증을 구성할 영역으로 이동합니다.

주제 탭을 누르고 사용자를 누릅니다.

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

사용자 프로필이 표시됩니다.

주 –
새 사용자를 만들 경우 인증 구성 서비스가 사용자에 자동으로 할당되지 않습니다. 사용자를 만들기 전에 서비스 프로필에 있는 인증 구성 서비스 옵션을 선택하십시오. 이 옵션을 선택하지 않으면 사용자가 해당 역할에 대해 정의된 인증 구성을 상속하지 못합니다.

사용자 인증 구성 속성에서 적용할 인증 체인을 선택합니다.

저장을 누릅니다.

인증 수준 기반 인증

각 인증 모듈에 해당 인증 수준에 대한 정수 값을 연결할 수 있습니다. 서비스 구성에서 인증 모듈의 등록 정보 화살표를 누르고 모듈의 인증 수준 속성에 해당하는 값을 변경하여 인증 수준을 할당할 수 있습니다. 높은 인증 수준은 사용자가 하나 또는 여러 인증 모듈에 인증을 얻은 후에 사용자에 높은 신뢰도를 정의합니다.

사용자가 모듈에 성공적으로 인증하면 인증 수준이 사용자의 SSO 토큰에 설정됩니다. 사용자가 여러 인증 모듈에 인증해야 하는 경우 성공적으로 인증하면 최고 인증 수준 값이 사용자의 SSO 토큰에 설정됩니다.

사용자가 서비스에 대한 액세스를 시도한 경우 서비스는 사용자의 SSO 토큰에서 인증 수준을 확인하여 사용자에게 액세스를 허용할지 여부를 결정할 수 있습니다. 그런 다음 설정된 인증 수준을 사용하여 인증 모듈을 통해 이동하도록 사용자를 리디렉션합니다.

사용자는 특정 인증 수준을 사용하여 인증 모듈에 액세스 할 수도 있습니다. 예를 들어, 다음 구문을 사용하여 로그인을 수행합니다.

http://hostname:port/deploy_URI/UI/Login?authlevel=

auth_level_value

인증 수준이 auth_level_value보다 크거나 같은 모든 모듈은 사용자가 선택할 수 있는 인증 메뉴로 표시됩니다. 일치하는 모듈이 하나이면 이 인증 모듈에 대한 인증 페이지가 직접 표시됩니다.

이 인증 방법을 사용하면 관리자가 ID로 인증할 수 있는 모듈의 보안 수준을 지정할 수 있습니다. 인증 모듈마다 별도의 인증 수준 속성이 있고 이 속성의 값은 유효한 정수로 정의될 수 있습니다. 인증 수준 기반 인증을 사용하면 인증 서비스에서 인증 모듈을 포함하는 메뉴가 있는 모듈 로그인 페이지를 표시하는데, 이 인증 모듈의 인증 수준은 로그인 URL 매개 변수에서 지정한 값보다 크거나 같습니다. 사용자는 제시된 목록에서 모듈을 선택할 수 있습니다. 모듈을 선택하면 나머지 프로세스는 모듈 기반 인증에 따라 진행됩니다.

인증 수준 기반 인증 로그인 URL

인증 수준 기반 인증은 authlevel 매개 변수를 정의하는 방법으로 사용자 인터페이스 로그인 URL에서 지정할 수 있습니다. 관련된 모듈 목록이 있는 로그인 화면을 호출한 후 사용자는 인증할 모듈을 하나 선택해야 합니다. 인증 수준 기반 인증을 지정하고 초기화하는 데 사용되는 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?authlevel=authentication_level

및

http://server_name.domain_name:port/amserver/UI/

Login?realm=realm_name&authlevel=authentication_level

realm 매개 변수를 지정하지 않은 경우 사용자가 속한 영역은 로그인 URL 자체에 지정된 서버 호스트와 도메인으로부터 결정됩니다.

인증 수준 기반 인증 리디렉션 URL

인증 수준 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 인증 수준 기반 인증 리디렉션 URL

성공한 인증 수준 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 인증 수준 기반 인증 리디렉션 URL

실패한 인증 수준 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
gotoOnFail 로그인 URL 매개 변수에서 설정한 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

모듈 기반 인증

다음 구문을 사용하여 특정 인증 모듈에 액세스할 수 있습니다.

http://hostname:port/deploy_URI/UI/Login?module=

module_name

인증 모듈에 액세스하기 전에 인증 모듈 이름을 포함하도록 핵심 인증 서비스 속성인 영역 인증 모듈을 수정해야 합니다. 인증 모듈 이름이 이 속성에 없으면 사용자가 인증하려고 시도할 때 “인증 모듈이 거부되었습니다”라는 페이지가 표시됩니다.

이 인증 방법을 사용하면 사용자가 인증할 모듈을 지정할 수 있습니다. 지정된 모듈은 사용자가 액세스하는 영역 또는 하위 영역에 등록되어야 합니다. 이 모듈은 영역의 핵심 인증 서비스의 영역 인증 모듈 속성에서 구성됩니다. 이러한 모듈 기반 인증 요청을 받으면 인증 서비스에서 모듈이 정확하게 구성되었는지 확인하고 모듈이 정의되지 않은 경우에는 사용자 액세스가 거부됩니다.

모듈 기반 인증 로그인 URL

모듈 기반 인증은 사용자 인터페이스 로그인 URL에서 module 매개 변수를 정의하는 방법으로 지정할 수 있습니다. 모듈 기반 인증을 지정하고 초기화하는 데 사용되는 URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?module=authentication_module_name

http://server_name.domain_name:port/amserver/UI/

Login?org=org_name&module=authentication_module_name

org 매개 변수를 지정하지 않은 경우 사용자가 속한 영역은 로그인 URL 자체에 지정된 서버 호스트와 도메인으로부터 결정됩니다.

모듈 기반 인증 리디렉션 URL

모듈 기반 인증이 성공/실패하면 Access Manager는 사용자를 리디렉션할 위치 정보를 찾습니다. 응용 프로그램에서 이 정보를 찾는 순서는 다음과 같습니다.

성공한 모듈 기반 인증 리디렉션 URL

성공한 모듈 기반 인증의 리디렉션 URL은 다음 정보를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
goto 로그인 URL 매개 변수에서 설정한 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-success-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 프로필(amUser.xml)의 iplanet-am-user-success-url 속성에 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-success-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-success-url 속성에 설정된 URL

실패한 모듈 기반 인증 리디렉션 URL

실패한 모듈 기반 인증의 리디렉션 URL은 다음 장소를 순서대로 확인하여 결정합니다.

인증 모듈에서 설정한 URL
gotoOnFail 로그인 URL 매개 변수에서 설정한 URL
사용자 항목(amUser.xml)의 iplanet-am-user-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 대해 clientType 사용자 정의 파일에서 설정된 URL
iplanet-am-auth-login-failure-url 속성에 대해 전역 기본값으로서 clientType 사용자 정의 파일에서 설정된 URL
사용자 역할 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
사용자 영역 항목의 iplanet-am-auth-login-failure-url 속성에 설정된 URL
전역 기본값으로서 iplanet-am-auth-login-failure-url 속성에 설정된 URL

사용자 인터페이스 로그인 URL

인증 서비스 사용자 인터페이스는 웹 브라우저의 위치 표시줄에 로그인 URL을 입력하는 방법으로 액세스할 수 있습니다. 다음과 같이 URL을 입력합니다.

http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login

주 –

설치 도중 service_deploy_uri가 amserver로 구성됩니다. 이러한 기본 서비스 배포 URI은 이 설명서 전반에 걸쳐 사용됩니다.

사용자 인터페이스 로그인 URL에 로그인 URL 매개 변수가 추가되어 특정 인증 방법이나 성공 또는 실패한 인증 리디렉션 URL을 정의합니다.

로그인 URL 매개 변수

URL 매개 변수는 URL의 끝에 추가되는 이름/값 쌍입니다. 매개 변수는 물음표(?)로 시작하며name=value 형식으로 사용됩니다. 다음과 같이 여러 개의 매개 변수를 하나의 로그인 URL로 조합할 수 있습니다.

http://server_name.domain_name:port/amserver/UI/

Login?module=LDAP&locale=ja&goto=http://www.sun.com

매개 변수가 둘 이상인 경우 앰퍼샌드(&)로 분리됩니다. 그러나 매개 변수 조합은 다음 지침을 지켜야 합니다.

각 매개 변수는 하나의 URL에서 한 번만 사용되어야 합니다. 예를 들어, module=LDAP&module=NT는 사용할 수 없습니다.
org 매개 변수와 domain 매개 변수는 모두 로그인 영역을 결정합니다. 이 경우에는 로그인 URL에서 두 매개 변수 중 하나만 사용해야 합니다. 두 매개 변수를 모두 사용하면서 우선 순위를 지정하지 않으면 하나만 적용됩니다.
user, role, service, module 및 authlevel 매개 변수는 각각의 기준에 따라 인증 모듈을 정의하는 매개 변수입니다. 따라서 로그인 URL에는 이들 중 하나만 사용해야 합니다. 매개 변수를 두 개 이상 사용하면서 우선 순위를 지정하지 않으면 하나만 적용됩니다.

다음 절에서는 사용자 인터페이스 로그인 URL에 붙고 웹 브라우저의 위치 표시줄에 입력될 때 여러 가지 인증 기능을 수행하는 매개 변수를 설명합니다.

주 –

영역에 전사적으로 배포할 인증 URL 및 매개 변수를 간소화하기 위해 관리자는 간단한 URL을 사용하여 HTML 페이지를 구성할 수 있는데 이 페이지에는 구성된 모든 인증 방법에서 사용할 복잡한 로그인 URL 링크가 포함됩니다.

goto 매개 변수

goto=successful_authentication_URL 매개 변수는 인증 구성 서비스의 로그인 성공 URL에 정의된 값 대신 사용됩니다. 이 매개 변수는 인증이 성공하면 지정된 URL로 연결됩니다. goto=logout_URL 매개 변수는 사용자 로그아웃 시 지정된 URL로 연결하기 위해 사용합니다. 성공적인 인증 URL의 예는 다음과 같습니다.

http://server_name.domain_name:port/amserver/

UI/Login?goto=http://www.sun.com/homepage.html

goto 로그아웃 URL의 예는 다음과 같습니다.

http://server_name.domain_name:port/amserver/

UI/Logout?goto=http://www.sun.com/logout.html.

주 –

Access Manager에서 성공적인 인증 리디렉션 URL을 찾을 때 적용하는 우선 순위가 있습니다. 이러한 리디렉션 URL 및 해당 순서는 인증 방법에 따라 다르므로 인증 유형 절에서 이 순서(및 관련 정보)를 자세히 설명합니다.

gotoOnFail 매개 변수

gotoOnFail=failed_authentication_URL 매개 변수는 인증 구성 서비스의 로그인 실패 URL에 정의된 값 대신 사용됩니다. 이 매개 변수는 사용자 인증 실패 시 지정된 URL로 연결됩니다. 예를 들어 gotoOnFail URL은 http:// server_name.domain_name:port /amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html이 될 수 있습니다.

주 –

Access Manager에서 실패한 인증 리디렉션 URL을 찾을 때 적용하는 우선 순위가 있습니다. 이러한 리디렉션 URL 및 해당 순서는 인증 방법에 따라 다르므로 인증 유형 절에서 이 순서(및 관련 정보)를 자세히 설명합니다.

realm 매개 변수

org=realmName 매개 변수를 사용하면 사용자가 지정된 영역에서 사용자로 인증할 수 있습니다.

주 –

아직 지정된 영역의 구성원이 아닌 사용자가 realm 매개 변수를 사용하여 인증하려고 하면 오류 메시지가 나타납니다. 그러나 다음 사항이 모두 해당되면 Directory Server에서 사용자 프로필을 동적으로 작성할 수 있습니다.

핵심 인증 서비스의 사용자 프로필 속성은 Dynamic 또는 Dynamic with User Alias로 설정되어야 합니다.
사용자는 필수 모듈에 성공적으로 인증해야 합니다.
사용자가 아직 Directory Server에 프로필이 없습니다.

이 매개 변수를 통해 영역 및 로켈 설정에 따라 정확한 로그인 페이지가 표시됩니다. 이 매개 변수를 설정하지 않은 경우 기본값은 최상위 영역입니다. 예를 들어, 다음은 org URL이 될 수 있습니다.

http://server_name.domain_name:port/amserver/UI/Login?realm=sun

org 매개 변수

org=orgName 매개 변수를 사용하면 사용자가 지정된 조직에서 사용자로 인증할 수 있습니다.

주 –

아직 지정된 조직의 구성원이 아닌 사용자가 org 매개 변수를 사용하여 인증하려고 하면 오류 메시지가 나타납니다. 그러나 다음 사항이 모두 해당되면 Directory Server에서 사용자 프로필을 동적으로 작성할 수 있습니다.

핵심 인증 서비스의 사용자 프로필 속성은 Dynamic 또는 Dynamic with User Alias로 설정되어야 합니다.
사용자는 필수 모듈에 성공적으로 인증해야 합니다.
사용자가 아직 Directory Server에 프로필이 없습니다.

이 매개 변수를 통해 조직 및 로켈 설정에 따라 정확한 로그인 페이지가 표시됩니다. 이 매개 변수를 설정하지 않은 경우 기본값은 최상위 조직입니다. 예를 들어, 다음은 org URL이 될 수 있습니다.

http://server_name.domain_name:port/amserver/UI/Login?org=sun

user 매개 변수

user=userName 매개 변수는 시용자 프로필의 사용자 인증 구성 속성에서 구성된 모듈을 기반으로 인증을 실행합니다. 예를 들어, 한 사용자의 프로필은 인증 모듈을 사용하여 인증하도록 구성하고, 다른 사용자는 LDAP 모듈을 사용하여 인증하도록 구성할 수 있습니다. 이 매개 변수를 추가하면 사용자의 조직에 구성된 방법이 아닌 사용자 자신이 구성한 인증 프로세스를 따르게 됩니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?user=jsmith

role 매개 변수

role=roleName 매개 변수는 지정된 역할을 위해 구성된 인증 프로세스를 사용자에게 전송합니다. 아직 지정된 역할의 구성원이 아닌 사용자가 이 매개 변수를 사용하여 인증하려고 하면 오류 메시지가 나타납니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?role=manager.

locale 매개 변수

Access Manager에는 콘솔 자체는 물론 인증 프로세스에서도 현지화된 화면(영어가 아닌 다른 언어로 번역된 화면)을 표시하는 기능이 있습니다. locale=localeName 매개 변수를 사용하면 지정된 로켈이 정의된 다른 로켈보다 우선 적용됩니다. 로그인 로켈은 다음 위치에서 순서에 따라 구성을 검색한 후 클라이언트에 표시됩니다.

로그인 URL에서 locale 매개 변수의 값

locale=localeName 매개 변수의 값은 정의된 다른 로켈보다 우선 적용됩니다.
사용자 프로필에 정의된 로켈

URL 매개 변수가 없을 때는 사용자 프로필의 사용자 기본 언어 속성에 설정된 값에 따라 로켈이 표시됩니다.
HTTP 헤더에 정의된 로켈

이 로켈은 웹 브라우저에서 설정합니다.
핵심 인증 서비스에 정의된 로켈

이 로켈은 핵심 인증 모듈의 기본 인증 로켈 속성의 값입니다.
플랫폼 서비스에 정의된 로켈

이 로켈은 플랫폼 서비스에서 플랫폼 로켈 속성의 값입니다.

운영 체제 로켈

여기서 파생된 로켈은 사용자의 세션 토큰에 저장되며 Access Manager에서는 현지화된 인증 모듈을 로드할 때만 이를 사용합니다. 인증이 성공하면 사용자 프로필의 사용자 기본 언어 속성에 정의된 로켈이 사용됩니다. 아무 것도 설정되어 있지 않을 때는 인증에 사용된 로켈이 적용됩니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?locale=ja.

주 –

Access Manager에서 화면 텍스트와 오류 메시지 현지화 방법에 대한 내용을 참조할 수 있습니다.

module 매개 변수

module=moduleName 매개 변수를 사용하면 지정된 인증 모듈을 통해 인증할 수 있습니다. 모든 인증 모듈은 먼저 사용자가 속한 영역에서 등록되고 핵심 인증 모듈에서 해당 영역의 인증 모듈 중 하나로 선택되어야 지정될 수 있습니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?module=Unix.

주 –

URL 매개 변수에서 사용되는 인증 모듈 이름은 대소문자를 구분합니다.

service 매개 변수

service=serviceName 매개 변수를 사용하면 사용자는 서비스의 구성된 인증 스키마를 통해 인증할 수 있습니다. 인증 구성 서비스를 사용하여 서비스마다 인증 스키마를 달리 구성할 수 있습니다. 예를 들어, 영역의 직원 디렉토리 응용 프로그램은 LDAP 인증 모듈만 필요한 반면 온라인 급여 응용 프로그램은 보다 안전한 인증서 인증 모듈을 사용하여 인증해야 합니다. 이러한 서비스마다 인증 스키마를 구성하고 이름을 지정할 수 있습니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?service=sv1.

주 –

인증 구성 서비스는 서비스 기반의 인증을 위한 스키마 정의에 사용됩니다.

arg 매개 변수

arg=newsession 매개 변수는 사용자의 현재 세션을 종료하고 새 세션을 시작하는 데 사용됩니다. 인증 서비스는 사용자의 기존 세션 토큰을 제거하고 요청 시마다 새 로그인을 수행합니다. 이 옵션은 일반적으로 익명 인증 모듈에서 사용됩니다. 사용자는 먼저 익명 세션으로 인증한 다음 등록이나 로그인 링크를 누릅니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?arg=newsession.

authlevel 매개 변수

authlevel=value 매개 변수는 인증 수준이 인증 서비스에게 지정된 인증 수준 값보다 크거나 같은 모듈을 호출하도록 명령합니다. 각 인증 모듈은 고정된 정수 인증 수준으로 정의됩니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?authlevel=1.

주 –

인증 수준은 각 모듈의 특정 프로필에 설정됩니다.

domain 매개 변수

이 매개 변수를 사용하면 지정된 도메인으로 식별된 영역에 로그인할 수 있습니다. 지정된 도메인은 영역 프로필의 도메인 이름 속성에 정의된 값과 일치해야 합니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com.

주 –

아직 지정된 도메인/영역의 구성원이 아닌 사용자가 org 매개 변수를 사용하여 인증하려고 하면 오류 메시지가 나타납니다. 그러나 다음 사항이 모두 해당되면 Directory Server에서 사용자 프로필을 동적으로 작성할 수 있습니다.

핵심 인증 서비스의 사용자 프로필 속성은 Dynamic 또는 Dynamic With User Alias 로 설정되어야 합니다.
사용자는 필수 모듈에 성공적으로 인증해야 합니다.
사용자가 아직 Directory Server에 프로필이 없습니다.

iPSPCookie 매개 변수

iPSPCookie=yes 매개 변수를 사용하면 영구 쿠키를 사용하여 로그인할 수 있습니다. 영구 쿠키는 브라우저 창을 닫은 후에도 계속 존재하는 쿠키를 말합니다. 이 매개 변수를 사용하기 위해서는 사용자가 로그인한 조직의 영구 쿠키가 핵심 인증 모듈에서 활성화되어 있어야 합니다. 사용자가 인증하고 브라우저를 닫은 후에는 다시 인증할 필요 없이 새 브라우저 세션으로 로그인할 수 있고 콘솔로 직접 이동합니다. 이러한 작업은 핵심 서비스에 지정된 영구 쿠키 최대 시간의 값이 경과할 때까지 가능합니다. 예를 들면 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN 매개 변수

이 매개 변수 옵션을 사용하면 URL 또는 HTML 형식으로 인증 자격 증명을 통과할 수 있습니다. IDTokenN=value 매개 변수를 사용하는 경우 인증 서비스 사용자 인터페이스에 액세스하지 않고도 인증할 수 있습니다. 이러한 프로세스를 0 페이지 로그인이라고 합니다. 0페이지 로그인은 하나의 로그인 페이지를 사용하는 인증 모듈에서만 작동합니다. IDToken0, IDToken1, ..., IDTokenN 값은 인증 모듈의 로그인 페이지에 있는 필드에 매핑됩니다. 예를 들어, LDAP 인증 모듈은 userID 정보에 IDToken1을 사용하고 비밀번호 정보에 IDToken2를 사용할 수 있습니다. 이 경우 LDAP 모듈 IDTokenN URL은 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/

Login?module=LDAP&IDToken1=userID&IDToken2=password

(LDAP가 기본 인증 모듈인 경우 module=LDAP를 생략할 수 있습니다.)

익명 인증의 경우 로그인 URL 매개 변수는 다음과 같습니다.

http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID.

주 –

이전 릴리스의 토큰 이름인 Login.Token0, Login.Token1, ..., Login.TokenN은 아직 지원되지만 향후 릴리스에서는 사용할 수 없게 됩니다. 새로 제공되는 IDTokenN 매개 변수를 사용하는 것이 좋습니다.

계정 잠금

인증 서비스는 사용자 인증이 n회 실패하면 사용자 인증을 잠그는 기능을 제공합니다. 이 기능은 기본적으로 꺼져 있지만 Access Manager 콘솔을 사용하여 활성화할 수 있습니다.

주 –

잘못된 비밀번호 예외가 발생하는 모듈만 계정 잠금 기능을 사용할 수 있습니다.

핵심 인증 서비스에는 다음을 포함하여 이 기능을 활성화/사용자 정의하는 속성이 들어 있습니다.

로그인 실패 잠금 모드. 계정 잠금을 활성화합니다.
로그인 실패 잠금 수 사용자가 잠기기 전에 인증을 시도할 수 있는 횟수를 정의합니다. 이 값은 사용자 아이디에 대해서만 적용됩니다. 동일한 사용자 아이디가 지정된 횟수만큼 실패하면 그 사용자 아이디는 잠겨집니다.
로그인 실패 잠금 간격 사용자 잠금이 적용되기 전 얼마 동안 로그인 실패 잠금 수의 값이 완료되어야 하는지 분 단위로 정의합니다.
잠금 알림을 보낼 전자 메일 주소 사용자 잠금 알림을 보낼 전자 메일 주소를 지정합니다.
N회 실패 후 사용자에게 경고. 몇 차례 인증이 실패하면 경고 메시지가 사용자에게 표시되는지 지정합니다. 관리자는 사용자에게 잠금이 임박했음을 경고한 이후의 추가 로그인 시도를 설정할 수 있습니다.
로그인 실패 잠금 기간. 잠금 후 얼마나 대기한 후 다시 인증을 시도할 수 있는지 분 단위로 정의합니다.
잠금 속성 이름. 물리적 잠금에 대해 사용자 프로필 중 어떤 LDAP 속성이 inactive로 설정될 것인지 정의합니다.
잠금 속성 값. 잠금 속성 이름에 지정된 LDAP 속성 중 어떤 속성이inactive 또는 active로 설정될 것인지 정의합니다.

계정 잠금이 발생하면 관리자에게 전자 메일 알림이 전송됩니다. (계정 잠금 활동도 기록).

주 –

Microsoft® Windows 2000 운영 체제에서의 이 기능 사용에 대한 자세한 내용은 부록 A, “AMConfig.properties File”에서 “Simple Mail Transfer Protocol(SMTP)”을 참조하십시오.

Access Manager에서는 다음 절에서 정의하는물리적 잠금과 메모리 잠금의 두 가지 계정 잠금 유형을 지원합니다.

물리적 잠금

이는 Access Manager에 대한 기본 잠금 동작입니다. 사용자 프로필의 LDAP 속성 상태를 inactive로 변경하면 이 잠금이 초기화됩니다. Lockout Attribute Name은 잠금 목적에 따라 사용되는 LDAP 속성을 정의합니다.

주 –

별칭 사용자는 LDAP 프로필에서 사용자 별칭 목록 속성(iplanet-am-user-alias-list in amUser.xml)을 구성하는 방법으로 기존의 LDAP 사용자 프로필에 매핑된 사용자입니다. 별칭 사용자는 핵심 인증 서비스의 별칭 검색 속성 이름 필드에 iplanet-am-user-alias-list를 추가함으로써 검증할 수 있습니다. 즉 별칭 사용자가 잠긴 경우 해당 사용자가 별칭 처리된 실제 LDAP 프로필도 잠기게 됩니다. 이는 LDAP 및 구성원이 아닌 인증 모듈을 사용하는 물리적 잠금에만 적용됩니다.

메모리 잠금

메모리 잠금은 Login Failure Lockout Duration 속성을 0보다 큰 값으로 변경하는 방법으로 사용할 수 있습니다. 그러면 사용자 계정은 지정된 분 수 동안 메모리에서 잠깁니다. 시간이 모두 경과한 후에는 계정의 잠금이 해제됩니다. 메모리 잠금 기능을 사용할 때는 몇 가지 사항에 특별히 주의해야 합니다.

Access Manager가 다시 시작하는 경우에는 메모리에서 잠긴 모든 계정이 잠금 해제됩니다.
사용자 계정이 메모리에서 잠겨있고 관리자가 계정 잠금 체계를 물리적 잠금으로 변경한 경우(잠금 기간을 다시 0으로 설정) 사용자 계정이 메모리에서 잠금 해제되고 잠금 수가 재설정됩니다.
메모리 잠금 후 LDAP 및 구성원을 제외한 인증 모듈을 사용할 때 사용자가 정확한 비밀번호로 로그인을 시도할 경우 사용자가 활성 상태가 아닙니다. 오류 대신이 조직에 사용자의 프로필이 없습니다. 오류가반환됩니다.

주 –

사용자 프로필에 실패 URL 속성이 설정된 경우 잠금 경고 메시지나 계정이 잠겨 있음을 나타내는 메시지가 표시되지 않고 정의된 URL로 사용자가 리디렉션됩니다.

인증 서비스 페일오버

인증 서비스 페일오버는 하드웨어나 소프트웨어 문제 때문에 주 서버에 장애가 발생하거나 서버가 일시적으로 다운될 경우 자동으로 인증 요청을 보조 서버로 리디렉션합니다.

인증 서비스를 사용할 수 있는 Access Manager 인스턴스에서 인증 컨텍스트가 먼저 생성되어야 합니다. 이 Access Manager 인스턴스를 사용할 수 없는 경우 인증 페일오버를 통해 다른 Access Manager 인스턴스에서 인증 컨텍스트를 생성할 수 있습니다. 인증 컨텍스트는 다음 순서로 서버 가용성을 확인합니다.

인증 서비스 URL이 AuthContext API로 전달됩니다. 예를 들면 다음과 같습니다.
AuthContext(orgName, url)
이 API가 사용될 경우 URL에 의해 참조되는 서버만 사용합니다. 해당 서버에서 인증 서비스를 사용할 수 있는 경우라도 페일오버는 이루어지지 않습니다.
인증 컨텍스트는 AMConfig.properties 파일의 com.iplanet.am.server* 속성에 정의된 서버를 검사합니다.
단계 2가 실패할 경우 인증 컨텍스트는 이름 지정 서비스를 사용할 수 있는 서버에서 플랫폼 목록을 조회합니다. 이 플랫폼 목록은 하나의 Directory Server 인스턴스를 공유하는 다수의 Access Manager 인스턴스(일반적으로 페일오버 목적)가 설치될 때 자동으로 작성됩니다.

예를 들어, 플랫폼 목록에 Server1, Server2 및 Server3을 위한 URL이 포함되면 인증 컨텍스트는 그 중 하나에서 인증이 성공할 때까지 Server1, Server2, Server3을 차례로 순환합니다.

플랫폼 목록은 이름 지정 서비스의 가용성에 따라 다르므로 항상 동일한 서버에서 얻어질 수 있는 것은 아닙니다. 또한 이름 지정 서비스 페일오버가 먼저 일어날 수도 있습니다. AMConfing.properties의 com.iplanet.am.naming.url property에 다수의 이름 지정 서비스 URL이 지정됩니다. 사용할 수 있는 첫 번째 이름 지정 서비스 URL은 인증 페일오버가 이루어지는 서버 목록이 포함된 서버를 식별하는 데 사용됩니다.

정규화된 도메인 이름(FQDN) 매핑

정규화된 도메인 이름(FQDN) 매핑을 사용하면 사용자가 잘못된 URL을 입력하더라도(예: 보호된 자원에 액세스할 때 부분 호스트 이름이나 IP 주소 지정) 인증 서비스에서 수정할 수 있습니다. FQDN 매핑은 AMConfig.properties 파일의 com.sun.identity.server.fqdnMap 속성을 수정하여 활성화합니다. 이 등록 정보를 지정하는 형식은 다음과 같습니다.

com.sun.identity.server.fqdnMap[invalid-name ]=valid-name

invalid-name 값은 사용자가 잘못 입력한 FQDN 호스트 이름이 되고 valid-name은 필터에서 사용자를 리디렉션할 실제 호스트 이름이 됩니다. 명시된 요구 사항의 범위 내에서 매핑 수를 지정할 수 있습니다(코드 예 1-1에서 설명). 이 등록 정보를 설정하지 않으면 사용자는 AMConfig.properties 파일에서도 확인 가능한 com.iplanet.am.server.host= server_name 등록 정보에 구성된 기본 서버 이름으로 보내집니다.

예 7–1 `AMConfig.properties`의 FQDN 매핑 속성

com.sun.identity.server.fqdnMap[isserver]=isserver.mydomain.com

com.sun.identity.server.fqdnMap[isserver.mydomain]=isserver.mydomain.com

com.sun.identity.server.fqdnMap[

            IP address]=isserver.mydomain.com

FQDN 매핑의 용도

이 등록 정보는 서버에 호스트된 응용 프로그램이 둘 이상의 호스트 이름으로 액세스 가능할 경우 둘 이상의 호스트 이름에 대해 하나의 매핑을 작성하는 데 사용할 수 있습니다. 또한 Access Manager에서 특정 URL에 대해 수정 조치를 취하지 않게 할 때에도 사용할 수 있습니다. 예를 들어, IP 주소를 사용하여 응용 프로그램에 액세스하는 사용자에게 리디렉션이 필요하지 않다면 이 기능은 다음과 같이 매핑 항목을 지정하여 구현할 수 있습니다.

com.sun.identity.server.fqdnMap[IP address ]=IP address.

주 –

매핑이 둘 이상 정의되어 있을 때는 잘못된 FQDN 이름으로 값이 겹치지 않아야 합니다. 응용 프로그램 액세스가 불가능해질 수도 있습니다.

영구 쿠키

영구 쿠키는 웹 브라우저를 닫은 후에도 계속 존재하는 쿠키로서 사용자가 이 영구 쿠키를 사용하면 다시 인증할 필요 없이 새 브라우저 세션으로 로그인할 수 있습니다. 이 쿠키의 이름은 AMConfig.properties의 com.iplanet.am.pcookie.name 등록 정보에서 정의되며 그 기본값은 DProPCookie입니다. 쿠키 값은 3DES 암호화된 문자열로서 사용자 DN, 영역 이름, 인증 모듈 이름, 최대 세션 시간, 유휴 시간 및 캐시 시간으로 구성됩니다.

영구 쿠키를 사용하려면

단계

핵심 인증 모듈에서 Persistent Cookie Mode를 켭니다.

핵심 인증 모듈에서 Persistent Cookie Maximum Time 속성에 대한 시간 값을 구성합니다.

값이 yes인 iPSPCookie 매개 변수를 사용자 인터페이스 로그인 URL에 추가합니다.

사용자가 이 URL을 사용하여 인증하면 브라우저를 닫아도 다시 인증할 필요 없이 새 브라우저 창을 열 수 있고 콘솔로 리디렉션하게 됩니다. 영구 쿠키는 단계 2에서 정의한 시간이 경과할 때까지 계속 적용됩니다.

영구 쿠키 모드는 다음 인증 SPI 방법을 사용하여 켤 수 있습니다.

AMLoginModule.setPersistentCookieOn().

레거시 모드에서 다중 LDAP 인증 모듈 구성

페일오버의 한 형식으로 또는 Access Manager 콘솔에 값 필드가 하나만 제공되는 경우 하나의 속성에 여러 값을 구성하기 위해 관리자는 하나의 영역에 여러 LDAP 인증 모듈 구성을 정의할 수 있습니다. 이러한 추가 구성은 콘솔에 표시되지 않더라도 사용자의 인증 요청에 대한 초기 검색이 없는 경우에 기본 구성과 함께 사용됩니다. 예를 들어, 한 영역에서 두 가지 서로 다른 도메인에 인증용 LDAP 서버를 통한 검색을 정의하거나 한 도메인에 사용자 이름 지정 속성을 여러 개 구성할 수도 있습니다. 후자는 콘솔에 텍스트 필드를 하나만 갖는 경우이며, 기본 검색 기준을 사용하여 사용자를 찾지 못하면 LDAP 모듈에서 2차 범위를 사용하여 검색하게 됩니다. 다음은 추가 LDAP 구성을 구성하는 단계입니다.

추가 LDAP 구성을 추가하려면

단계

2차(또는 3차) LDAP 인증 구성에 필요한 새 값과 전체 속성 세트를 포함하여 XML 파일을 작성합니다.

etc/opt/SUNWam/config/xml에 있는 amAuthLDAP.xml을 확인하면서 사용 가능한 속성을 참조할 수 있습니다. 그러나 이 단계에서 만든 XML 파일은 amAuthLDAP.xml과 달리 amadmin.dtd 구조를 기반으로 합니다. 이 파일에 대해 속성을 하나 또는 전부 정의할 수 있습니다. 코드 예 1-2는 LDAP 인증 구성에 사용할 수 있는 모든 속성 값이 포함된 하위 구성 파일의 예입니다.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!--

  Copyright (c) 2002 Sun Microsystems, Inc. All rights reserved.

  Use is subject to license terms.

-->

<!DOCTYPE Requests

    PUBLIC "-//iPlanet//Sun ONE Access Manager 6.0 Admin CLI DTD//EN"

    "jar://com/iplanet/am/admin/cli/amAdmin.dtd"

>

<!--

  Before adding subConfiguration load the schema with

GlobalConfiguration defined and replace corresponding

 serviceName and subConfigID in this sample file OR load

 serviceConfigurationRequests.xml before loading this sample

-->

<Requests>

<realmRequests DN="dc=iplanet,dc=com">

    <AddSubConfiguration subConfigName = "ssc"

        subConfigId = "serverconfig"

        priority = "0" serviceName="iPlanetAMAuthLDAPService">



              <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-server"/>

            <Value>vbrao.red.iplanet.com:389</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-base-dn"/>

            <Value>dc=iplanet,dc=com</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="planet-am-auth-ldap-bind-dn"/>

            <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>

            <Value>

                  plain text password</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>

            <Value>uid</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>

            <Value>uid</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-search-scope"/>

            <Value>SUBTREE</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>

            <Value>false</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>

            <Value>true</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-auth-level"/>

            <Value>0</Value>

        </AttributeValuePair>

        <AttributeValuePair>

            <Attribute name="iplanet-am-auth-ldap-server-check"/>

            <Value>15</Value>

        </AttributeValuePair>



    </AddSubConfiguration>



</realmRequests>

</Requests>

단계 1에서 작성한 XML 파일에서 iplanet-am-auth-ldap-bind-passwd의 값으로서 일반 텍스트 비밀번호를 복사합니다.

이 속성 값은 코드 예에 굵은 글씨로 표시되어 있습니다.

amadmin 명령줄 도구를 사용하여 XML 파일을 로드합니다.
./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.
이 2차 LDAP 구성은 콘솔에서 보거나 수정할 수 없습니다.

정보 –
다중 LDAP 구성에 사용할 수 있는 예제가 있습니다. /AccessManager-base /SUNWam/samples/admin/cli/bulk-ops/에서 serviceAddMultipleLDAPConfigurationRequests .xml 명령줄 템플리트를 참조하십시오. /AccesManager-base /SUNWam/samples/admin/cli/의 Readme.html에서 지침을 참조할 수 있습니다.

세션 업그레이드

인증 서비스를 사용하면 한 영역에서 동일한 사용자가 수행한 2차 인증 성공을 기반으로 유효한 세션 토큰을 업그레이드할 수 있습니다. 유효한 세션 토큰을 가진 사용자가 현재 영역에서 보호한 자원에 인증을 시도하고 이 2차 인증 요청이 성공하면 해당 세션은 새 인증을 기반으로 한 새 등록 정보로 업데이트됩니다. 인증에 실패한 경우 사용자의 현재 세션이 업그레이드되지 않고 반환됩니다. 유효한 세션을 가진 사용자가 다른 영역에서 보호한 자원에 인증을 시도하는 경우 새 영역에 인증할 것인지 묻는 메시지를 받게 됩니다. 이때 사용자는 현재 세션을 유지하거나 새 영역에 인증을 시도할 수도 있습니다. 인증이 성공하면 이전 세션이 삭제되고 새 세션이 작성됩니다.

세션 업그레이드 중 로그인 페이지가 시간 초과되면 원래의 성공 URL로 리디렉션됩니다. 시간 초과 값은 다음에 따라 결정됩니다.

각 모듈에 설정한 페이지 시간 초과 값(기본값: 1분)
AMConfig.properties의 com.iplanet.am.invalidMaxSessionTime 등록 정보(기본값: 10분)
iplanet-am-max-session-time(기본값: 120분)

com.iplanet.am.invalidMaxSessionTimeout 값 및 iplanet-am-max-session-time 값은 페이지 시간 초과 값보다 커야 합니다. 그렇지 않으면 세션 업그레이드 중 유효한 세션 정보가 손실되고 이전의 성공 URL에 대한 리디렉션이 실패하게 됩니다.

플러그 인 인터페이스 검증

관리자는 영역에 적합한 사용자 이름 또는 비밀번호 검증 논리를 작성하고 이를 인증 서비스에 플러그 인할 수 있습니다. (이 기능은 LDAP 및 구성원 인증 모듈에서만 지원됩니다.)사용자를 인증하거나 비밀번호를 변경하기 전에 Access Manager에서는 이 플러그 인을 호출합니다. 검증이 성공하면 인증이 계속되지만, 실패하면 인증 실패 페이지가 나타납니다. 이 플러그 인은 서비스 관리 SDK의 일부인 com.iplanet.am.sdk.AMUserPasswordValidation 클래스를 확장합니다. 이 SDK에 대한 내용은 Access Manager Javadocs의 com.iplanet.am.sdk 패키지를 참조하십시오.

검증 플러그 인을 작성 및 구성하려면

단계

새 플러그 인 클래스는 com.iplanet.am.sdk. AMUserPasswordValidation 클래스를 확장하고 validateUserID() 및 validatePassword() 메소드를 구현합니다. AMException은 검증이 실패할 때 나타납니다.

플러그 인 클래스를 컴파일하고 원하는 위치에 .class 파일을 놓습니다. 런타임 동안 Access Manager에서 액세스할 수 있도록 클래스 경로를 업데이트합니다.

Access Manager 콘솔에 최상위 관리자로 로그인합니다. 서비스 관리 탭을 누르고 관리 서비스에 대한 속성을 확인하십시오. UserID & Password Validation Plugin Class 필드에 플러그 인 클래스의 이름(패키지 이름 포함)을 입력합니다.

로그아웃했다가 다시 로그인합니다.

JAAS 공유 상태

JAAS 공유 상태는 인증 모듈들이 사용자 아이디와 비밀번호를 공유하게 합니다. 다음 인증 모듈에 옵션이 정의되어 있습니다.

영역(또는 조직)
사용자
서비스
역할

실패할 때 모듈에는 필수 자격 증명에 대한 메시지가 나타납니다. 인증이 실패하고 나면 모듈의 실행이 중지되거나 로그아웃 공유 상태가 지워집니다.

JAAS 공유 상태 활성화

JAAS 공유 상태를 구성하려면 다음을 수행합니다.

iplanet-am-auth-shared-state-enabled 옵션을 사용합니다.
공유 상태 옵션은 다음의 경우에 사용됩니다.iplanet-am-auth-shared-state-enabled=true
이 옵션의 기본값은 true입니다.
이 변수는 인증 체이닝 구성의 옵션 열에서 지정됩니다.

실패하면 인증 모듈에는 필수 자격 증명 프롬프트가 JAAS 사양에 제시된 tryFirstPass 옵션 동작에 따라 나타납니다.

JAAS 공유 상태 저장소 옵션

JAAS 공유 상태 저장소 옵션을 구성하려면 다음을 수행합니다.

iplanet-amauth-store-shared-state-enabled 옵션을 사용합니다.
저장소 공유 상태 옵션은 다음과 같은 경우에 사용됩니다.iplanet-am-auth-store-shared-state-enabled=true
이 옵션의 기본값은 false입니다.
이 변수는 인증 체이닝 구성의 옵션 열에서 지정됩니다.

완결, 중단 또는 로그아웃한 후에는 공유 상태가 지워집니다.

8장 정책 관리

이 장에서는 Sun Javaa™ System Access Manager의 정책 관리 기능에 대해 설명합니다. Access Manager의 정책 관리 기능을 사용하면 최상위 수준 관리자 또는 최상위 수준 정책 관리자가 모든 영역에서 사용할 수 있는 특정 서비스의 정책을 보고, 만들고, 삭제하고, 수정할 수 있습니다. 또한 영역이나 하위 영역 관리자 또는 정책 관리자가 영역 수준에서 정책을 보고, 만들고, 삭제하고, 수정할 수 있는 방법을 제공합니다.

이 장은 다음 내용으로 구성되어 있습니다.

개요

정책은 조직의 보호 대상 자원에 대한 액세스 권한을 지정하는 규칙을 정의합니다. 보호하고 관리하고 모니터링해야 하는 자원, 응용 프로그램 및 서비스가 있습니다. 정책은 주어진 자원에 대한 작업을 사용자가 언제, 어떤 방법으로 수행할 수 있는지 정의하여 이러한 자원에 대한 액세스 권한과 용도를 제어합니다. 정책은 특정 기본에 대해 자원을 정의합니다.

주 –

기본은 아이디를 가질 수 있는 개인, 회사, 역할 또는 그룹이 될 수 있습니다. 자세한 내용은 Java™ 2 Platform Standard Edition Javadoc을 참조하십시오.

단일 정책은 이진 또는 비이진 결정 중 하나를 정의할 수 있습니다. 이진 결정은 yes/no, true/ false 또는 allow/deny입니다. 비이진 결정은 속성의 값을 나타냅니다. 예를 들어, 메일 서비스에는 각 사용자에 대한 최대 저장 값이 설정된 mailboxQuota 속성이 포함될 수 있습니다. 일반적으로 정책은 한 기본이 어떤 자원에 대해 어떤 조건 하에서 어떤 작업을 수행할 수 있는지 정의하도록 구성됩니다.

정책 관리 기능

정책 관리 기능은 정책을 만들고 관리하기 위한 정책 서비스를 제공합니다. 정책 서비스는 관리자가 Access Manager 배포 내에서 자원을 보호하기 위해 권한을 정의, 수정, 부여, 철회 및 삭제할 수 있도록 합니다. 일반적으로 정책 서비스에는 데이터 저장소, 생성을 허용하는 인터페이스 라이브러리, 정책 관리 및 평가, 정책 집행자 또는 정책 에이전트가 포함됩니다. 기본적으로 Access Manager는 데이터 저장용으로 Sun Java Enterprise System Directory Server를 사용하며 정책 평가 및 정책 서비스 사용자 정의를 위해 Java 및 C API를 제공합니다(자세한 내용은 Sun Java System Access Manager 7 2005Q4 Developer’s Guide를 참조하십시오). 또한 관리자가 Access Manager 콘솔을 사용하여 정책을 관리할 수 있게 해줍니다. Access Manager는 다운로드할 수 있는 정책 에이전트를 사용하여 정책을 집행하는 정책 가능 서비스인 URL 정책 에이전트 서비스를 제공합니다.

URL 정책 에이전트 서비스

Access Manager를 설치하면 HTTP URL 보호를 위한 정책을 정의하는 URL 정책 에이전트 서비스가 제공됩니다. 이 서비스를 사용하여 관리자는 정책 집행자 또는 정책 에이전트를 통해 정책을 만들고 관리할 수 있습니다.

정책 에이전트

정책 에이전트는 회사의 자원이 저장된 서버에 대한 정책 적용 지점(PEP)입니다. 정책 에이전트는 웹 서버에 Access Manager와 별도로 설치되며 사용자가 보호를 받는 웹 서버에 있는 웹 자원에 대한 요청을 보낼 때 추가 인증 단계 역할을 합니다. 이 인증 단계는 자원에서 수행하는 사용자 인증 요청에 추가로 이루어집니다. 에이전트는 웹 서버를 보호하고 자원은 인증 플러그 인에 의해 보호됩니다.

예를 들어, 원격 설치된 Access Manager에 의해 보호되는 인적 자원 웹 서버에는 에이전트가 설치되어 있을 수 있습니다. 이 에이전트는 제대로된 정책 없이 기밀 정보인 급여 정보나 기타 민감한 데이터를 보지 못하도록 방지합니다. 정책은 Access Manager 관리자가 정의하여 Access Manager 배포 내에 저장하며 정책 에이전트가 원격 웹 서버의 내용에 대한 사용자 액세스를 허용 또는 거부하는 데 사용됩니다.

최신 Access Manager 정책 에이전트는 Sun Microsystems 다운로드 센터에서 다운로드할 수 있습니다.

정책 에이전트 설치 및 관리에 대한 자세한 내용은 Sun Java System Access Manager Policy Agent 2.2 User’s Guide를 참조하십시오.

주 –

정책은 특별한 순서로 평가되지 않습니다. 그러나 정책을 평가할 때 한 가지 작업 값이 거부로 평가되는 경우 정책 구성 서비스에서 거부 결정에 대한 평가 계속 속성이 활성화되지 않으면 후속 정책은 평가되지 않습니다.

Access Manager 정책 에이전트는 웹 URL(http://... 또는 https//...)에서만 결정을 실행합니다. 그러나 Java 및 C 정책 평가 API를 사용하여 다른 자원에서 정책을 실행하는 에이전트를 작성할 수 있습니다.

또한 정책 구성 서비스의 자원 비교기 속성도 기본 구성에서 다음과 같은 구성으로 변경해야 합니다.

serviceType=Name_of_LDAPService |class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*

|delimiter=,|caseSensitive=false

또는 LDAPResourceName과 같은 구현을 제공하여 com.sun.identity.policy.interfaces.ResourceName을 구현하고 자원 비교기를 구성하는 방법도 사용할 수 있습니다.

정책 에이전트 프로세스

보호 대상 웹 자원을 위한 프로세스는 정책 에이전트에 의해 보호를 받는 서버에 상주하는 URL을 웹 브라우저에서 요청할 때 시작됩니다. 서버의 설치된 정책 에이전트는 요청을 인터셉트하여 기존 인증 자격 증명(세션 토큰)을 확인합니다.

에이전트가 요청을 인터셉트하고 기존 세션 토큰을 확인하면 다음 프로세스가 이어집니다.

세션 토큰이 유효하면 사용자에게 권한이 부여 또는 거부됩니다. 유효한 토큰이 아닐 경우 사용자는 다음과 같은 단계를 거쳐 인증 서비스로 리디렉션됩니다.

에이전트가 기존 세션 토큰이 없는 요청을 인터셉트했다면 다른 인증 방법을 사용하여 자원을 보호하더라도 사용자를 로그인 페이지로 리디렉션합니다.
사용자의 자격 증명이 인증되면 에이전트가 Access Manager의 내부 서비스 연결에 사용되는 URL을 정의하는 이름 지정 서비스에 요청을 발행합니다.
자원이 에이전트에서 구성된 비강제 목록과 일치하면 액세스가 허용됩니다.
이름 지정 서비스는 정책 서비스에 대한 로케이터, 세션 서비스 및 로깅 서비스를 반환합니다.
에이전트는 사용자에게 적용할 수 있는 정책 결정을 얻기 위해 정책 서비스에 요청을 보냅니다.
액세스 대상 자원에 대한 정책 결정에 따라 사용자는 액세스 권한이 부여되거나 거부됩니다. 정책 결정에 대한 조언에 다른 인증 수준 또는 방법이 제시되면 에이전트는 모든 검색 조건이 확인될 때까지 요청을 인증 서비스로 다시 보냅니다.

정책 유형

Access Manager를 사용하여 다음 두 가지 유형의 정책을 구성할 수 있습니다.

일반 정책

Access Manager에서 액세스 권한을 정의하는 정책을 일반 정책이라고 합니다. 일반 정책은 규칙 , 주제, 조건 및 응답 공급자로 구성됩니다.

규칙

하나의 규칙에는 하나의 자원, 하나 이상의 작업 및 하나의 값이 포함됩니다. 각 작업에는 하나 이상의 값이 있을 수 있습니다.

자원은 인적 자원 서비스를 사용하여 액세스되는 HTML 페이지 또는 사용자의 급여 정보 등 보호 대상인 특정 객체를 정의합니다.
작업은 자원에 대해 수행될 수 있는 작업의 이름입니다. 예를 들어, 웹 서버 작업으로는 POST 또는 GET 등이 있습니다. 인적 자원 서비스에는 예를 들어 집 전화 번호 변경 작업 등이 허용될 수 있습니다.
값은 작업에 대한 권한(예: 허용 또는 거부)을 정의합니다.

주 –

일부 서비스에 대해 자원 없이 작업을 정의할 수 있습니다.

주제

주제는 정책이 영향을 주는 사용자 또는 사용자 집합(예: 그룹 또는 특정 역할 소유자들)을 정의합니다. 주제는 정책에 지정됩니다. 사용자가 적어도 정책의 한 주제의 구성원일 경우에만 정책이 적용되는 것이 일반적인 규칙입니다. 기본 주제는 다음과 같습니다.

AM Identity 주제

사용자가 영역 주제 탭에서 만들고 관리하는 Identity를 해당 주제의 값으로 추가할 수 있습니다.

Access Manager 역할

LDAP 역할을 이 주제의 값으로 추가할 수 있습니다. LDAP 역할은 Directory Server 역할 기능을 사용하는 임의의 역할 정의입니다. 이러한 역할은 Directory Server 역할 정의에 의해 위임되는 객체 클래스를 가집니다. 정책 구성 서비스에서 LDAP 역할 검색 필터를 수정하여 범위를 좁히고 성능을 향상시킬 수 있습니다.

인증된 사용자

유효한 SSO 토큰을 가진 사용자가 이 주제의 구성원입니다. 인증된 사용자는 정책이 정의된 조직과 다른 조직에 인증한 경우에도 모두 이 주제의 구성원이 됩니다. 이는 자원 소유자가 관리되는 자원에 대한 액세스 권한을 다른 조직의 사용자에게 제공하는 경우에 유용합니다.

LDAP 그룹

LDAP 그룹의 구성원은 이 주제의 값으로 추가할 수 있습니다.

LDAP 역할

LDAP 사용자

LDAP 사용자를 이 주제의 값으로 추가할 수 있습니다.

조직

조직의 구성원은 이 주제의 구성원입니다.

웹 서비스 클라이언트

유효한 값은 로컬 JKS 키 저장소에 있는 신뢰할 수 있는 인증서(신뢰할 수 있는 WSC의 인증서에 해당)의 DN입니다. 이 주제는 리버티 웹 서비스 프레임워크에 대해 종속성을 가지며 리버티 서비스 공급자가 WSC를 인증하기 위해서만 사용해야 합니다. SSO 토큰에 포함된 기본의 DN이 이 주제의 선택된 임의 값과 일치할 경우 SSO 토큰으로 식별된 웹 서비스 클라이언트(WSC)는 이 주제의 구성원입니다.

이 주제를 정책에 추가하기 전에 키 저장소를 만들어야 합니다. 키 저장소 설정에 대한 내용은 다음 사이트를 참조하십시오.

AccessManager-base /SUNWam/samples/saml/xmlsig/keytool.html

Access Manager 역할 대 LDAP 역할

Access Manager 역할은 Access Manager를 사용하여 작성됩니다. 이러한 역할은 Access Manager에 의해 위임되는 객체 클래스를 가집니다. LDAP 역할은 Directory Server 역할 기능을 사용하는 역할 정의입니다. 이러한 역할은 Directory Server 역할 정의에 의해 위임되는 객체 클래스를 가집니다. 모든 Access Manager 역할은 Directory Server 역할로 사용될 수 있습니다. 그러나 모든 Directory Server 역할이 Access Manager 역할은 아닙니다. 정책 구성 서비스를 구성하여 기존 디렉토리에서 LDAP 역할을 활용할 수 있습니다. Access Manager 역할은 Access Manager 정책 서비스를 호스트하는 방법으로만 액세스할 수 있습니다. 정책 구성 서비스에서 LDAP 역할 검색 필터를 수정하여 범위를 좁히고 성능을 향상시킬 수 있습니다.

중첩된 역할

중첩된 역할은 정책 정의의 주제에서 LDAP 역할로 올바르게 평가될 수 있습니다.

조건

조건을 사용하면 정책에서 제약 조건을 정의할 수 있습니다. 예를 들어, 급여 응용 프로그램에 대한 정책을 정의할 경우 지정된 시간 동안만 응용 프로그램에 대한 액세스를 제한하는 조건을 현재 작업에서 정의할 수 있습니다. 또는 주어진 IP 주소 집합이나 회사 인트라넷에서 요청을 보낸 경우에만 작업을 허가하는 조건을 정의할 수 있습니다.

조건을 추가로 사용하여 동일한 도메인에서 다른 URL에 대한 다른 정책을 구성할 수 있습니다. 예를 들어 http://org.example.com/hr/*jsp는 org.example.net에서 오전 9시부터 오후 5시까지만 액세스할 수 있고 http://org.example.com/finance/*.jsp는 org.example2.net에서 오전 5시부터 오후 11시까지 액세스할 수 있습니다. 이렇게 하려면 IP 조건과 함께 시간 조건을 사용합니다. 규칙 자원을 http://org.example.com/hr/*.jsp로 지정할 경우 http://org.example.com/hr 및 하위 디렉토리에 있는 모든 JSP 정책이 적용됩니다.

주 –

용어 참조, 규칙, 자원, 주제, 조건, 작업 및 값은 policy.dtd의 Referral, Rule, ResourceName, Subject, Condition, Attribute 및 Value 요소에 해당합니다.

추가할 수 있는 기본 조건은 다음과 같습니다.

인증 수준

사용자의 인증 수준이 조건에 설정된 인증 수준보다 높거나 같은 경우에 정책이 적용됩니다.

이 속성은 인증의 트러스트 수준을 나타냅니다.

인증 수준 조건은 해당 영역의 등록된 인증 모듈 수준이 아닌 다른 수준을 지정하는 데 사용됩니다. 다른 영역에서 인증된 사용자에게 정책을 적용할 때 유용합니다.

LE 인증은 사용자의 인증 수준이 조건에 설정된 인증 수준보다 높거나 같은 경우에 정책을 적용합니다. 인증 수준 조건은 해당 영역의 등록된 인증 모듈 수준이 아닌 다른 수준을 지정하는 데 사용됩니다. 다른 영역에서 인증된 사용자에게 정책을 적용할 때 유용합니다.

인증 방식

풀 다운 메뉴에서 조건에 대한 인증 방식을 선택합니다. 이러한 인증 방식은 영역에서 핵심 인증 서비스에 정의된 인증 모듈입니다.

IP 주소

IP 주소의 범위를 기반으로 조건을 설정합니다. 정의할 수 있는 필드는 다음과 같습니다.

보내는/받는 IP 주소 — IP 주소 범위를 지정합니다.
DNS 이름 — DNS 이름을 지정합니다. 이 필드는 정규화된 호스트 이름이나 다음 형식의 문자열이 될 수 있습니다.

domainname

*.domainname

세션

사용자 세션 데이터에 따라 조건을 설정합니다. 수정할 수 있는 필드는 다음과 같습니다.

최대 세션 시간 — 세션이 시작될 때부터 정책을 적용할 수 있는 최대 기간을 지정합니다.
세션 종료 — 선택된 경우 세션 시간이 최대 세션 시간 필드에 정의된 최대 허용 시간을 초과하면 사용자 세션이 종료됩니다.

이 조건으로 민감한 자원을 보호하여 인증 이후 제한된 시간 동안만 자원을 사용할 수 있도록 합니다.

세션 등록 정보

사용자의 Access Manager 세션에 설정된 등록 정보 값에 따라 정책을 요청에 적용할 수 있는지 여부를 결정합니다. 정책 평가 중 조건에 정의된 모든 등록 정보 값이 사용자의 세션에 있는 경우에만 true를 반환합니다. 조건에 여러 값으로 정의된 등록 정보의 경우 조건의 등록 정보에 대해 나열된 값이 토큰에 하나 이상 있으면 충분합니다. 예를 들어 이 조건을 사용하여 외부 저장소의 속성에 따라 정책을 적용할 수 있습니다. 인증 사후 플러그인은 외부 속성에 따라 세션 등록 정보를 설정할 수 있습니다.

시간

시간 제약 조건에 따라 조건을 설정합니다. 필드는 다음과 같습니다.

시작/끝 날짜 — 날짜 범위를 지정합니다.
시간 — 하루 중 시간의 범위를 지정합니다.
요일 — 요일의 범위를 지정합니다.
시간대 — 표준 또는 사용자 정의 표준 시간대를 지정합니다. 사용자 정의 표준 시간대는 Java에서 구성한 표준 시간대 아이디(예: PST)만 될 수 있습니다. 지정된 값이 없을 경우 기본값은 Access Manager JVM에 설정된 표준 시간대입니다.

응답 공급자

응답 공급자는 정책 기반 응답 속성을 제공하는 플러그인입니다. 응답 공급자 속성은 정책 결정과 함께 PEP로 전송됩니다. Access Manager에는 하나의 구현인 IDResponseProvider가 포함되어 있습니다. 사용자 정의 응답 공급자는 이 버전의 Access Manager에서 지원되지 않습니다. 에이전트, PEP는 보통 이러한 응답 속성을 헤더로 응용 프로그램에 전달합니다. 응용 프로그램은 일반적으로 이러한 속성을 사용하여 포털 페이지와 같은 응용 프로그램 페이지를 사용자 설정합니다.

정책 권고

조건에 따라 결정한 대로 정책을 적용할 수 없을 때는 그 조건에서 해당 정책을 요청에 적용할 수 없는 이유를 나타내는 권고 메시지를 만듭니다. 이러한 권고 메시지는 정책 적용 지점에 대한 정책 결정에 전달됩니다. 정책 적용 지점은 이 권고를 검색하고 더 높은 수준으로 인증하는 인증 메커니즘으로 사용자를 리디렉션하는 등의 적당한 조치를 취하게 됩니다. 적합한 조치가 취해진 후 정책이 적용 가능하게 되면 사용자에게 더 높은 수준의 인증에 관한 프롬프트가 나타나 자원에 액세스할 수 있게 됩니다.

자세한 내용은 다음 클래스를 참조하십시오.

com.sun.identity.policy.ConditionDecision.getAdvices()

해당 조건이 충족되지 않으면 AuthLevelCondiiton 및 AuthSchemeCondition 에서 권고를 제공합니다.

AuthLevelCondition 권고는 다음 키와 관련되어 있습니다.

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition 권고는 다음 키와 관련되어 있습니다.

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

사용자 정의한 조건도 권고를 만들 수 있습니다. 그러나 Access Manager 정책 에이전트는 인증 수준 권고와 인증 방식 권고에만 응답합니다. 사용자 정의 에이전트를 작성하고 기존 Access Manager 에이전트를 확장하여 더 많은 권고를 이해하고 응답할 수 있습니다. 자세한 내용은 Sun Java System Access Manager Policy Agent 2.2 User’s Guide를 참조하십시오.

참조 정책

관리자는 한 영역의 정책 정의와 결정을 다른 영역에 위임해야 할 수 있습니다. 또는 자원에 대한 정책 결정을 다른 정책 제품에 위임할 수 있습니다. 참조 정책은 정책 작성과 평가를 위해 이 정책 위임을 제어합니다. 이 정책은 하나 이상의 규칙과 하나 이상의 참조로 구성됩니다.

규칙

규칙은 정책 정의와 평가가 참조되는 자원을 정의합니다.

참조

참조는 정책 평가가 참조되는 조직을 정의합니다. 기본적으로 참조에는피어 영역과 하위 영역의 두 가지 유형이 있습니다. 이러한 참조는 각각 동일한 수준의 영역과 하위 수준의 영역에 위임됩니다. 자세한 내용은 피어 영역 및 하위 영역에 대한 정책 만들기 를 참조하십시오.

주 –

참조 대상 영역은 참조된 자원 또는 그 하위 자원에 대해서만 정책을 정의하거나 평가할 수 있습니다. 그러나 이 제한은 최상위 영역에는 적용되지 않습니다.

정책 정의 유형 문서

일단 작성하여 구성한 정책은 Directory Server에 XML 파일로 저장됩니다. Directory Server에서 XML로 인코딩된 데이터는 한 장소에 저장됩니다. amAdmin.dtd(또는 콘솔)를 사용하여 정책을 정의하고 구성하지만 실제로 Directory Server에는 policy.dtd를 기반으로 한 XML로 저장됩니다. policy.dtd에는 정책 작성 태그가 없고 amAdmin.dtd에서 추출한 정책 요소 태그가 포함됩니다. 그러므로 정책 서비스는 Directory Server에서 정책을 로드할 때 policy.dtd를 기반으로 XML의 구문을 분석합니다. amAdmin.dtd는 명령줄을 사용하여 정책을 만들 때만 사용됩니다. 이 절에서는 policy.dtd의 구조에 대해 설명합니다. policy.dtd는 다음 위치에 있습니다.

AccessManager-base/SUNWam/dtd(Solairs)
AccessManager-base/identity/dtd(Linux)

주 –

이 장에서는 Solaris 디렉토리에 대한 내용만 설명합니다. Linux의 디렉토리 구조는 다르므로 유의하십시오.

Policy 요소

Policy 요소는 정책의 권한 또는 규칙과 규칙 적용 대상 또는 주제를 정의하는 루트 요소입니다. 또한 정책이 참조(위임) 정책인지 아닌지 여부와 제한(또는 조건)이 있는지 여부도 정의합니다. Policy 요소에는Rule, Conditions, Subjects,Referrals 또는 response providers 와 같은 하위 요소가 한 가지 이상 포함될 수 있습니다. 필수 XML 속성은 정책의 이름을 지정하는 name 속성입니다. referralPolicy 속성은 정책이 참조 정책인지 여부를 나타내며 정의하지 않을 경우 기본값은 일반 정책입니다. 선택 XML 속성은 name 속성과 description 속성입니다.

주 –

정책에 참조라는 태그를 붙이면 정책 평가 시 주제와 조건은 무시됩니다. 반대로 일반이라는 태그를 붙이면 정책을 평가할 때 참조가 무시됩니다.

Rule 요소

Rule 요소는 정책에 대한 구체적인 사항을 정의하며ServiceName, ResourceName 또는 AttributeValuePair의 3가지 하위 요소를 취할 수 있습니다. Rule 요소는 정책이 만들어졌던 서비스 또는 응용 프로그램의 유형과 자원 이름, 수행되는 작업을 정의합니다. 규칙은 작업 없이 정의될 수 있습니다. 예를 들어, 참조 정책 규칙에는 작업이 없습니다.

주 –

ResourceName 요소가 정의되지 않은 정책을 정의할 수도 있습니다.

ServiceName 요소

ServiceName 요소는 정책이 적용되는 서비스의 이름을 정의합니다. 이 요소는 서비스 유형을 나타냅니다. 이 요소에는 다른 요소가 포함되지 않습니다. 이 요소의 값은 sms.dtd를 기반으로 서비스의 XML 파일에 정의된 것과 같습니다. ServiceName 요소의 XML 서비스 속성은 문자열 값을 취하는 서비스의 이름입니다.

ResourceName 요소

ResourceName 요소는 작업 수행 대상인 객체를 정의합니다. 정책은 이 객체를 보호하도록 특별히 구성되었습니다. 이 요소에는 다른 요소가 포함되지 않습니다. ResourceName 요소의 XML 서비스 속성은 객체의 이름입니다. ResourceName의 예로 웹 서버의 http://www.sunone.com:8080/images 또는 디렉토리 서버의 ldap://sunone.com:389/dc=example,dc=com을 들 수 있습니다. 보다 구체적인 자원의 예로 salary://uid=jsmith,ou=people,dc=example,dc=com을 들 수 있으며 여기서 작업 대상 객체는 John Smith의 급여 정보입니다.

AttributeValuePair 요소

AttributeValuePair 요소는 작업과 그 작업의 값을 정의합니다. 이 요소는 Subject 요소, Referral 요소 및 Condition 요소의 하위 요소로 사용됩니다. Attribute 요소와 Value 요소가 모두 포함되며 XML 서비스 속성은 포함되지 않습니다.

Attribute 요소

Attribute 요소는 작업의 이름을 정의합니다. 작업은 자원에 대해 수행되는 작업 또는 이벤트입니다. POST 또는 GET은 웹 서버 자원에 대해 수행되는 작업이며 READ 또는 SEARCH는 디렉토리 서버 자원에 대해 수행되는 작업입니다. Attribute 요소는 Value 요소와 함께 사용되어야 합니다. Attribute 요소 자체는 다른 요소를 포함하지 않습니다. Attribute 요소의 XML 서비스 속성은 작업의 이름입니다.

Value 요소

Value 요소는 작업 값을 정의합니다. 작업 값으로는 허용/거부 또는 예/아니요 등이 있습니다. 그 밖의 작업 값은 부울, 숫자 또는 문자열일 수 있습니다. 작업 값은 sms.dtd를 기반으로 서비스의 XML 파일에 정의됩니다. Value 요소는 다른 요소를 포함하지 않으며 XML 서비스 속성도 포함하지 않습니다.

주 –

거부 규칙은 허용 규칙보다 항상 우선됩니다. 예를 들어 한 정책이 액세스를 거부하고 다른 정책은 허용할 경우, 두 정책에 대한 다른 모든 조건은 충족된다고 가정할 때정책 간에 잠재적인 충돌이 일어날 수 있으므로 거부 정책을 사용할 때는 매우 주의해야 합니다. 명시적인 거부 규칙이 사용될 경우 역할이나 그룹 구성원처럼 다른 주제를 통해 사용자에게 할당된 정책 때문에 액세스가 거부될 수 있습니다. 일반적으로 정책 정의 프로세스에서는 허용 규칙만 사용해야 합니다. 기본 거부는 다른 정책이 적용되지 않을 때 사용될 수 있습니다.

Subjects 요소

Subjects 하위 요소는 정책이 적용되는 객체의 집합을 식별합니다. 이 집합은 그룹의 구성원, 역할의 소유자 또는 개인 사용자에 따라 선택됩니다. 이 요소의 하위 요소는 Subject입니다. 정의될 수 있는 XML 속성은 다음과 같습니다.

name. 이 속성은 컬렉션의 이름입니다.

description. 이 속성은 주제에 대한 설명입니다.

includeType. 이 속성은 현재 사용되지 않습니다.

Subject 요소

Subject 하위 요소는 정책이 적용되는 기본의 집합을 식별합니다. 이 집합은 Subjects 요소에 의해 정의되는 집합에서 보다 구체적인 객체들의 집합을 가려낸 것입니다. 이 집합의 구성원은 역할, 그룹 구성원 또는 개별 사용자를 기반으로 할 수 있습니다. 이 요소에는 하위 요소인 AttributeValuePair 요소가 포함됩니다. 필수 XML 속성은 type입니다. 이 속성은 정의된 주제가 취해지는 객체의 집합을 식별합니다. 다른 XML 속성으로는 집합의 이름을 정의하는 name 속성과 집합이 정의된 대로인지 정책이 Subject의 구성원이 아닌 사용자에게 적용되는지 여부를 정의하는 includeType 속성이 있습니다.

주 –

다수의 Subject를 정의할 때는 최소한 그 중 하나가 정책이 적용될 사용자에게 적용되어야 합니다. false로 설정된 includeType으로 Subject를 정의한 경우 사용자는 적용할 정책에 대한 해당 Subject의 구성원이 아니어야 합니다.

Referrals 요소

Referrals 하위 요소는 정책 참조 집합을 식별합니다. 이 요소는 Referral 하위 요소를 취합니다. 정의될 수 있는 XML 속성은 집합의 이름을 정의하는 name 속성과 설명을 취하는 description 속성입니다.

Referral 요소

Referral 하위 요소는 특정 정책 참조를 식별합니다. 이 요소는 AttributeValuePair 요소를 하위 요소로 취합니다. 필수 XML 속성은 구체적으로 정의된 참조를 취하는 할당의 집합을 식별하는 type 속성입니다. 집합의 이름을 정의하는 name 속성도 포함될 수 있습니다.

Conditions 요소

Conditions 하위 요소는 정책 제한 사항(시간 범위, 인증 수준 등)의 집합을 식별합니다. 이 요소는 하나 이상의 Condition 하위 요소를 포함해야 합니다. 정의될 수 있는 XML 속성은 집합의 이름을 정의하는 name 속성과 설명을 취하는 description 속성입니다.

주 –

Conditions 요소는 정책의 선택 요소입니다.

Condition 요소

Condition 하위 요소는 특정 정책 제한 사항(시간 범위, 인증 수준 등)을 식별합니다. 이 요소는 AttributeValuePair 요소를 하위 요소로 취합니다. 필수 XML 속성은 구체적으로 정의된 조건을 취하는 제한 사항의 집합을 식별하는 type 속성입니다. 집합의 이름을 정의하는 name 속성도 포함될 수 있습니다.

정책 가능 서비스 추가

지정된 서비스의 자원에 대한 정책은 서비스 방식에 sms.dtd 에 구성되는 <Policy> 요소가 있는 경우에만 정의할 수 있습니다.

기본적으로, Access Manager는 URL 정책 에이전트 서비스(iPlanetAMWebAgentService)를 제공합니다. 이 서비스는 다음 디렉토리에 있는 XML 파일에 정의됩니다.

/etc/opt/SUNWam/config/xml/

그러나 Access Manager에 정책 서비스를 추가할 수 있습니다. 일단 정책 서비스가 만들어지면 amadmin 명령줄 유틸리티를 통해 Access Manager에 추가합니다.

새 정책 사용 가능 서비스를 추가하려면

단계

sms.dtd에 따라 XML 파일 형식의 새 정책 서비스를 개발합니다. Access Manager는 두 가지 정책 서비스 XML 파일을 제공하며 사용자는 다음과 같은 새 정책 서비스 파일을 기준으로 사용하게 됩니다.

amWebAgent.xml - 기본 URL 정책 에이전트 서비스를 위한 XML 파일로/etc/opt/SUNWam/config/xml/에 있습니다.

SampleWebService.xml- AccessManager-base/samples/policy에 있는 샘플 정책 서비스 파일입니다.

새 정책 서비스를 로드할 디렉토리에 XML 파일을 저장합니다. 예를 들면 다음과 같습니다.
/config/xml/newPolicyService.xml

amadmin 명령줄 유틸리티를 사용하여 새 정책 서비스를 로드합니다. 예를 들면 다음과 같습니다.

AccessManager-base/SUNWam/bin/amadmin
    --runasdn “uid=amAdmin,ou=People,default_org,
root_suffix
    --password password
    --schema /config/xml/newPolicyService.xml

새 정책 서비스를 로드한 후 amadmin을 통해 새 정책을 로드하거나 Access Manager 콘솔을 통해 정책 정의 규칙을 정의할 수 있습니다.

정책 만들기

정책 API와 Access Manager 콘솔을 통해 정책을 만들고 수정하고 삭제할 수 있으며 amadmin 명령줄 도구를 통해 정책을 만들고 삭제할 수 있습니다. amadmin 유틸리티를 사용하여 XML의 정책을 가져오고 나열할 수도 있습니다. 이 절에서는 amadmin 명령줄 유틸리티와 Access Manager 콘솔을 통해 정책을 만드는 방법에 대해 설명합니다. 정책 API에 대한 자세한 내용은 Sun Java System Access Manager 7 2005Q4 Developer’s Guide를 참조하십시오.

정책은 일반적으로 XML 파일을 사용하여 만들어지며 amadmin 명령줄 유틸리티를 통해 Access Manager에 추가된 후 Access Manager 콘솔을 사용하여 관리됩니다(콘솔을 사용하여 정책을 만들 수도 있음). amadmin을 사용하여 직접 정책을 수정할 수 없기 때문입니다. 정책을 수정하려면 Access Manager에서 정책을 삭제한 다음 amadmin을 사용하여 수정된 정책을 추가해야 합니다.

일반적으로 정책은 영역(또는 하위 영역) 수준에서 만들어져 영역 트리 전체에 사용됩니다.

amadmin을 사용하여 정책을 만들려면

단계

amadmin.dtd를 기반으로 정책 XML 파일을 만듭니다. 이 파일은 다음 디렉토리에 있습니다.

AccessManager-base/SUNWam/dtd

일단 정책 XML 파일이 만들어지면 다음 명령을 사용하여 로드할 수 있습니다.
AccessManager-base/SUNWam/bin/amadmin --runasdn "uid=amAdmin,ou=People,default_org, root_suffix" --password password --data policy.xml
여러 정책을 동시에 추가하려면 각 XML 파일에 정책을 하나씩 사용하는 대신 XML 파일 하나에 여러 정책을 입력합니다. 여러 XML 파일을 사용하여 정책을 빠르게 연속으로 로드하면 내부 정책 색인이 손상되어 일부 정책이 정책 평가에 포함되지 않을 수 있습니다.

amadmin을 통해 정책을 만들 경우, 인증 스키마 조건을 만드는 동안 인증 모듈이 영역에 등록되고 영역, LDAP 그룹, LDAP 역할 및 LDAP 사용자 주제를 만드는 동안 해당 LDAP 객체(영역, 그룹, 역할 및 사용자)가 존재하며 IdentityServerRoles 주제를 만드는 동안 Access Manager 역할이 존재하고 하위 영역 또는 피어 영역 참조를 만드는 동안 관련 영역이 존재하는지 확인합니다.

SubrealmReferral, PeerRealmReferral, Realm 주제, IdentityServerRoles 주제, LDAPGroups 주제 , LDAPRoles 주제 및 LDAPUsers의 값 요소 텍스트에서 주제는 전체 DN이어야 합니다.

Access Manager 콘솔을 사용하여 일반 정책을 만들려면

단계

정책을 만들려는 영역을 선택합니다.

정책 탭을 누릅니다.

정책 목록에서 새 정책을 누릅니다.

정책에 대한 이름 및 설명을 추가합니다.

정책을 활성화하려면 활성 속성에서 예를 선택합니다.

이 시점에서 일반 정책에 대한 모든 필드를 정의할 필요는 없습니다. 정책을 만든 다음 나중에 규칙, 주제, 조건 및 응답 공급자를 추가할 수 있습니다. 자세한 내용은 정책 관리를 참조하십시오.

만들기를 누릅니다.

Access Manager 콘솔을 사용하여 참조 정책을 만들려면

단계

정책을 만들려는 영역을 선택합니다.

정책 탭에서 새 참조를 누릅니다.

정책에 대한 이름 및 설명을 추가합니다.

정책을 활성화하려면 활성 속성에서 예를 선택합니다.

이 시점에서 참조 정책에 대한 모든 필드를 정의할 필요는 없습니다. 정책을 만든 다음 나중에 규칙 및 참조를 추가할 수 있습니다. 자세한 내용은 정책 관리를 참조하십시오.

만들기를 누릅니다.

피어 영역 및 하위 영역에 대한 정책 만들기

피어 및 하위 영역에 대해 정책을 만들려면 먼저 상위 또는 다른 피어 영역에 참조 정책을 만들어야 합니다. 참조 정책은 해당 규칙 정의에 하위 영역에서 관리될 자원 접두어를 포함해야 합니다. 상위 영역(또는 다른 피어 영역)에 참조 정책이 만들어지면 하위 영역(또는 피어 영역)에 일반 정책을 만들 수 있습니다.

이 예에서 o=isp는 상위 영역이고 o=example.com은 하위 영역으로 http://www.example.com의 자원과 하위 자원을 관리합니다.

하위 영역에 대한 정책을 만들려면

단계

o=isp에 참조 정책을 만듭니다. 참조 정책에 대한 내용은 참조 정책 수정 절차를 참조하십시오.

참조 정책은 http://www.example.com을 규칙의 자원으로 정의하고, example.com을 갖는 SubRealmReferral을 참조의 값으로 포함해야 합니다.

example.com 하위 영역으로 이동합니다.

이제 isp에서는 example.com으로 자원을 참조하며 http://www.example.com 자원 또는 http://www.example.com으로 시작하는 모든 자원에 대한 일반 정책을 만들 수 있습니다.

example.com에 의해 관리되는 다른 자원에 대한 정책을 정의하려면 o=isp에 추가 참조 정책을 만들어야 합니다.

정책 관리

일단 일반 또는 참조 정책을 만들어 Access Manager에 추가하면 Access Manager 콘솔을 통해 규칙, 주제, 조건 및 참조를 수정하여 정책을 관리할 수 있습니다.

일반 정책 수정

정책 탭을 통해 액세스 권한을 정의하는 일반 정책을 수정할 수 있습니다. 여러 규칙, 주제, 조건 및 자원 비교기를 정의 및 구성할 수 있습니다. 이 절에서는 이를 수행하는 단계를 나열하고 설명합니다.

규칙을 일반 정책에 추가하거나 수정하려면

단계

이미 정책을 만든 경우 규칙을 추가하려는 정책의 이름을 누릅니다. 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 일반 정책을 만들려면 을 참조하십시오.

규칙 메뉴에서 새로 만들기를 누릅니다.

규칙에 대해 다음 기본 서비스 유형 중 하나를 선택합니다. 정책에 대해 사용 가능한 서비스가 많은 경우 목록이 더 클 수도 있습니다.

검색 서비스

검색 서비스 쿼리에 대한 인증 작업을 정의하고 지정된 자원에 대한 웹 서비스 클라이언트의 프로토콜 호출을 수정합니다.

리버티 개인 프로필 서비스

리버티 개인 프로필 서비스 쿼리에 대한 인증 작업을 정의하고 지정된 자원에 대한 웹 서비스 클라이언트의 프로토콜 호출을 수정합니다.

URL 정책 에이전트

정책 집행을 위해 URL 정책 에이전트 서비스를 제공합니다. 이 서비스를 사용하여 관리자는 정책 집행자 또는 정책 에이전트를 통해 정책을 만들고 관리할 수 있습니다.

다음을 누르십시오.

규칙에 대한 이름 및 자원 이름을 입력합니다.

현재 정책 에이전트는 http:// 및 https:// 자원만 지원하고 호스트 이름 대신 IP 주소를 사용하는 것을 지원하지 않습니다.

호스트, 포트 및 자원 이름에 와일드카드가 지원됩니다. 예를 들면 다음과 같습니다.
http*://*:*/*.html
URL 정책 에이전트 서비스의 경우 포트 번호를 입력하지 않으면 기본 포트 번호는 http://의 경우 80이고 https://의 경우 443입니다.

규칙의 작업을 선택합니다. URL 정책 에이전트 서비스를 사용하는 경우 다음을 선택할 수 있습니다.
- GET
- POST

작업 값 선택
- 허용— 규칙에 정의된 자원과 일치하는 자원에 액세스할 수 있게 합니다.
- 거부— 규칙에 정의된 자원과 일치하는 자원에 대한 액세스를 거부합니다.
- 거부 규칙은 허용 규칙보다 항상 우선됩니다. 예를 들어, 주어진 자원에 대해 두 개의 정책, 즉 액세스를 거부하는 정책과 액세스를 허용하는 정책이 있을 경우 결과적으로 액세스가 거부됩니다(두 정책에 대한 조건이 충족될 경우). 정책 간에 잠재적인 충돌이 일어날 수 있으므로 거부 정책을 사용할 때는 매우 주의해야 합니다. 정책 정의 프로세스에서는 허용 규칙만 사용해야 합니다. 자원에 적용할 수 있는 정책이 없는 경우 액세스는 자동으로 거부됩니다.
  
  명시적 거부 규칙이 사용될 경우 다른 주제(예: 역할 및/또는 그룹 구성원)를 통해 주어진 사용자에 할당되는 정책은 하나 이상의 정책에 액세스를 허용할 경우 자원에 대한 액세스가 거부될 수 있습니다. 예를 들어, 사원 역할에 적용할 수 있는 자원에 대한 거부 정책이 있고 관리자 역할에 적용할 수 있는 동일한 자원에 대한 허용 정책이 있는 경우 사원 역할과 관리자 역할이 모두 할당된 사용자에 대한 정책 결정이 거부됩니다.
  
  이러한 문제를 해결하는 한 가지 방법은 조건 플러그 인을 사용하여 정책을 설계하는 것입니다. 위의 경우에 사원 역할에 인증된 사용자에게 거부 정책을 적용하고 관리자 역할에 인증된 사용자에게 허용 정책을 적용하는 “역할 조건”을 지정하여 두 정책을 차별화할 수 있습니다. 다른 방법은 인증 수준 조건을 사용하는 것입니다. 이 조건에서는 관리자 역할이 더 높은 인증 수준으로 인증됩니다.

마침을 누릅니다.

주제를 일반 정책에 추가하거나 수정하려면

단계

이미 정책을 만든 경우 주제를 추가하려는 정책의 이름을 누릅니다. 아직 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 일반 정책을 만들려면 을 참조하십시오.

주제 목록에서 새로 만들기를 누릅니다.

다음 기본 주제 유형 중 하나를 선택합니다. 주제 유형에 대한 설명은 주제를 참조하십시오.

다음을 누르십시오.

주제의 이름을 입력합니다.

단독 필드를 선택하거나 선택 취소합니다.

이 필드를 선택하지 않을 경우(기본값) 주제의 구성원인 Identity에 정책이 적용됩니다. 이 필드를 선택할 경우 정책은 주제의 구성원이 아닌 Identity에 적용됩니다.

정책에 여러 개의 주제가 있는 경우 Identity가 최소한 하나 이상 주제의 구성원이면 정책은 Identity에 적용됩니다.

주제에 추가할 Identity를 표시하기 위해 검색을 수행합니다. 이 단계는 인증된 사용자 주제 또는 웹 서비스 클라이언트 주제에는 적용되지 않습니다.

기본(*) 검색 패턴은 모든 항목을 표시합니다.

주제에 대해 추가할 개별 Identity를 선택하거나 모두 추가를 눌러 모든 Identity를 한 번에 추가합니다. 추가를 눌러 Identity를 선택 목록으로 이동합니다. 인증된 사용자 주제에 대해서는 이 단계가 해당되지 않습니다.

마침을 누릅니다.

정책에서 주제를 제거하려면 해당 주제를 선택하고 삭제를 누릅니다. 주제 이름을 눌러 주제 정의를 편집할 수 있습니다.

일반 정책에 조건을 추가하려면

단계

이미 정책을 만든 경우 조건을 추가하려는 정책의 이름을 누릅니다. 아직 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 일반 정책을 만들려면 을 참조하십시오.

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

조건 유형을 선택하고 다음을 누릅니다.

조건 유형의 필드를 정의합니다. 조건 유형에 대한 설명은 조건을 참조하십시오.

마침을 누릅니다.

일반 정책에 응답 공급자를 추가하려면

단계

이미 정책을 만든 경우 응답 공급자를 추가하려는 정책의 이름을 누릅니다. 아직 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 일반 정책을 만들려면 을 참조하십시오.

응답 공급자 목록에서 새로 만들기를 누릅니다.

응답 공급자의 이름을 입력합니다.

다음 값을 정의합니다.

StaticAttribute

IDResponseProvider 인스턴스에 정의되고 정책에 저장된 이름 및 값을 가진 응답 속성입니다.

DynamicAttribute

여기에서 선택한 응답 속성은 먼저 해당 영역의 정책 구성 서비스에 정의되어야 합니다. 지정한 속성 이름은 구성된 데이터 저장소에 있는 이름과 같아야 합니다. 속성을 정의하는 방법에 대한 자세한 내용은 Access Manager 온라인 도움말의 정책 구성 속성 정의를 참조하십시오.

마침을 누릅니다.

정책에서 응답 공급자를 제거하려면 해당 주제를 선택하고 삭제를 누릅니다. 이름을 눌러 응답 공급자 정의를 편집할 수 있습니다.

참조 정책 수정

참조 정책을 사용하여 정책 정의와 영역 결정을 다른 영역으로 위임할 수 있습니다. 사용자 정의 참조는 정책 대상 지점에서 정책 결정을 가져오는 데 사용됩니다. 참조 정책을 만들면 관련된 규칙, 참조 및 자원 공급자를 추가 또는 수정할 수 있습니다.

규칙을 참조 정책에 추가하거나 수정하려면

단계

이미 정책을 만든 경우 규칙을 추가하려는 정책의 이름을 누릅니다. 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 참조 정책을 만들려면 을 참조하십시오.

규칙 목록에서 새로 만들기를 누릅니다.

규칙에 대해 다음 기본 서비스 유형 중 하나를 선택합니다. 정책에 대해 사용 가능한 서비스가 많은 경우 목록이 더 클 수도 있습니다.

검색 서비스

검색 서비스 쿼리에 대한 인증 작업을 정의하고 지정된 자원에 대한 웹 서비스 클라이언트의 프로토콜 호출을 수정합니다.

리버티 개인 프로필 서비스

리버티 개인 프로필 서비스 쿼리에 대한 인증 작업을 정의하고 지정된 자원에 대한 웹 서비스 클라이언트의 프로토콜 호출을 수정합니다.

URL 정책 에이전트

정책 집행을 위해 URL 정책 에이전트 서비스를 제공합니다. 이 서비스를 사용하여 관리자는 정책 집행자 또는 정책 에이전트를 통해 정책을 만들고 관리할 수 있습니다.

다음을 누르십시오.

규칙에 대한 이름 및 자원 이름을 입력합니다.

현재 정책 에이전트는 http:// 및 https:// 자원만 지원하고 호스트 이름 대신 IP 주소를 사용하는 것을 지원하지 않습니다.

자원 이름, 포트 번호 및 프로토콜에 와일드카드가 지원됩니다. 예를 들면 다음과 같습니다.
http://*:*/*.html
URL 정책 에이전트 서비스의 경우 포트 번호를 입력하지 않으면 기본 포트 번호는 http://의 경우 80이고 https://의 경우 443입니다.

자원을 http://host*:*로 정의하여 특정 시스템에 설치된 모든 서비스에 대한 자원 관리를 허용할 수 있습니다. 또한 다음 자원을 정의하여 관리자에게 조직의 모든 서비스에 대한 특정 조직 권한을 부여할 수 있습니다.
http://*.subdomain.domain.topleveldomain

마침을 누릅니다.

참조를 정책에 추가 또는 수정하려면

단계

이미 정책을 만든 경우 응답 공급자를 추가하려는 정책의 이름을 누릅니다. 아직 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 참조 정책을 만들려면 을 참조하십시오.

규칙 목록에서 새로 만들기를 누릅니다.

서비스 유형을 선택합니다.

규칙 필드에서 자원을 정의합니다. 필드는 다음과 같습니다.

Referral— 현재 참조 유형을 표시합니다.

Name— 참조 이름을 입력합니다.

Resource Name— 자원 이름을 입력합니다.

Filter— 값 필드에 표시될 조직 이름에 대한 필터를 지정합니다. 기본적으로 이 필드에는 모든 조직 이름이 표시됩니다.

Value — 참조의 조직 이름을 선택합니다.

마침을 누릅니다.

정책에서 참조를 제거하려면 참조를 선택하고 삭제를 누릅니다.

참조 이름 옆에 있는 편집 링크를 눌러 모든 참조 정의를 편집할 수 있습니다.

참조 정책에 응답 공급자를 추가하려면

단계

이미 정책을 만든 경우 응답 공급자를 추가하려는 정책의 이름을 누릅니다. 아직 정책을 만들지 않은 경우 Access Manager 콘솔을 사용하여 일반 정책을 만들려면 을 참조하십시오.

응답 공급자 목록에서 새로 만들기를 누릅니다.

응답 공급자의 이름을 입력합니다.

다음 값을 정의합니다.

StaticAttribute

IDResponseProvider 인스턴스에 정의되고 정책에 저장된 이름 및 값을 가진 응답 속성입니다.

DynamicAttribute

정책의 IDResponseProvider 인스턴스에 선택된 이름만 가진 응답 속성입니다. 값은 정책 평가 중 사용자 아이디 요청에 따라 IDRepostitories에서 읽습니다.

마침을 누릅니다.

정책에서 응답 공급자를 제거하려면 해당 주제를 선택하고 삭제를 누릅니다. 이름을 눌러 응답 공급자 정의를 편집할 수 있습니다.

정책 구성 서비스

정책 구성 서비스는 Access Manager 콘솔을 통해 각 조직에 대한 정책 관련 속성을 구성하는 데 사용됩니다. Access Manager 정책 프레임워크에 사용되는 자원 이름 구현 및 Directory Server 데이터 저장소를 정의할 수도 있습니다. 정책 구성 서비스에 지정된 Directory Server는 LDAP 사용자, LDAP 그룹, LDAP 역할 및 조직 정책 주제의 구성원 평가에 사용됩니다.

주제 결과 수명

정책 평가 성능을 향상시키려면 정책 구성 서비스의 주제 결과 수명 속성에 정의된 시간 동안 구성원 평가를 캐시에 저장합니다. 이렇게 캐시에 저장된 구성원 결정은 주제 결과 수명 속성에 정의된 시간이 다 지날 때까지 사용됩니다. 이후의 구성원 평가는 디렉토리 내 사용자의 현재 상태를 반영하는 데 사용됩니다.

동적 속성

목록에 표시되고 정책 응답 공급자 동적 속성을 정의하기 위해 선택된 허용된 동적 속성 이름입니다. 정의된 이름은 데이터 저장소에 정의된 속성 이름과 같아야 합니다.

amldapuser 정의

amldapuser는 기본으로 사용되는 설치 중에 정책 구성 서비스에서 지정된 Directory Server에 생성된 사용자입니다. 이는 필요에 따라 관리자 또는 해당 영역의 정책 관리자에 의해 변경될 수 있습니다.

정책 구성 서비스 추가

영역이 생성될 때 정책 구성 서비스 속성이 자동으로 이 영역에 대해 설정됩니다. 하지만 필요한 경우 속성을 수정할 수 있습니다.

자원 기반 인증

일부 조직에서는 사용자가 액세스를 시도하는 자원에 따라 특정 모듈에 대해 인증하는 고급 인증 시나리오를 요구합니다. 자원 기반 인증은 사용자가 기본 인증 모듈이 아니라 자원을 보호하는 특정 인증 모듈에 인증해야 하는 Access Manager의 기능입니다. 이 기능은 처음으로 사용자를 인증하는 경우에만 사용할 수 있습니다.

주 –

이 기능은 세션 업그레이드에 설명된 자원 기반 인증과는 다른 기능입니다. 해당 특정 기능에는 제한 사항이 없습니다.

제한 사항

자원 기반 인증에는 다음과 같은 제한 사항이 포함됩니다.

자원에 적용할 수 있는 정책에 여러 인증 모듈이 있는 경우 해당 시스템에서 임의로 하나의 인증 모듈을 선택합니다.
이 정책에 대해 정의될 수 있는 조건은 수준과 방법뿐입니다.
이 기능은 서로 다른 DNS 도메인 사이에서는 사용할 수 없습니다.

자원 기반 인증을 구성하려면

Access Manager와 정책 에이전트가 모두 설치되면 자원 기반 인증을 구성할 수 있습니다. 자원 기반 인증을 구성하려면 Access Manager가 게이트웨이 서블릿을 가리켜야 합니다.

단계

AMAgent.properties를 엽니다.

AMAgent.properties는 Solaris 환경에서 /etc/opt//SUNWam/agents/config/에 있습니다.

다음 행을 주석으로 처리합니다.

#com.sun.am.policy.am.loginURL = http://Access Manager_server_host.domain_name:port/amserver/UI/Login.

다음 행을 파일에 추가합니다.

com.sun.am.policy.am.loginURL = http://AccessManager_host.domain_name:port/amserver/gateway

주 –
게이트웨이 서블릿은 Policy Evaluation API를 사용하여 개발하며 자원 기반 인증을 수행하는 사용자 정의 기법을 작성하는 데 사용됩니다. Sun Java System Access Manager 7 2005Q4 Developer’s Guide의 6 장, Using the Policy APIs에 있는 6장, Using the Policy APIs를 참조하십시오.

에이전트를 다시 시작합니다.

9장 주제 관리

주제 인터페이스를 사용해 영역 내 기본적인 아이디 관리를 할 수 있습니다. 주제 인터페이스에서 만든 모든 아이디는 Access Manager 아이디 주제 유형으로 만든 정책의 주제 정의에 사용할 수 있습니다.

생성 및 수정할 수 있는 아이디는 다음과 같습니다.

사용자

사용자는 개인의 아이디를 나타냅니다. 그룹의 사용자를 생성 및 제거할 수 있으며 역할 및/또는 그룹에 사용자를 추가 또는 제거할 수 있습니다. 사용자에게 서비스를 할당할 수도 있습니다.

사용자를 만들거나 수정하려면

단계

사용자 탭을 누릅니다.

새로 만들기를 누릅니다.

다음 필드에 데이터를 입력합니다.

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

이름.이 필드는 사용자의 이름을 가집니다.

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

전체 이름. 이 필드는 사용자의 전체 이름을 가집니다.

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

비밀번호(확인). 비밀번호를 확인합니다.

사용자 상태.이 옵션은 사용자에게 Access Manager를 통한 인증이 허용되었는지 여부를 나타냅니다.

만들기를 누릅니다.

사용자가 생성되면 사용자의 이름을 눌러 사용자 정보를 편집할 수 있습니다. 사용자 속성에 대한 자세한 내용은 사용자 속성을 참조하십시오. 다음을 수행할 수 있습니다.

역할 및 그룹에 사용자를 추가하려면

단계

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

역할 또는 그룹을 선택합니다. 이미 사용자에게 할당된 역할과 그룹만 표시됩니다.

사용 가능한 목록에서 역할 또는 그룹을 선택하고 추가를 누릅니다.

선택된 목록에 역할 또는 그룹이 표시되면 저장을 누릅니다.

아이디에 서비스를 추가하려면

단계

서비스를 추가할 아이디를 선택합니다.

서비스 탭을 누릅니다.

추가를 누릅니다.

선택한 아이디 유형에 따라 다음과 같은 서비스 목록이 표시됩니다.
- 인증 구성
- 검색 서비스
- 리버티 개인 프로필 서비스
- 세션
- 사용자

추가할 서비스를 선택하고 다음을 누릅니다.

서비스에 대한 속성을 편집합니다. 서비스 정의에 대한 설명을 참조하려면 4단계에서 서비스 이름을 누릅니다.

마침을 누릅니다.

에이전트

Access Manager 정책 에이전트는 허용되지 않은 침입으로부터 웹 서버 및 웹 프록시 서버의 컨텐트를 보호합니다. 또한 관리자가 구성한 정책을 기반으로 서비스 및 웹 자원에 대한 액세스를 제어합니다.

에이전트 객체는 정책 에이전트 프로필을 정의하고 Access Manager 자원을 보호하는 특정 에이전트에 대한 인증 및 기타 프로필 정보를 Access Manager에서 저장할 수 있게 합니다. 관리자는 Access Manager 콘솔을 사용해 에이전트 프로필을 확인, 작성, 수정 및 삭제할 수 있습니다.

에이전트 객체 만들기 페이지는 에이전트가 Access Manager에 대해 인증할 때 사용한 UID/비밀번호를 정의하는 곳입니다. 같은 Access Manager를 사용하는 AM/WS 설정이 여러 개 있는 경우 다른 에이전트에 대해 여러 아이디를 활성화하고 이들을 Access Manager와 별개로 활성화 및 비활성화하는 옵션을 제공합니다. 또한 각 컴퓨터에서 AMAgent.properties를 편집하지 않고 에이전트에 대한 일부 기본 설정 값을 중앙에서 관리할 수 있습니다.

에이전트를 만들거나 수정하려면

단계

에이전트 탭을 누릅니다.

새로 만들기를 누릅니다.

다음과 같은 필드에 값을 입력합니다.

이름.에이전트의 이름 또는 아이디를 입력합니다. 에이전트가 Access Manager에 로그인할 때 사용할 이름입니다. 멀티바이트 이름은 사용할 수 없습니다.

비밀번호. 에이전트의 비밀번호를 입력합니다. 이 비밀번호는 LDAP 인증 도중에 에이전트가 사용하는 비밀번호와는 달라야 합니다.

비밀번호 확인. 비밀번호를 확인합니다.

장치 상태.에이전트의 장치 상태를 입력합니다. 활성으로 설정된 경우 에이전트는 Access Manager에 대해 인증되어 Access Manager와 통신할 수 있습니다. 비활성으로 설정된 경우 에이전트는 Access Manager에 대해 인증될 수 없습니다.

만들기를 누릅니다.

에이전트를 만든 후에는 다음과 같은 필드를 추가로 편집할 수 있습니다.

설명.에이전트에 대한 간단한 설명을 입력합니다. 예를 들어 에이전트 인스턴스 이름이나 에이전트가 보호하고 있는 응용 프로그램의 이름을 입력할 수 있습니다.

에이전트 키 값. 키/값 쌍을 사용하여 에이전트 등록 정보를 설정합니다. Access Manager는 이 등록 정보를 사용하여 사용자의 자격 증명 명제에 대한 에이전트 요청을 받습니다. 현재는 하나의 등록 정보만 유효하며 다른 모든 등록 정보는 무시됩니다. 다음 형식을 사용합니다.

agentRootURL=http:// server_name:port/

고유 정책 에이전트 아이디 만들기

기본적으로 신뢰할 수 있는 환경에서 여러 정책 에이전트를 만드는 경우 정책 에이전트에는 동일한 UID 및 비밀번호가 포함됩니다. UID 및 비밀번호를 공유하므로 Access Manager는 에이전트를 구분할 수 없어 세션 쿠키를 가로챌 수 있는 상태로 열어 둘 수 있습니다.

아이디 공급자가 타사 또는 기업 내 허용되지 않은 그룹에 의해 개발된 응용 프로그램(또는 서비스 제공업체)에 사용자에 대한 인증, 권한 부여 및 프로필 정보를 제공하는 경우 취약점이 발생할 수 있습니다. 예상되는 보안 문제는 다음과 같습니다.

모든 응용 프로그램은 동일한 http 세션 쿠키를 공유합니다. 이렇게 되면 rogue 응용 프로그램이 세션 쿠키를 하이재킹하여 다른 응용 프로그램에 대해 사용자를 가장할 수 있습니다.
응용 프로그램이 https 프로토콜을 사용하지 않는 경우 세션 쿠키는 네트워크 도청에 취약합니다.
단 하나의 응용 프로그램이라도 해킹당하는 경우 전체 인프라의 보안이 손상될 위험이 있습니다.
감염된 응용 프로그램은 세션 쿠키를 사용하여 사용자에 대한 프로필 속성을 가져와서 수정할 수 있습니다. 사용자가 관리 권한을 가진 경우 응용 프로그램은 보다 많은 손상을 입을 수 있습니다.

고유 정책 에이전트 아이디를 만들려면

단계

Access Manager 관리 콘솔을 사용하여 각 에이전트에 대한 항목을 만듭니다.

에이전트를 만들 때 입력한 비밀번호에 대해 다음 명령을 실행합니다. 이 명령은 에이전트가 설치된 호스에서 호출되어야 합니다.

AccessManager-base/SUNWam/agents/bin/crypt_util agent123

이 명령을 실행하면 다음과 같은 출력이 표시됩니다.

WnmKUCg/y3l404ivWY6HPQ==

AMAgent.properties를 변경하여 새 값을 적용한 다음 에이전트를 다시 시작합니다. 예:

# The username and password to use for the Application 

authentication module.



com.sun.am.policy.am.username = agent123

com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ==



# Cross-Domain Single Sign On URL

# Is CDSSO enabled.

com.sun.am.policy.agents.cdsso-enabled=true



# This is the URL the user will be redirected to after successful login

# in a CDSSO Scenario.

com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port

/amserver/cdcservlet

새 값을 반영하기 위해 Access Manager를 설치한 AMConfig.properties를 변경한 다음 Access Manager를 다시 시작합니다. 예:

com.sun.identity.enableUniqueSSOTokenCookie=true

com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer

 

com.sun.identity.authentication.uniqueCookieDomain=.example.com

Access Manager 콘솔에서 구성>플랫폼을 선택합니다.

쿠키 도메인 목록에서 쿠키 도메인 이름을 다음과 같이 변경합니다.
1. 기본 iplanet.com 도메인을 선택한 다음 제거를 누릅니다.
2. Access Manager 설치의 호스트 이름을 입력한 다음 추가를 누릅니다.
  
  예: server.example.com
  
  다음과 같이 브라우저에 설정된 두 개의 쿠키가 표시됩니다.
  - iPlanetDirectoryPro – server.example.com(호스트 이름)
  - sunIdentityServerAuthNServer – example.com(호스트 이름)

필터링된 역할

필터링된 역할은 LDAP 필터를 사용하여 작성된 동적 역할입니다. 모든 사용자가 필터를 통해 걸러져 역할 작성 시 역할에 할당됩니다. 필터는 항목의 임의 속성 값 쌍(예: ca=user*)을 찾아 해당 속성을 포함하는 사용자를 역할에 자동으로 할당합니다.

필터링된 역할을 만들려면

단계

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

새로 만들기를 누릅니다.

필터링된 역할의 이름을 입력합니다.

검색 조건에 대한 정보를 입력합니다.

예:
(&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*))))
필터를 비워두면 기본적으로 다음과 같은 역할이 생성됩니다.
(objectclass = inetorgperson)

만들기를 눌러 필터 조건에 기초한 검색을 시작합니다. 필터 조건에 의해 정의된 아이디가 자동으로 역할에 할당됩니다.

필터링된 역할이 생성되면 역할의 이름을 눌러 역할에 속한 사용자를 확인합니다. 또한 서비스 탭을 눌러 역할에 서비스를 추가할 수도 있습니다.

역할

역할의 구성원은 역할을 소유하는 LDAP 항목입니다. 역할의 기준 자체는 속성과 함께 LDAP 항목으로 정의되며 항목의 고유 이름(DN) 속성에 의해 식별됩니다. 역할을 만들면 서비스와 사용자를 직접 추가할 수 있습니다.

역할을 만들거나 수정하려면

단계

역할 탭을 누릅니다.

역할 목록에서 새로 만들기를 누릅니다.

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

만들기를 누릅니다.

역할 또는 그룹에 사용자를 추가하려면

단계

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

사용자 탭을 누릅니다.

사용 가능한 목록에서 추가할 사용자를 선택한 다음 추가를 누릅니다.

선택된 목록에 사용자가 표시되면 저장을 누릅니다.

그룹

그룹은 공통적인 기능, 특징 또는 관심을 가지는 사용자의 집합을 나타냅니다. 일반적으로 이 그룹에는 연관된 권한이 없습니다. 그룹은 두 가지 수준 즉, 조직 내에서와 다른 관리 대상 그룹 내에서 존재할 수 있습니다.

그룹을 만들거나 수정하려면

단계

그룹 탭을 누릅니다.

그룹 목록에서 새로 만들기를 누릅니다.

그룹의 이름을 입력합니다.

만들기를 누릅니다.

그룹을 만들면 그룹 이름 및 사용자 탭을 차례로 눌러 그룹에 사용자를 추가할 수 있습니다.