Project

General

Profile

History

Κεντρικός Κατάλογος Χρηστών

Ο κατάλογος είναι υλοποιημένος ως ένα LDAP directory με openldap. Στη συνέχεια ακολουθούν πληροφορίες σχετικά με τη δομή του καταλόγου και τον τρόπο με τον οποίο συνδέεται με τους καταλόγους των Ινστιτούτων.

Σύνδεση καταλόγων των Ινστιτούτων με τον κεντρικό Κατάλογο.

Ο τρόπος με τον οποίο οι πληροφορίες των χρηστών των Ινστιτούτων είναι προσβάσιμες μέσω του Κεντρικού καταλόγου εξαρτάται από τον τύπο LDAP directory που έχει ήδη υλοποιημένο το εκάστοτε Ινστιτούτο. Υποστηρίζονται οι εξής περιπτώσεις directories Ινστιτούτων:

  • Δεν υπάρχει υλοποιημένο LDAP directory:
    Στην περίπτωσή αυτή οι λογαριασμοί των χρηστών δημιουργούνται κατευθείαν στο Κεντρικό LDAP. (οδηγίες).
  • OpenLDAP directory:
    Όταν υπάρχει OpenLDAP directory υλοποιημένο τότε μπορεί να ακολουθηθεί μία από τις δύο παρακάτω λύσεις:
    • Αντιγραφή (openldap replication) στο κεντρικό OpenLDAP.
    • Ρύθμιση του κεντρικού openldap ώστε να λειτουργεί ως ldap proxy για το συγκεκριμένο directory (οδηγίες).
  • Microsoft Active Directory:
    Το Active Directory έχει κάποιες ιδιαιτερότητες σε σχέση με τα LDAP standards:
    • Ελαφρώς διαφορετική δομή του καταλόγου
    • Διαφορετικό format των passwords με αποτέλεσμα να μην είναι δυνατή η αντιγραφή τους στο OpenLDAP.
      Για τους παραπάνω λόγους γίνεται
    1. Συγχρονισμός (one-way) των πληροφορίων του Active Directory με το κεντρικό Directory μέσω ειδικού utility (java).
    2. Χρήση της υπηρεσίας Password Synchronization του Identity Management for Unix component που προσφέρει η Microsoft στα Windows Server 2003. Η υπηρεσία αυτή δίνει τη δυνατότητα όταν κάποιος χρήστης αλλάζει το password του στο Active Directory να ενημερώνεται αυτόματα και το αντίστοιχο password στο OpenLdap.
      Θα πρέπει να τονιστεί το εξής: Ακόμα και με χρήση του Password Syncrhonization Service δεν είναι δυνατός ο συγχρονισμός των ήδη υπάρχοντων passwords. Άρα οι χρήστες πριν μπορέσουν οι χρήστες να χρησιμοποιήσουν τις υπηρεσίες που προσφέρονται μέσω της AAI υποδομής του ΑΘΗΝΑ θα πρέπει να προβούν σε μία αλλαγή του password τους. Σημειώνεται πως αυτό χρειάζεται να γίνει μόνο μία φορά από τότε που θα στηθεί για πρώτη φορά το Password Synchronization service και ο συγχρονισμός Active Directory με LDAP ώστε να πρωτοδημιουργηθεί το αντίστοιχο userPassword Attribute στο OpenLDAP.
      Για οδηγίες σχετικά με υλοποίηση του συγχρονισμού δείτε εδώ

Σε όλες τις παραπάνω περιπτώσεις συνιστάται να μη γίνεται συγχρονισμός ή replication ολόκληρου του τοπικού Directory tree αλλά ενός ή περισσοτέρων subtrees του που να περιέχουν μόνο τους πραγματικούς χρήστες του Ινστιτούτου. Με τον τρόπο αυτό γίνεται προσπάθεια να μη δημιουργούνται στο κεντρικό directory system users και groups που δεν έχουν νόημα εκτός του εσωτερικού περιβάλλοντος του Ινστιτούτου.

Δομή και attributes του κεντρικού καταλόγου.

Δομή καταλόγου

O κατάλογος χρησιμοποιεί ως base DN το dc=athena-innovation,dc=gr. Ολόκληρος ο κατάλογος του κάθε ινστιτούτου βρίσκεται κάτω από ξεχωριστό Organization Unit, π.χ. οι χρήστες του ΙΠΣΥΠ βρίσκονται όλοι κάτω από το ou=imis,dc=athena-innovation,dc=gr. To OU κάθε ινστιτούτου προκύπτει από το αρχικά της επωνυμίας του στα Αγγλικά.

Με βάση και την περιγραφή της δομής του κεντρικού directory όπως αυτή δόθηκε παραπάνω, ο συγχρονισμός/replication/proxying τωv directories γίνεται ως εξής:
  1. Στο κεντρικό OpenLDAP Δημιουργείται ένα ξεχωριστό ldap database με baseDN dc=institude_name,dc=athena-innovation,dc=gr. (σημείωση: Αν για κάποιο λόγο (π.χ. κάποια διαφορετική χρήση του ldap) κάποιο Ινστιτούτο επιθυμεί να έχει διαφορετικό baseDN π.χ. dc=ipsyp,dc=gr), αυτό είναι δυνατόν.) Εκεί αντιγράφονται/δημιουργούνται τα records του κάθε Ινστιτούτου. Σε αυτή την ldap database οι διαχειριστές μπορούν αν επεξεργάζονται τις εγγραφές τους.
  2. H κεντρική ldap database που χρησιμοποιείται είναι απλώς μία meta database που διαβάζει τις εγγραφές από τις επιμέρους ldap databases με read only δικαιώματα προσφέροντας έτσι ένα επιπλέον επιπεδο ασφάλειας. Η meta database αλλάζει τα DNs των εγγραφών ώστε οι εγγραφές που ήταν στο *dc*=intitute_name,dc=athena-innovation,dc=gr να εμφανίζονται ως κάτω από το *ou*=institute_name,dc=athena-innovation,dc=gr.
  3. Είναι δυνατόν στην κεντρική meta database να γίνονται διάφορα attributes massages ώστε να επιτυγχάνεται η επιθυμητή ομοιογένεια των δεδομένων στο τελικό directory.
Για κάθε Ινστιτούτο και αντίστοιχο OU δημιουργούνται 2 χρήστες:
  • cn=ldapadmin,ou=institute_name,dc=athena-innovation,dc=gr. Ο χρήστης ldapadmin έχει πλήρη δικαιώματα σε όλο το subtree του Ινστιτούτο (αλλά μόνο σε αυτό) και προσφέρεται για τη διαχείριση των εγγραφών από τους διαχειριστές του Ινστιτούτου.
  • cn=ldapbind,ou=institute_name,dc=athena-innovation,dc=gr. O χρήστης ldapbind έχει δικαίωμα να διαβάσει όλα τα attributes όλων των χρηστών (εκτός του password). Προσφέρεται για εφαρμογές που χρειάζεται να κάνουν bind στο directory ώστε να το χρησιμοποιήσουν καθώς δεν υποστηρίζεται το anonymoys bind.

Attributes

Για να είναι αξιοποιήσιμες οι πληροφορίες που βρίσκονται στον κατάλογο πρέπει να είναι ομοιογενείς. Έχουν λοιπόν καθοριστεί κάποιες απαιτήσεις σχετικά με τα attributes που πρέπει να έχουν οι εγγραφές των καταλόγων και τις επιτρπτές τιμές των attributes αυτών. Οι περισσότερες από αυτές προκύπτουν από τις απαιτήσεις για τη συμμετοχή του Ερευνητικού Κέντρου στην Ομοσπονδία του ΕΔΕΤ σε συνδυασμό με επιλογές που έχουν γίνει από το ΑΘΗΝΑ.
Στη συνέχεια περιγράφονται τα attributes που πρέπει υποχρεωτικά να υπάρχουν σε όλες τις εγγραφές χρηστών του καταλόγου του ΑΘΗΝΑ. Για περισσότερες πληροφορίες για άλλα attributes που αναγνωρίζονται στην Ομοσπονδία δείτε το κείμενο πολιτικής και διαδικασιών του ΕΔΕΤ, και για την αντιστοίχισή τους σε attributes του Active Directory ή του Shibboleth εδώ.

LdapSchema Attribute Τιμή Παράδειγμα
RFC 2798 displayName Oνοματεπώνυμο Panagiotis Georgantas
RFC 4519 cn Oνοματεπώνυμο Panagiotis Georgantas
RFC 4519 givenName Όνομα Panagiotis
RFC 4519 surnName Επώνυμο Georgantas
RFC 4519 ο Research Center ATHENA
RFC 4519 ou Πλήρης επωνυμία του Ινστιτούτου στα Αγγλικά Institute for the Management of Information Systems
SCHAC schacHomeOrganization athena-innovation.gr
Eduperson eduPersonPrincipalName
Eduperson eduPersonAffiliation Ένα από faculty,student,staff,alum,member,affiliate,employee member
Eduperson eduPersonOrgDN dc=athena-innovation,dc=gr
Eduperson eduPersonOrgUnitDN ou=INSTITUTE,dc=athena-innovation,dc=gr ou=imis,dc=athena-innovation,dc=gr
Eduperson eduPersonPrimaryOrgUnitDN ou=INSTITUTE,dc=athena-innovation,dc=gr ou=imis,dc=athena-innovation,dc=gr
Όπως φαίνεται από τα παραπάνω γίνεται έντονη χρήση του eduPerson σχήμα, καθώς επίσης χρήση και του SCHAC σχήματος. Καθώς τα σχήματα αυτά δεν είναι διαθέσιμα by default στους LDAP servers δίνεται η δυνατότητα να προστίθενται αυτόματα στο κεντρικό directory. Παρόλα αυτά συστήνεται να εγκαθίστανται στους καταλόγους των Ινστιτούτων και να μπαίνουν τιμές στα πεδία τους σε κάθε τοπικό κατάλογο
  1. Για να υπάρχει consistency των δεδομένων
  2. Γιατί υπάρχουν attributes όπως το eduPersonAffiliation που δεν είναι συνήθως δυνατόν να παίρνουν αυτόματα τιμές.

Οδηγίες για την εγκατάσταση του EduPersonSchema και των σχετικών Propery pages μπορείτε να βρείτε εδώ.

Ομοίως και τα υπόλοιπα attributes που δεν ακολουθούν τις απαιτήσεις του κεντρικού καταλόγου δίνεται η δυνατότητα να διορθώνονται αυτόματα αλλά συστήνεται να αλλάζουν στο source directory.