LDAP Schema의 개념과 기본 요소

5000 단어 schema
Schema는 LDAP의 중요한 구성 부분으로 데이터베이스 모델 정의와 유사하다. LDAP의 Schema는 LDAP 디렉터리가 따라야 할 구조와 규칙을 정의한다. 예를 들어objectclass는 어떤 속성이 있는지, 이런 속성은 어떤 구조인지 등이다. schema는 LDAP 서버에 LDAP 디렉터리의 분류, 속성 등 정보를 식별하는 방식을 제공하여 LDAP 서버에 식별할 수 있도록 한다.LDAP schema에는 다음과 같은 네 가지 중요한 요소가 있습니다. 1.Objectclass Objectclass는 하나의 종류를 정의합니다. 이 종류는 다른 디렉터리 (LDAP에서 하나의 Entry) 에 사용됩니다. 이것은 이 디렉터리에 어떤 속성이 있어야 하는지, 어떤 속성이 필수적인지, 어떤 속성이 선택할 수 있는지 설명합니다.Objectclass의 정의는 이름(NAME), 설명(DESC), 유형(STRUCTURAL 또는 AUXILARY, 구조형인지 보조형인지), 필수 속성(MUST), 선택 속성(MAY) 등 정보를 포함한다.
BAP 제품에는 다음과 같은 범주가 있습니다.
# GalaxyTitle 
objectclass	( 2.16.840.1.153730.3.4.2
    NAME 'GalaxyTitle'
	DESC 'GalaxyTitle use to manage title'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		 sortid )
	)  
	
# GalaxyPost 
objectclass	( 2.16.840.1.153730.3.4.32
    NAME 'GalaxyPost'
	DESC 'GalaxyPost use to manage post'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		 sortid $ type )
	) 

# GalaxyDuty
objectclass	( 2.16.840.1.153730.3.4.22
    NAME 'GalaxyDuty'
	DESC 'GalaxyDuty use to manage duty'
    SUP top
    STRUCTURAL
        MUST ( dutyuid )
	MAY (
		 sortid )
	) 


# GalaxyGroup 
objectclass	( 2.16.840.1.153730.3.2.12
    NAME 'GalaxyGroup'
	DESC 'GalaxyGroup use to manage group'
    SUP top
    STRUCTURAL
    MUST ( uid )
	MAY (
		sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $
		email $ gfax $ others1 $ others2 $
		others3 $  uniqueMember $ searchConditionXml)
	)  



# GalaxyPeople
objectclass	( 2.16.840.1.153730.3.2.22
    NAME 'GalaxyPeople'
	DESC 'GalaxyPeople use to manage people'
    SUP InetOrgPerson
    STRUCTURAL
	MAY (
		otherDepartmentNumber  $ sortid   $  ifactivated  $  peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $  virtualaccount
	    )
	) 
	  
	
# GalaxyOrganization 
objectclass	( 2.16.840.1.153730.3.2.2
    NAME 'GalaxyOrganization'
	DESC 'GalaxyOrganization use to manage dep'
    SUP top
    STRUCTURAL
        MUST ( uid )
	MAY (
		sysid $ employeeids $ sortid $ depmanager $ telephone $
		email $ gfax $ others1 $ others2 $
		others3 $ depmanagerFilter $ title $ post)
	)  


	
# GalaxyContainer 
objectclass	( 2.16.840.1.153730.3.2.16
    NAME 'GalaxyContainer'
	DESC 'a container,can fill with people,org,group...'
    SUP top
    STRUCTURAL
        MUST ( cn )
    )    
     
# GalaxyLevel 
objectclass	( 2.16.840.1.153730.3.3.18
    NAME 'GalaxyLevel'
	DESC 'level inof'
    SUP top
    STRUCTURAL
        MUST ( cn $ number )
    )  	
    
    
# GalaxyAttOfPeople 
objectclass	( 2.16.840.1.153730.3.3.19
    NAME 'GalaxyAttOfPeople'
	DESC 'att name and sn'
    SUP top
    STRUCTURAL
        MUST ( sn $ cn )
    )      

      2. Attribute attribute는 위objectclass에 포함될 수 있는 속성입니다. 그 정의는 이름, 데이터 형식, 단일 값, 다중 값, 일치 규칙 등을 포함합니다.뒤에 구체적인 예로 설명하다.    3. Syntax syntax는 LDAP의'문법'입니다. 사실은 LDAP에서 사용할 데이터 형식과 데이터 제약입니다. 이 문법은 X.500의 데이터 제약에 따라 정의된 것입니다.정의에는 ID(X.500 준수)와 설명(DESP)이 필요합니다. 4.Matching Rules는 특정한 속성을 지정하는 데 사용되는 일치 규칙으로, 실제로는 LDAP 서버가 식별하고 정의된 속성을 일치시킬 수 있도록 특수한 Syntax의 별명을 정의하는 것이다.LDAP의 schema의 주요 요소는 바로 이것입니다. 다음은 LDAP가 규정하거나 현재 비교적 통용되는 schema를 열거했습니다. 일반적인 LDAP 서버는 이러한 정의를 식별할 수 있어야 합니다.이것이 바로 subschema라는 objectclass의 정의입니다. (2.5.20.1 NAME'subschema'AUXILIARY MAY(dITStructure Rules $nameForms $ditContentRules $objectClasses $attributeTypes $matchingRules $matchingRuleUse) 먼저 ID입니다. 여기는 2.5.20.1입니다. 이어서 NAME, AUXILIARY 설명은 보조형이고 그 다음은 선택 가능한 속성의 정의입니다.subschema에는 필수 속성이 정의되어 있지 않습니다. 정의가 필요하면 MAY와 같이 MUST () 에 속성을 놓고 $로 구분해서 속성 정의를 보십시오. (2.5.4.3 NAME'cn'SUP name EQUALITY caseIgnore Match) cn 속성의 부모 속성은name입니다.이것은 caseIgnoreMatch(정합 원칙은 EQUALITY, 그리고 SUBSTR은 문자열 정합, ORDERING는 순서 정합)와 같은 syntax 정의와 비교적 간단하다. 예를 들어 (1.3.6.1.4.1.1466.115.12.1.1.6 DESC'String') 이 정의는 1.3.6.1.4.1.1466.115.12.1.1.15.1.5는 LDAP의 문자열을 대표한다. 이 숫자열의 정의는 X.500과 관련이 있다.그것의 저장 방식, 차지하는 공간 크기 등을 포함한다.
마지막으로 Matching Rule의 예를 보면 앞에서 case Ignore Match를 언급했으니 그를 보십시오(2.5.13.2 NAME'case Ignore Match'SYNTAX 1.3.6.1.4.1.1466.115.12.15) 사실 1.3.6.1.4.1.1466.115.12.15.1.15는 LDAP 데이터 형식인 Directory String의 ID입니다. 앞의cn은 이 데이터 형식과 같아야 유효하다는 것을 설명합니다.그리고 많은 상용 schema의 정의가 RFC2252에 있습니다. LDAP 서버는 이러한 기본적인 schema를 지원해야 합니다.자, 이제 기본적으로 LDAP의 schema에 대해 대체적인 설명이 있습니다. 미흡하거나 타당하지 않은 점이 있을 수 있으니 여러분의 지적을 바랍니다.

좋은 웹페이지 즐겨찾기