programing

LDAP는 무엇을 해결합니까?

nasanasas 2020. 12. 5. 09:54
반응형

LDAP는 무엇을 해결합니까?


나는 내가 참여한 많은 프로젝트에서 LDAP와 연락을 해왔지만 사실은 그것을 이해하지 못한다. 나는 그것이 사람 디렉토리라고 생각했지만 계층 구조의 모든 객체를 포함 할 수 있음을 발견 한 후.

상자에 openldap을 설치했고 설치와 관련된 많은 자습서를 찾았습니다.

LDAP 란 무엇입니까? LDAP가 올바른 선택 인 시나리오는 무엇입니까? 작업을 위해 알아야 할 LDAP 개념은 무엇입니까? LDAP의 장점은 무엇입니까? 오래된 응용 프로그램에서 사용했기 때문에 사용됩니까? 이 모든 질문을 설명하는 좋은 문서가 인터넷 어디에나 있습니까?

업데이트 : 대답 보완하기 나 같은 LDAP 초보자를위한 빠른 시작 안내서가 포함 된 이 링크찾았 습니다.


LDAP 란 무엇입니까? LDAP가 올바른 선택 인 시나리오는 무엇입니까?

핵심에서 LDAP는 디렉토리의 저장에 적합한 개체에 액세스하기위한 프로토콜입니다. 어떤 것이 "적합"한지 여부는 구현 자에게 맡겨진 전적으로 주관적인 결정이지만 일반적으로 이는 각각 데이터를 자주 업데이트하지 않거나 전혀 업데이트하지 않는 많은 객체 모음을 의미하며 , 여기서 각 객체는 조회 할 수있는 명백한 방법 또는 표준적인 방법이 있습니다.

  • 전화 번호부 (이름 또는 전화 번호로 조회)
  • 라이브러리의 제목 (제목, 저자 등으로 조회)
  • 건물의 세입자 (층, 스위트, 이름 등으로 조회)

등등.

LDAP 자체는 프로토콜 일 뿐이며 실제 저장소를 제공하지 않습니다. 거의 동일한 방식으로 HTTP는 Apache, Jetty, Tomcat, Mongrel 등을 사용하는지 여부에 대한 어떤 것도 암시하지 않습니다. 웹 서버로. (일반적으로 LDAP의 한 가지 문제점은 다른 것을 의미하기 위해 이름을 혼란스럽게 재사용하는 것입니다. Wikipedia에는 ​​이에 대한 좋은 섹션 이 있습니다.)


DIT는 B-Tree 알고리즘에 매우 잘 어울리는 계층 적 설명 체계로, 대부분의 경우 엄청난 검색 성능을 제공합니다. OpenDS와 같은 Directory Server는 마이크로 초 내에 색인화 된 검색을 반환하는 반면 RDBMS 시스템은 훨씬 느립니다. 디렉토리 서버 (일반적으로 LDAP 서버라고 함)는 빠른 읽기 응답을 위해 자원 (RAM, CPU)을 교환합니다. RDBMS 시스템은 해당 데이터 관리 측면에서 더 큰 기능을 제공합니다. 업데이트가 거의 없거나 전혀없는 속도, 단순성 및 소규모 네트워크 프로토콜이 필요하십니까? 디렉토리 서버를 사용하십시오. 데이터 관리 및 마이닝 기능, 그리고 / 또는 데이터간에 정의 된 관계형 측면과 함께 데이터베이스의 높은 변화율이 필요하십니까? RDBMS를 사용하세요 (MySQL이 최선의 선택입니다).


LDAP는 O (1) 읽기 성능을 가지고 있으며 O (더 나쁜) 쓰기 성능을 제공합니다. 자주 액세스하지만 거의 변경되지 않는 데이터 (사람, 컴퓨터 이름 및 주소 등)에 이상적입니다. (따라서 약어 : Lightweight Directory Access Protocol.)

LDAP는 개발자 친숙도 감소 및 이상한 성능 특성 측면에서 관계형이 아닌 데이터베이스를 사용하는 데 따르는 어려움이 눈에 띄게 빠른 읽기 액세스의 이점보다 적은 올바른 선택입니다.


내가 생각하고 싶은 한 가지 관점은 LDAP는 지속성 저장소 위에있는 앱이고 데이터베이스는 지속성 저장소라는 것입니다. 둘 다 사용자 정보를 저장하는 데 사용할 수 있습니다.

LDAP는 데이터베이스에서하기 어려운 계층 구조를 제공합니다. 데이터베이스에서 계층 구조를 만들 수 있지만 위임 (이 행은 사용자에게만 속함) 또는 행의 ACL과 같은 작업을 수행하기가 더 어렵습니다. 따라서 LDAP를 사용하여 사용자 ID를 저장하는 경우 보안 문제를 데이터베이스 외부로 밀어내는 것이 더 쉽습니다. 데이터베이스에서 문제를 해결하려는 시도는 이상합니다.

동시에 LDAP는보고에 대해 끔찍합니다 (보고를 위해 LDAP를 DB로 변환). 빠르게 검색해야하는 속성을 트리 깊숙이 저장하는 것은 성능에 문제가 될 수 있습니다 (이렇게하지 말고 DB를 옆에 두거나 DIT를 재 설계하여 쿼리를 평평하게 만드십시오). 정말 깊은 DIT에 속성을 사방에 저장하는 것은 잘못된 LDAP 또는 시스템 디자인이지만 공급 업체 제품이나 레거시 앱에 연결되어있는 경우 피할 수없는 경우도 있습니다.


이 링크는 LDAP http://blogs.oracle.com/raghuvir/entry/ldap에 대해 설명합니다.

회사 전체의 이메일 주소 조회를 위해 사무실에서 LDAP를 사용합니다. 내부 앱에 대한 단일 소스 사인온 서비스로도 사용합니다.


저는 파트 타임으로 일하고 있으며 풀 타임 학생입니다. 제 커리큘럼은 많은 그룹 프로젝트를 권장합니다 (읽기 필요).

OpenLdap과 phpLdapAdmin을 사용하여 Subversion 및 Mercurial 저장소, Trac 프로젝트, Hudson 등에 대한 액세스를 제어했습니다. 설치가 쉽지는 않았지만 관리 시간을 절약 할 수있는 시간은 하나님이 보내 주셨습니다.

다른 리소스를 사용할 수 있어야하는 많은 그룹의 사람들이있는 프로젝트가 있다면 좋은 도구입니다.


LDAP는 프로토콜 일 뿐이며 위키피디아 기사에서 적절하게 설명합니다. http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

Microsoft의 Active Directory와 같은 기본 조직 구조를 쿼리하는 방법입니다. LDAP 쿼리를 사용하여 사용자에 대한 모든 종류의 정보를 얻고 응용 프로그램 권한을 설정하는 데 사용할 수 있습니다.


LDAP는 액세스 프로토콜입니다. 응용 프로그램을 찾으려는 기본 기술 ( 디렉토리 서비스) 에만 API를 제공 합니다. OpenLDAP는 오픈 소스 디렉토리 서비스 중 하나입니다. Sun에는 OpenDS라는 또 다른 구현이 있습니다. Active Directory와 Novell NDS는 현장에서 흔히 볼 수있는 또 다른 두 가지입니다.

디렉터리는 모든 종류의 리소스에 대한 정보와 리소스 간의 관계 (예 : 디렉터리, 프린터 또는 네트워크 액세스 장치에 대한 사용자의 권한)를 저장하는 데 사용할 수 있습니다.


이 링크를 참조하십시오 :

http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/1.html#RTFToC1

LDAP를 깊이 설명합니다.

예를 들어 해당 문서에서이 이미지를 볼 수 있습니다.


(출처 : dirsvcs at www.umich.edu )


예전 직장 중 하나에서는 LDAP 를 기본 사용자 인증 시스템으로 사용했습니다.

이것은 차례로 우리의 다양한 시스템에 부서 정보를 제공했습니다. 그들은 소속되어 있으며, 홈 디렉토리, 연락처 정보, 직원 관리를 마운트해야합니다.

반드시 LDAP에 의해 제어되는 것은 아니지만 LDAP를 통해 작업하기 위해 혼합 한 다른 것들은 SQL 사용자, K4, 삼바 및 이메일 계정 생성의 존재였습니다.


이 모든 질문을 설명하는 좋은 문서가 인터넷 어디에나 있습니까?

IBM은 LDAP에 대한 훌륭한 Red Book을 출판했습니다. 제목은 LDAP 이해-설계 및 구현 입니다.

It can be downloaded from the previous link.

참고URL : https://stackoverflow.com/questions/884604/what-does-ldap-solve

반응형