나는 LDAP 서버무제한 LDAP SDK를 사용하여 LDAP 캐시를 만드시겠습니까?
항목이 존재이며 캐시에 유효한 경우 로컬 캐시를 읽을
감소 연결 시도에 다음과 같은 목표를 가진 LDAP 캐시를하고 싶습니다
LDAP에서 가져 오기
현재 LDAP를 쿼리하기 위해 무제한 LDAP SDK를 사용하고 있습니다.
몇 가지 조사를 한 후에 작동 할 수있는 영구 검색 예제를 발견했습니다. LDAP 서버에서 업데이트 된 항목은 항목을 searchEntryReturned로 전달하여 캐시 업데이트가 가능하도록합니다.
하지만 난 그게 비동기 또는 캐시 구현하는 더 나은 방법이 있기 때문에이 작업을 수행하는 방법을 확실하지 않다? 보기와 아이디어는 크게 환영합니다.
Ldap 서버는 Apache DS이며 영구 검색을 지원합니다.
프로그램은 JSF2 응용 프로그램입니다.
Apache DS는 RFC 4533에 정의 된대로 콘텐츠 동기화 컨트롤을 사용할 수 있다고 생각합니다. 이러한 컨트롤은 시스템간에 복제 또는 데이터 동기화를 구현하는 데 사용될 수 있으며 캐싱은 다소 일반적인 용도입니다. UnboundID LDAP SDK는 이러한 컨트롤 (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html)을 지원합니다. 더 적절한 지 판단하기 위해 RFC 4533에 포함 된 컨트롤과 정보를 살펴 보는 것이 좋습니다.
또 다른 방법은 Apache DS가 LDAP 변경 로그를 지원하는지 확인하는 것입니다 (예 : draft-good-ldap-changelog에 설명 된 형식). 이렇게하면 변경된 항목에 대한 정보를 검색하여 로컬 사본에서 업데이트 할 수 있습니다. 새로운 변경 사항을 찾기 위해 변경 로그를 주기적으로 폴링하여 변경 사항에 대한 정보를 자신의 페이스대로 사용할 수 있습니다 (응용 프로그램이 오프라인 상태 일 때 변경 사항을 포함하여).
영구 검색이 문제가 될 수 있지만 문제가 될 수있는 몇 가지 문제가 있습니다. 첫 번째는 업데이트 된 항목이 클라이언트로 전송되는 속도를 제어하지 못하고 서버가 클라이언트가 소비 할 수있는 것보다 빠르게 변경 사항을 적용 할 수 있으면 클라이언트를 압도 할 수 있다는 것입니다 (관찰 된 바 있습니다 많은 실제 사례에서). 두 번째는 지속적인 검색을 통해 업데이트 된 항목을 알 수 있지만 변경된 사항은 알 수 없습니다. 캐시의 경우 전체 항목의 복사본을 대체하기 때문에 큰 영향을 미치지 않을 수도 있지만 다른 경우에는 덜 바람직합니다. 또 다른 큰 문제점은 영구 검색이 검색이 활성화 된 동안 업데이트 된 항목에 대한 정보 만 반환한다는 것입니다. 어떤 이유로 클라이언트가 종료되거나 연결이 유효하지 않게되면 클라이언트가 그 상태에있는 동안 변경 사항에 대한 정보를 쉽게 얻을 수있는 방법이 없습니다.
클라이언트 측 캐싱은 여러 가지 이유로 일반적으로 좋지 않습니다.그것은 부적절한 행동을 유발하거나 잠재적으로 보안 위험을 야기 할 가능성이있는 응용 프로그램에 부실 데이터를 제공 할 수 있으며, 인증을 위해 사용하는 경우 엄청난 보안 위험이 따릅니다. 또한 모든 클라이언트가 캐시에 포함 된 데이터에 대해 동일한 수준의 액세스 권한을 가지고 있지 않으면 보안 상 위험 할 수 있습니다. 또한 각 클라이언트 응용 프로그램에 대한 캐시 구현은 확장 가능한 솔루션이 아니므로 여러 응용 프로그램에서 캐시를 공유하려고하면 전체 디렉토리 서버 인스턴스로 만들 수 있습니다. 추가 캐싱없이 원하는 부하를 처리 할 수있는 서버를 사용하는 것이 훨씬 좋습니다.
아주 좋은 설명. 음 ... 내 LDAP 서버가 실제로 localhost이고 요청하는 요청이 너무 많습니다. "이 사용자는 서기의 그룹에 있습니까?" 100 개의 LDAP 요청을 호출하는 페이지가 나오는데, 그 중 일부는 실제로 이전에 요청한 것과 동일한 요청이며 결과적으로 5 초의 페이로드가됩니다. 나는 "비 갱신 된"캐시가 문제를 일으킨다는 것을 이해합니다. 무엇을 개선해야합니까? – Tommy
일반적으로 사용자가 주어진 그룹의 구성원인지 여부를 확인하는 프로세스에는 단일 항목과 일치하는 단일 검색 작업 만 필요합니다. 정적 그룹 (예 : groupOfNames, groupOfUniqueNames 또는 groupOfEntries 객체 클래스 사용) 인 경우 대상과 동일한 값을 가진 member 속성을 대상으로하는 필터를 사용하여 항목에 대한 기본 수준 검색 만 수행하면됩니다 사용자의 DN (예 : "(member = uid = john.doe, ou = People, dc = example, dc = com)"). 동적 그룹 인 경우 사용자 항목이 범위에 있고 연관된 필터와 일치하는지 확인하십시오. –
또한 일부 디렉토리는 결정을 내리는 다른 방법을 제공합니다 (예 : 사용자가 구성원으로 속한 그룹의 DN 목록을 사용하여 사용자 항목에 동적으로 생성 된 속성). 이 경우 해당 기능을 활용하여보다 효율적이거나 편리한 결정을 내릴 수 있습니다. –