Тартылған деректер қызметтерін қолдайтын жеңіл протокол

Кіріспе

Желілік протокол, таратылған каталог ақпараттық қызметтерін қолдайды

Жеңіл каталогқа қол жеткізу протоколы (LDAP /ɛ//l//d//æ//p/) – интернет-протокол (IP) желісі арқылы таратылған каталог ақпараттық қызметтеріне қол жеткізу және оларды басқару үшін ашық, сатушыға тәуелсіз, салалық стандартты қолданба протоколы. Каталогтық қызметтер интранет және интернет қолданбаларын дамытуда маңызды рөл атқарады, себебі олар пайдаланушылар, жүйелер, желілер, қызметтер және қолданбалар туралы ақпаратты желі бойынша бөлісуге мүмкіндік береді. Мысалы, каталогтық қызметтер кез келген құрылымдалған жазбалар жиынтығын, көбінесе иерархиялық құрылыммен, мысалы, корпоративтік электрондық пошта каталогын қамтамасыз ете алады. Сол сияқты, телефондық анықтамалық – мекенжайы мен телефон нөмірі бар абоненттердің тізімі. LDAP ASN.1 сипаттау тілін пайдалана отырып, Internet Engineering Task Force (IETF) Request for Comments (RFC) деп аталатын Standard Track басылымдарының сериясында сипатталған. Соңғы нұсқасы RFC 4511 ретінде жарияланған 3-ші нұсқа (техникалық ерекшеліктерге жол картасы RFC4510-да келтірілген). LDAP-тың кең таралған қолданылуы – пайдаланушылардың логині мен парольдерін сақтау үшін орталықтандырылған орынды ұсыну. Бұл көптеген әртүрлі қолданбалар мен қызметтерге пайдаланушыларды тексеру үшін LDAP серверіне қосылуға мүмкіндік береді. LDAP X.500 стандартындағы стандарттардың қарапайым жиынтығына негізделген. Осы қатынасқа байланысты LDAP кейде X.500 lite деп аталады.

Тарих

Телекоммуникациялық компаниялардың анықтамалықтарға қойылатын талаптарды түсінуі, шамамен 70 жыл бойы телефондық анықтамалықтарды жасау және басқару тәжірибесінен кейін жақсы қалыптасқан. Осы компаниялар ақпараттық технология және компьютерлік желілерге каталогтық қызметтер ұғымын енгізді, олардың еңбегі 1980 жылдары Халықаралық телекоммуникация одағы (ITU) жариялаған X.500 толық спецификациясында жемісті болды. X.500 каталогтық қызметтеріне дәстүрлі түрде X.500 Directory Access Protocol (DAP) арқылы қол жеткізілді, бұл Open Systems Interconnection (OSI) протоколының қажеттілігін білдірді. LDAP бастапқыда X.500 каталогтық қызметтеріне қарапайым (қазір кең таралған) TCP/IP протоколы арқылы қол жеткізуге арналған жеңіл балама протокол ретінде әзірленген. Мұндай каталогқа қол жеткізу моделі DIXIE және Directory Assistance Service протоколдарынан алынған. Протоколды алғашқыда Мичиган университетінің Тим Хауес, Isode Limited компаниясының Стив Килл, Nexor компаниясының Колин Роббинс және Performance Systems International компаниясының Венгик Йонг 1993 жыл шамасында DIXIE және DAS протоколдарының ізбасары ретінде жасаған. Critical Angle Inc. компаниясының Марк Уолл, Тим Хауес және Стив Килл 1996 жылы Internet Engineering Task Force (IETF) қолдауымен LDAP-тің жаңа нұсқасы – LDAPv3 жұмысын бастады. 1997 жылы жарық көрген LDAPv3, LDAPv2-ні ескірген деп жариялады, кеңейту мүмкіндігін қосты, қарапайым аутентификация және қауіпсіздік қабатын біріктірді және протоколды X.500-нің 1993 жылғы нұсқасына сәйкестендірді. LDAPv3 спецификациясын және LDAPv3 мүмкіндіктерін кеңейтетін көптеген қосымшаларды дамыту IETF арқылы жүзеге асырылды. LDAP-тың инженерлік дамуының бастапқы кезеңдерінде ол Жеңіл каталогты шолу протоколы немесе LDBP деп аталды. Протоколдың қолданылу аясын кеңейтуге байланысты, каталогтарды іздеу және шолудан басқа, каталогтарды жаңарту функцияларын қамту үшін атауы өзгертілді. Ол өзінің «жеңіл» атауын алды, өйткені ол DAP-тың алдыңғы нұсқасы сияқты желіге көп жүктеме бермейді, сондықтан оның жолақтығы салыстырмалы түрде төмен болғандықтан, Интернетте оңай жүзеге асырылуы мүмкін. LDAP кейінгі Интернет протоколдарына, соның ішінде X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML) және Service Location Protocol (SLP) протоколдарының жаңа нұсқаларына әсер етті. Ол сондай-ақ Microsoft Active Directory-нің негізі ретінде де қолданылады.

Telecommunication companies' understanding of directory requirements were well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification, a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s. X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols. The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of Performance Systems International, circa 1993, as a successor to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the IETF. In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the Internet due to its relatively modest bandwidth usage. LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP). It is also used as the basis for Microsoft's Active Directory.

DN-ны өзгерту

DN-ді өзгерту (көшіру/атын өзгерту) жаңа RDN (Relative Distinguished Name), қажет болса жаңа аталық DN-ді және ескі RDN-мен сәйкес келетін жазбадағы мәндерді жою керек екенін көрсететін белгіні қабылдайды. Сервер бүкіл каталогтардың тармақтарын атауын өзгертуге қолдау көрсетуі мүмкін. Жаңарту операциясы атомдық: Басқа операциялар жаңа жазбаны немесе ескі жазбаны көреді. Алайда, LDAP бірнеше операциядан тұратын транзакцияларды анықтамайды: Егер сіз жазбаны оқып, одан кейін өзгертсеңіз, басқа клиент осы уақыт аралығында жазбаны жаңартуы мүмкін. Бірақ серверлер мұны қолдайтын кеңейтімдерді іске асыруы мүмкін.

Кеңейтілген операциялар

Кеңейтілген операция – бастапқы протокол спецификациясына кірмеген жаңа операцияларды анықтауға мүмкіндік беретін жалпы LDAP операциясы. StartTLS – ең маңызды кеңейтімдердің бірі. Басқа мысалдарға "Болуын тоқтату" және "Құпия сөзді өзгерту" жатады.

Тастату

Abandon операциясы серверден хабарлама ID арқылы белгіленген операцияны тоқтатуды сұрайды. Сервер бұл сұранысты орындауға міндетті емес. Abandon операциясы да, тоқтатылған операция да жауап қайтармайды. Ұқсас Cancel кеңейтілген операциясы жауаптар жібереді, бірақ барлық жүзеге асырулар оны қолдамайды.

Бұрышты босату

Unbind операциясы аяқталмаған барлық операцияларды тоқтатады және қосылымды жабады. Ол ешқандай жауап қайтармайды. Атауы тарихи себептерге байланысты берілген, және ол Bind операциясының керісі емес. Клиенттер сеансты қосылымды жабып тоқтатуға болады, бірақ Unbind қолдануы тиіс. Unbind серверге қосылымды аккуратты түрде жабуға және клиент қосылымды тастап кеткенін анықтағанша сақталатын ресурстарды босатуға мүмкіндік береді. Сондай-ақ, ол серверге жойылса болатын операцияларды жоюды және жойылмайтын операцияларға жауаптар жібермеуді бұйырады.

Сұлба

Кірістердің мазмұны кіші ағашта каталог схемасымен реттеледі, ол каталог ақпараттық ағашының (DIT) құрылымына қатысты анықтамалар мен шектеулер жиынтығы болып табылады. Каталог серверінің схемасы серверде сақталатын ақпарат түрлерін реттейтін ережелер жиынтығын анықтайды. Оның бірқатар элементтері бар, соның ішінде:
Атрибут синтаксисі – атрибутте сақталатын ақпараттың түрі туралы ақпарат береді.
Сәйкестікті анықтау ережесі – атрибут мәндерімен салыстыруды қалай жасау керектігі туралы ақпарат береді.
Сәйкестікті реттеу ережесін қолдануы – қандай атрибут түрлерін белгілі бір сәйкестікті реттеу ережесімен бірге қолдануға болатынын көрсетеді.
Атрибут түрлері – берілген атрибутқа сілтеме жасай алатын объект идентификаторын (OID) және атаулар жиынтығын анықтайды, сондай-ақ атрибутты синтаксис пен сәйкес ережелермен байланыстырады.
Объект кластары – атрибуттардың атаулы жинақтарын анықтайды және оларды міндетті және қосымша атрибуттар жиынтығына жіктейді.
Атау нысандары – жазбаның RDN-не енгізілуі тиіс атрибуттар жиынтығына арналған ережелерді анықтайды.
Мазмұн ережелері – жазбамен бірге пайдаланылатын объект кластары мен атрибуттарына қатысты қосымша шектеулерді анықтайды.
Құрылым ережесі – берілген жазбаның қандай бағынышты жазбалары болуы мүмкін екенін реттейтін ережелерді анықтайды.
Атрибуттар – каталогта ақпаратты сақтауға жауапты элементтер, ал схема атрибуттарды жазбада қолдануға болатын ережелерді, осы атрибуттардың қандай мәндері болуы мүмкін екенін және клиенттер сол мәндермен қалай өзара әрекеттесе алатынын анықтайды. Клиенттер сервердің қолдайтын схемалық элементтері туралы тиісті схемалық кіші элементтерді алу арқылы білуге болады. Схема объект кластарын анықтайды. Әрбір жазбада схемада анықталған атаулы кластар бар objectClass атрибуты болуы тиіс. Жазбаның кластарының схемалық анықтамасы жазбаның қандай нысанды білдіретінін анықтайды, мысалы, адам, ұйым немесе домен. Объект класының анықтамасы сондай-ақ мәндері болуы тиіс атрибуттар тізімін және мәндері болуы мүмкін атрибуттар тізімін анықтайды. Мысалы, адамды білдіретін жазба "top" және "person" кластарына жатуы мүмкін. "Person" класына мүше болу үшін "sn" және "cn" атрибуттарын енгізу қажет, сондай-ақ "userPassword", "telephoneNumber" және басқа атрибуттарды енгізуге рұқсат етіледі. Жазбаларда бірнеше ObjectClasses мәндері болуы мүмкін болғандықтан, әрбір жазбада ол білдіретін объект кластарының біріктірілуінен құрылған міндетті және қосымша атрибуттар жиынтығы болады. ObjectClasses мұрагерлікке ие болуы мүмкін, ал бір жазбада бірнеше ObjectClasses мәндері болуы мүмкін, олар жазбаның өзінде қол жетімді және қажетті атрибуттарды анықтайды. objectClass схемасына параллель – класс анықтамасы және объектке бағытталған бағдарламалаудағы LDAP objectClass және LDAP жазбасын білдіретін инстанция. Каталог серверлері жазбаны басқаратын каталог схемасын жазбаның Subentry операциялық атрибутымен берілген базалық DN-де жариялай алады. (Операциялық атрибут пайдаланушы ақпараты емес, каталогтың жұмысын сипаттайды және оны іздеуден тек нақты сұралған кезде ғана қайтарылады.) Сервер әкімшілері берілген схема элементтерінен басқа қосымша схема жазбаларын қоса алады. Ұйымдардағы жеке адамдарды бейнелеу схемасы ақ парақ схемасы деп аталады.

The contents of the entries in a subtree are governed by a directory schema, a set of definitions and constraints concerning the structure of the directory information tree (DIT). The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:
Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute. Matching Rules—Provide information about how to make comparisons against attribute values. Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule. Attribute Types—Define an object identifier (OID) and a set of names that may refer to a given attribute, and associates that attribute with a syntax and set of matching rules. Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes. Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry. Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry. Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have. Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values. Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry. The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent e. g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values. For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values that define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class definition and an instance in Object oriented programming, representing LDAP objectClass and LDAP entry, respectively. Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.) Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema.

Вариациялар

Сервер жұмысының көп бөлігі іске асырушыға немесе әкімшіге шешім қабылдау үшін қалдырылады. Сәйкесінше, серверлер әртүрлі жағдайларды қолдау үшін құрыла алады. Мысалы, сервердегі деректерді сақтау тәсілі нақты көрсетілмейді – сервер қарапайым файлдарды, деректер базасын пайдалануы немесе басқа серверге қақпа ретінде жұмыс істеуі мүмкін. Кіруді бақылау стандартталмаған, алайда осы бағытта жұмыстар жүргізілуде және көп қолданылатын үлгілер бар. Пайдаланушылардың парольдері олардың тізімдерінде немесе басқа жерде сақталуы мүмкін. Сервер қалаған жағдайда операцияларды орындаудан бас тартуға және түрлі шектеулер қоюға құқылы. LDAP-тың көп бөлігі кеңейтілуге жарамды. Мысалдар: Жаңа операцияларды анықтауға болады. Бақылау элементтері сұраулар мен жауаптарды өзгерте алады, мысалы, сұрыпталған іздеу нәтижелерін алу үшін. Жаңа іздеу салалары мен байланыс әдістерін анықтауға болады. Атрибуттарда олардың мағынасын өзгертетін опциялар болуы мүмкін.

Басқа деректер үлгілері

LDAP қарқынды дамыған сайын, сатушылар оны басқа қызметтерге қолжеткізу протоколы ретінде ұсынды. Іске асыру кезінде деректер LDAP/X.500 моделін имитациялау үшін қайта құрылады, бірақ бұл модельді қаншалықты дәл сақтау әртүрлі. Мысалы, LDAP арқылы SQL дерекқорына кіруге мүмкіндік беретін бағдарламалық құралдар бар, бірақ LDAP бұл мақсатқа тікелей бейімделмейді. X.500 серверлері де LDAP-ті қолдауға болады. Сол сияқты, бұрын басқа типтегі деректер сақтағыштарында сақталған деректер кейде LDAP каталогтарына көшіріледі. Мысалы, Unix пайдаланушылары мен топтары туралы ақпарат LDAP-те сақталып, PAM және NSS модульдері арқылы қолжеткізіледі. LDAP көбінесе басқа қызметтер үшін аутентификация және/немесе авторизация үшін қолданылады (куәландырылған пайдаланушы белгілі бір қызметте қандай әрекеттерді орындай алады). Мысалы, Active Directory-де Kerberos аутентификация кезеңінде, ал LDAP авторизация кезеңінде қолданылады. Мұндай деректер моделінің мысалы – GLUE схемасы, ол таратылған ақпараттық жүйеде LDAP негізінде қолданылады, бұл пайдаланушыларға, қосымшаларға және қызметтерге желілік инфрақұрылымдағы қызметтерді және олардың құрылымы мен күйі туралы қосымша ақпаратты анықтауға мүмкіндік береді.

Қолданылуы

LDAP сервері өзі орындай алмайтын сұраулар үшін басқа серверлерге сілтемелерді қайтаруы мүмкін. Бұл LDAP жазбалары үшін атау құрылымын қажет етеді, соның арқасында белгілі бір ерекше атауды (DN) сақтайтын серверді табуға болады, бұл X.500 каталогында анықталған және LDAP-те де қолданылады. Ұйымның LDAP серверлерін табудың тағы бір жолы – DNS серверлік жазбасы (SRV). example.org доменіндегі ұйым жоғары деңгейдегі LDAP DN dc=example, dc=org (мұнда dc – домен компоненті) пайдалана алады. Егер LDAP сервері де ldap.example.org деп аталса, ұйымның жоғары деңгейдегі LDAP URL-і ldap://ldap.example.org/dc=example,dc=org болады. X.500 [2008] және LDAPv3 екеуінде де негізінен екі кең таралған атау стилі қолданылады. Бұл туралы ITU спецификацияларында және IETF RFC-де құжатталған. Алғашқы нысан ең жоғарғы деңгейдегі объектіні ел объектісі ретінде қарастырады, мысалы c=US, c=FR. Домендік компонент моделі жоғарыда сипатталған модельді пайдаланады. Елге негізделген атаудың мысалы: l=Орын, ou=Бір ұйымдық бөлімше, o=Бір ұйым, c=FR, немесе АҚШ-та: cn=Жалпы атау, l=Орын, ou=Бір ұйымдық бөлімше, o=Бір ұйым, st=Калифорния, c=US болуы мүмкін.