Sun Java System Calendar Server 6 2005Q4 관리 설명서

달력 액세스 제어

Calendar Server에서는 액세스 제어 목록(ACL)을 사용하여 달력, 달력 등록 정보 그리고 이벤트, 수행할 작업(태스크)과 같은 달력 구성 요소의 액세스 제어를 결정합니다.

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

보안 Calendar Server 로그인

사용자가 Communications Express를 통해 Calendar Server에 로그인할 때 기본적으로 인증 프로세스에서는 사용자 아이디와 비밀번호를 비롯한 로그인 정보를 암호화하지 않습니다. 사이트에서 보안 로그인을 원할 경우 Calendar Server가 SSL(Secure Sockets Layer) 프로토콜을 사용하여 로그인 데이터를 암호화하도록 구성합니다. 자세한 내용은 8 장, SSL 구성, SSL 구성을 참조하십시오.

사용자별 액세스 제어

Calendar Server에서는 달력, 달력 등록 정보 및 달력 구성 요소에 대한 액세스를 결정할때 다음 사용자를 인식합니다.

주 달력 소유자

주 달력 소유자는 소유한 달력에 대해 모든 액세스 권한을 갖습니다. Calendar Server에서는 자신의 달력에 액세스하는 주 소유자에 대해 액세스 제어를 확인하지 않습니다.
관리자수퍼유저

calmaster와 같은 관리자나 root와 같은 수퍼유저는 액세스 제어 제한을 적용받지 않으며 달력이나 달력 구성 요소와 관련된 모든 작업을 수행할 수 있습니다. 자세한 내용은 Calendar Server 특별 계정을 참조하십시오.
다른 달력 소유자

주 달력 소유자는 자신의 달력에 대해 다른 소유자를 지정할 수 있습니다. 그러면 다른 소유자는 주 소유자를 대신하여 해당 달력에 대해 이벤트나 수행할 작업(태스크)을 예약, 삭제, 수정, 적용 또는 거절할 수 있습니다.
익명 사용자

특수한 달력 아이디(calid) anonymous는 임의의 비밀번호를 사용하여 Calendar Server에 액세스할 수 있습니다. 단, ics.conf 파일에서 service.http.allowanonymouslogin이 “yes”(기본값)로 설정된 상태여야 합니다. anonymous 사용자는 특정 도메인과 연관되지 않습니다. calstore.anonymous.calid 매개 변수를 편집하여 anonymous 사용자의 calid를 변경할 수 있습니다.

또한 어떤 달력의 사용 권한이 모든 사용자에게 읽기 액세스를 허용한 경우 익명으로 달력을 볼 수 있습니다. 예를 들어, 다음 링크에서 사용자는 calid가 tchang:meetings인 달력을 익명으로 볼 수 있습니다(달력의 사용 권한이 모든 사용자에게 읽기 액세스를 허용한 경우).

http://calendar.sesta.com:8080/?calid=tchang:meetings

anonymous 사용자는 달력에서 공개 이벤트 및 태스크를 조회, 인쇄 및 검색할 수 있지만 그 외의 어떤 작업도 수행할 수 없습니다.

익명으로 자원 달력 보기에 대한 자세한 내용은 달력 링크 만들기를 참조하십시오.

액세스 제어 목록(ACL)

Calendar Server는 액세스 제어 목록(ACL)을 사용하여 달력, 달력 등록 정보 그리고 이벤트, 수행할 작업(태스크)과 같은 달력 구성 요소의 액세스 제어를 결정합니다. ACL은 하나 이상의 액세스 제어 항목(ACE)으로 구성됩니다. ACE는 동일한 달력이나 구성 요소에 집합적으로 적용되는 문자열입니다. ACL에서 각 ACE는 세미콜론으로 구분됩니다. 예를 들면 다음과 같습니다.

jsmith^c^wd^g는 하나의 ACE로 구성되어 있습니다.
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g는 세 개의 ACE로 구성되어 있습니다.

ACE는 각각 캐럿(^)으로 구분되는 다음 요소들로 구성됩니다.

Who - ACE가 적용되는 개인, 사용자, 도메인 또는 사용자 유형
What - 달력, 이벤트나 수행할 작업(태스크)과 같은 달력 구성 요소, 달력 등록 정보 등과 같은 모든 액세스 대상
How - 읽기, 쓰기, 삭제 등과 같은 허용된 액세스 제어 권한의 유형
Grant - 부여되거나 거부된 특정 액세스 제어 권한

예를 들어, ACE jsmith^c^wd^g에서

jsmith는 ACE가 누구에서 적용되는지를 나타내는 Who 요소입니다.
c는 액세스 대상(달력 구성 요소만 해당)을 나타내는 What 요소입니다.
wd는 어떤 액세스 권한이 부여 또는 거부되는지(쓰기 및 삭제) 나타내는 How 요소입니다.
g는 해당 달력 구성 요소에 대해 jsmith에게 부여된 액세스 권한, 쓰기 및 삭제를 나타내는 Grant 요소입니다.

Who

Who 요소는 ACE의 기본적인 값이며, ACE가 누구에게 적용되는지를 나타냅니다(예: 개별 사용자, 도메인 또는 특정 사용자 유형).

Who는 UPN(Universal Principal Name)이라고도 부릅니다. 사용자의 UPN은 해당 사용자의 로그인 아이디와 도메인을 결합한 것입니다. 예를 들어, 도메인 sesta.com에 있는 사용자 bill의 UPN은 bill@sesta.com입니다.

표 1–2 액세스 제어 항목(ACE) 문자열의 “Who” 형식


형식	설명
`user`	특정 사용자를 참조합니다예: jsmith.
`user@domain`	특정 도메인의 특정 사용자를 참조합니다예: `jsmith@sesta.com` .
`@domain`	지정된 도메인에서 임의의 사용자를 참조합니다. 예를 들어,`@sesta.com` specifies `jsmith@sesta.com` , `sally@sesta.com`, and anyone else at `sesta.com` . 이 형식을 사용하여 도메인 전체 사용자에게 액세스 권한을 부여하거나 거부합니다.
`@`	모든사용자를참조합니다
`@@{d\|p\|o\|n}`	달력의소유자를참조합니다 `@@d` – 주 소유자의 도메인 `@@p` – 주 소유자만 해당 `@@o` – 주 소유자를 비롯한 모든 소유자 `@@n` – 소유자가 아님

What

What 요소는 달력, 달력 구성 요소(이벤트나 태스크), 달력 등록 정보 등 액세스 대상을 지정합니다.

표 1–3 액세스 제어 항목(ACE) 문자열의 “What” 값

값

설명

이벤트, 태스크와 같은 달력 구성 요소를 지정합니다.

이름, 설명, 소유자를 비롯하여 달력 등록 정보를 지정합니다.

구성 요소와 등록 정보를 포함하여 달력 전체(all)를 지정합니다.

How

How 요소는 읽기, 쓰기, 삭제 등 허가되는 액세스 제어 권한의 유형을 지정합니다.

표 1–4 액세스 제어 항목(ACE) 문자열의 “How” 형식


유형	설명
`r`	읽기 액세스
`w`	새 항목 추가 및 기존 항목 변경을 포함하는 쓰기 액세스
`d`	삭제 액세스
`s`	예약(초대) 액세스. 요청을 수행하고 응답을 받아들이며 다른 ITIP 예약 대화형 작업을 적용할 수 있습니다.
`f`	사용 가능/사용 중(가용성) 액세스 전용. 사용 가능/사용 중 액세스란 사용자가 달력의 예약 시간을 조회할 수 있지만 이벤트 세부 정보는 볼 수 없음을 의미합니다. 그 대신 예약된 시간 블록 옆에 “Not Available”이라고만 표시됩니다. 예약된 이벤트가 없는 시간 블록은 그 옆에 “Available”이라고 표시됩니다.
l	도메인 액세스를 조회합니다.
`e`	응답 액세스를 대신합니다. 이 유형은 달력의 주 소유자를 대신하여 초대를 받아들이거나 거절할 권한을 사용자에게 부여합니다. 이러한 유형의 액세스는 사용자가 주 소유자가 아닌 소유자로 지정된 경우 포함되므로 명시적으로 부여할 필요가 없습니다.
`i`	초대 액세스를 대신합니다. 이 유형은 달력의 주 소유자를 대신하여 다른 참석자가 초대된 구성 요소를 만들고 수정하는 권한을 사용자에게 부여합니다. 이러한 유형의 액세스는 사용자가 주 소유자가 아닌 소유자로 지정된 경우 포함되므로 명시적으로 부여할 필요가 없습니다.
`c`	취소 액세스를 대신합니다. 이 유형은 사용자가 달력의 주 소유자를 대신하여 참석자가 초대된 구성 요소를 취소할 권한을 사용자에게 부여합니다. 이러한 유형의 액세스는 사용자가 주 소유자가 아닌 소유자로 지정된 경우 포함되므로 명시적으로 부여할 필요가 없습니다.
`z`	자체 관리 액세스 - 인증된 사용자에게 ACE를 추가 또는 제거할 수 있는 권한을 부여합니다. 이 권한을 가진 사용자는 자신의 권한을 추가 및 제거할 수 있습니다. 예를 들어 UserA에는 UserB의 달력에 대해 쓰기 액세스 권한이 아닌 자체 관리 액세스 권한이 부여될 수 있습니다. 그러면 UserA는 스스로 UserB의 달력에 대해 쓰기 액세스 권한을 부여하는 ACE를 추가할 수 있습니다. 주: 이 권한을 통해 UserA가 다른 사용자에게 UserB의 달력에 액세스할 수 있는 권한을 줄 수 없습니다. 예를 들어 자체 관리 권한은 UserA가 UserC에게 UserB의 달력에 액세스할 수 있는 권한을 주도록 허용하지 않습니다.

Grant

Grant 요소는 d(삭제) 또는 r(읽기) 등 지정된 액세스 유형을 부여 또는 거부할 것인지 여부를 지정합니다.

표 1–5 액세스 제어 항목(ACE) 문자열의 Grant 값


값	설명
`g`	특정 액세스 제어 권한을 부여합니다.
`d`	특정 액세스 제어 권한을 거부합니다.

ACE 예제

다음 예제에서는 ACE 사용 방법을 보여 줍니다.

사용자 아이디 jsmith에게 구성 요소와 등록 정보를 포함하여 달력 전체에 대한 읽기 액세스를 부여합니다.

jsmith^a^r^g
jsmith에게 구성 요소에 대해서만 쓰기 및 삭제 액세스 권한을 부여합니다.

jsmith^c^wd^g
sesta.com 도메인의 모든 사용자에게 구성 요소에 대해서만 예약, 가용성 및 읽기 액세스 권한을 부여합니다.

@sesta.com^c^sfr^g
모든 소유자에게 구성 요소에 대해서만 쓰기 및 삭제 액세스 권한을 부여합니다.

@@o^c^wd^g
jsmith에게 달력 데이터에 대한 모든 액세스 권한을 거부합니다.

jsmith^a^sfdwr^d
모든 소유자에게 구성 요소 및 등록 정보를 포함하여 달력 전체에 대한 읽기, 예약 및 가용성 액세스 권한을 부여합니다.

@@o^a^rsf^g
모든 사용자에게 읽기 액세스를 부여합니다.

@^a^r^g

ACL에 ACE 배치

Calendar Server는 ACL을 읽을 때 가장 먼저 인식하는 ACE를 사용하여 대상에 대한 액세스를 부여하거나 거부합니다. 따라서 ACL의 순서가 중요하며, ACE 문자열은 보다 구체적인 항목이 보다 일반적인 항목보다 먼저 오도록 배치해야 합니다.

예를 들어, 달력 jsmith:sports의 ACL에서 최초의 ACE가 모든 사용자에게 읽기 액세스 권한을 부여한다고 가정합니다. 그리고 Calendar Server는 bjones에게 해당 달력에 대한 읽기 액세스 권한을 거부하는 두 번째 ACE를 인식합니다. 이 경우 Calendar Server는 bjones에게 해당 달력에 대한 읽기 액세스를 부여하고 충돌되는 두 번째 ACE는 무시합니다. 따라서 bjones와 같은 특정 사용자에 대한 액세스 권한이 적용되게 하려면 ACL에서 bjones의 ACE는 달력의 모든 사용자에게 적용되는 ACE와 같이 보다 일반적인 전역 항목보다 앞에 배치되어야 합니다.