ㅎㅎ. 요즘 한가해서인지 자주오네요.

문의 하신 내용은 설계적인 측면에서 바라보면 앞뒤가 바뀐 질문이십니다.

LDAP 서비스를 구상하고 구현 할때 4단계(가지)의 검토(설계) 과정이 필요하다고 합니다.

1. infimation modelling

2. Naming Modelling

3. Functional Modelling

4. Security Modelling

제일 먼저 서버스의 목적, 내용, 대상 등에 대한 고려와 이에 필요한 정보들을 나열하고, 이 정보들을

체계적으로 사용 할수 있게끔 스키마를 정의 합니다. 그리고 이 정보들을 어떻게 CRUD 할것인지에 대해서도 고민 합니다.

다음으로 이 정보들을 LDAP 내에서 어떻게 배치 할것인가를 고민해야 합니다. 조직 밑에 사용자를 둘것인가? 별도의 노드로 분리하는가? 조직의 레벨을 어떻게 관리할것인가?

다음은 실제 수집 관리되는 정보로 어떤 서비스를 어떻게 제공할 것인가를 고민합니다, 수집된 정보중 어떤 정보를 인증용으로 , 어떤 정보를 어떤 app 에서 어떻게 활용하게 할것인가를 고민합니다, 이때 배포용API 를 생성하기도 합니다.

다음으로는 LDAP 서비스의 레벨을 고민합니다, 어떤 사람, 그룹, IP, 시간 등등에  어떤 정보를 얼만큼 제공할것인지 고민하여 결정 합니다,

이런 과정으로 볼때 여쭈어보신 내용은 일단 만들고 어디에 쓸까를 고민하시는 상황이지요. 발명가가 무언가를 만들긴 했는데 어디에 쓸지를 모르는 상황.

***

상하위 부서 코드(ID)가 필요한 경우 LDAP 순수 기능에서는 전혀 필요없습니다.  상위 부서 정보는 이미 해당 DN 에 명시되어 있고, 하위부서 정보는 검색하면 되니까요. 통상  RDBMS 에서 개발되어진 APP 환경에서 저장소를 LDAP 으로 변경하는 경우 해당 엔트리에 상하위 부서 정보를 넣습니다,

***

부서 하위 조직목록을 부서 정보에 넣는 경우는 위에 내용과 비슷합니다, LDAP 으로의 전환이 이루어진 환경에서는 필요할수도 있지만 통상 이런 경우는 설계 오류 입니다.  실 현업에서는 RBAC 기능이 없는 ( 혹은 있더라도 LDAP 으로 구성되어있지 않는 ) 권한 관리 시스템에서 요구하는 경우가 있습니다.

 도움에 감사드립니다. 전혀 개념을 못잡다가 이제 조금씩 구체적이 되었습니다. 

하나 더 여쭈고 싶습니다.

노드의 깊이를

최상위노드-부서깊이1-부서깊이2-부서깊이3-사람1,사람2,사람3  

형태와

최상위노드-조직도-부서깊이1-부서깊이2-부서깊이3

최상위노드-멤버-사람1,사람2,사람3 

형태로 구성을 하면 주로 어떤 장점을 가졌는지요? 

첫번째 형태는 구조적으로는 명확하지만 처리에서 문제가 있을수 있겠고

두번째 형태는 사람1, 사람2 등에 대한 권한을 주기에 명확할듯 한데 

어떤 장점이 있는지 잘모르겠습니다. 주로 어떤용도로 사용을 하는지요?

글쓰기가 안되네요.. ㅎㅎㅎ

첫 방식은 정보의 viewing 관리에 좀더 손쉬운 방식이며 논리적으로 함당한 배치 방법입니다만,

조직명의 변경, 사람의 겸직, 전입 및 전출 관리에 좀더 높은 프로그램 복잡도가 필요합니다.

두번재 방식이 흔히 사용되는 방식입니다만, 적당한 부서 깊이별로 멥버를 배치하는 절충적인 방법이

사람의 수가 많을때 발생하는 관리상의 문제점 및 예기치 않은 시스템 부하를 예방합니다.