ΠΟΛΙΤΙΚΗ ΕΞΟΥΣΙΟΔΟΤΗΣΗΣ ΜΟΝΑΔΩΝ & ΧΡΗΣΤΩΝ

ΥΦΙΣΤΑΜΕΝΟ ΜΟΝΤΕΛΟ ΕΞΟΥΣΙΟΔΟΤΗΣΗΣ

Βασικός άξονας στο σχεδιασμό της υπηρεσίας κτηματολογίου είναι η  πιστοποίηση – εξουσιοδότηση των χρηστών (εκπαιδευτικών) μέσω της υπηρεσίας Καταλόγου Χρηστών του ΠΣΔ (LDAP).

Η διαλειτουργικότητα- συγχρονισμός της βάσης Κτηματολογίου με την υπηρεσία Καταλόγου χρηστών στηρίζεται στην παραδοχή ότι ως αυτοτελής μονάδα, είτε εκπαιδευτική είτε διοικητική, θεωρείται η μονάδα που  έχει 7ψήφιο μοναδικό κωδικό από το Υπ. Παιδείας. Ο κωδικός αυτός είναι αυστηρά αριθμητικός με εξαίρεση τα Ε. Κ (εργαστηριακά κέντρα).

Για την ταυτοποίηση και εμφάνιση των στοιχείων του χρήστη το κτηματολόγιο συνδέεται με την υπηρεσία SSO προκειμένου να επιστραφούν στοιχεία από το profile του χρήστη, όπως είναι τα παρακάτω :

• givenName ως το μικρό όνομα του χρήστη
• sn ως το επώνυμο του χρήστη
• accountStatus υποχρεωτικά τιμή "active", αλλιώς απορρίπτει το χρήστη

Για την εξουσιοδότηση –δικαιώματα του χρήστη, ο έλεγχος γίνεται κάθε φορά που κάποιος χρήστης κάνει login στην υπηρεσία.

Για κάθε μονάδα έχουν ήδη αρχικοποιηθεί 3 ομάδες (groups)

• ΕΙΣΑΓΩΓΗ
• ΔΙΑΧΕΙΡΙΣΗ
• ΑΠΟΓΡΑΦΗ
  

Τα μέλη κάθε ομάδας λαμβάνουν και τους αντίστοιχους ρόλους.

Για τους χρήστες που ήδη έχουν ενεργοποιήσει τους ρόλους ΕΙΣΑΓΩΓΗ ΔΙΑΧΕΙΡΙΣΗ ΑΠΟΓΡΑΦΗ, το Κτηματολόγιο συγχρονίζει τις "ομάδες" από τα πεδία 'memberOf' και 'isMemberOf' (για ιστορικούς λόγους προστέθηκε και το τελευταίο) τα οποία παραπέμπουν σε ομάδες με ονόματα:

• Import_ktim για δικαιώματα "Εισαγωγής"
• administration_ktim για δικαιώματα "Διαχείρισης
• inventory_ktim για δικαιώματα "Απογραφής"

Οι συνδυασμοί δικαιωμάτων που επιτρέπονται είναι οι ακόλουθοι:

 "ΕΙΣΑΓΩΓΗ + ΔΙΑΧΕΙΡΙΣΗ"

"ΕΙΣΑΓΩΓΗ + ΔΙΑΧΕΙΡΙΣΗ + ΑΠΟΓΡΑΦΗ"

“ΔΙΑΧΕΙΡΙΣΗ + ΑΠΟΓΡΑΦΗ"

Ο συνδυασμός "ΕΙΣΑΓΩΓΗ + ΑΠΟΓΡΑΦΗ" , χωρίς τον ενδιάμεσο ρόλο "ΔΙΑΧΕΙΡΙΣΗ", ΔΕΝ επιτρέπεται, εφόσον δεν έχει λειτουργικό νόημα.

ΝΕΟ ΜΟΝΤΕΛΟ ΕΞΟΥΣΙΟΔΟΤΗΣΗΣ ΧΡΗΣΤΩΝ

Με στόχο τη βελτίωση αλλά και την ευελιξία της υπηρεσίας, προβλέφθηκε νέος μηχανισμός, βασισμένος στο πεδίο "gsnUserRoleOn" που βρίσκεται στο object του χρήστη. Η λύση αυτή αξιοποιεί ρόλους που αποδίδονται στο χρήστη και αποφεύγεται η χρήση των ομάδων, που επιπλέον προκαλούσε αυξημένο φόρτο στον directory sever του ΠΣΔ.

Με τον τρόπο αυτό το attribute  "gsnUserRoleOn" μεταβάλλεται  ανάλογα με την ομάδα δικαιωμάτων,

πχ. subtype "gsnUserRoleOn;import-ktim" και τιμή απευθείας το DN της μονάδας στην οποία αναφέρεται το δικαίωμα χρήσης. Αντίστοιχα λοιπόν με τη λειτουργία του "memberOf" , οι ρόλοι μεταφέρθηκαν στο object του χρήστη με τα παρακάτω ονόματα

• "import-ktim"
• "adminstration-ktim"
• "inventory-ktim"

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

Ακολουθεί παράδειγμα της απόδοσης ρόλων μέσου του attribute gsnUserRoleOn, όπου στο χρήστη αποδίδεται ο ρόλος της ΕΙΣΑΓΩΓΗΣ για 2 σχολεία (1ο + 2ο ΛΥΚΕΙΟ ΓΑΛΑΤΣΙΟΥ) και ο ρόλος της ΔΙΑΧΕΙΡΙΣΗΣ μόνον για το 1ο ΛΥΚΕΙΟ ΓΑΛΑΤΣΙΟΥ

gsnuserroleon;import-ktim : 2lyk-galats.att.sch.gr

gsnuserroleon;import-ktim : 1lyk-galats.att.sch.gr

gsnuserroleon; adminstration-ktim : 1lyk-galats.att.sch.gr

Σε αυτό το μηχανισμό έχουν προστεθεί και 2 νέοι ρόλοι με σκοπό να καλυφθούν οι ανάγκες κεντρικών διοικητικών δομών που καλούνται να παρακολουθούν τα στατιστικά δείγματα του ΤΠΕ εξοπλισμού των υπό τη δικαιοδοσία τους μονάδων.

• "reports-ktim" για χρήστες "επόπτες" που θα βλέπουν αναφορές μόνο πχ Yπουργείο Παιδείας
  
• "support-ktim" για χρήστες κέντρων υποστήριξης, όπως τα Helpdesks και τα ΚΕ.ΠΛΗ.ΝΕ.Τ
  

Οποιοδήποτε άλλο όνομα ομάδας θεωρείται ότι δεν αναφέρεται στο Κτηματολόγιο αγνοείται.

Από τα δικαιώματα χρηστών, λοιπόν, χρησιμοποιείται ως κλειδί το DN των μονάδων, ώστε αυτά να αντιστοιχιστούν σε Μονάδες του ΠΣΔ, σύμφωνα με τον κατάλογο χρηστών.

Ο συγχρονισμός των μονάδων γίνεται μαζικά, σε τακτά διαστήματα. Βασίζεται σε αναδρομή του δέντρου κάτω από το "ou=units,dc=sch,dc=gr", με αλγόριθμο που αναζητά τμηματικά, επανασυνδέεται και επιμένει όταν οι LDAP servers έχουν μεγάλες καθυστερήσεις.

ΕΠΙΤΡΕΠΟΜΕΝΟΙ ΤΥΠΟΙ ΜΟΝΑΔΩΝ

Ελέγχεται ο "τύπος" μονάδας, όπως προκύπτει από το συνδυασμό των πεδίων "dept_types" και "title". Οι επιτρεπόμενοι συνδυασμοί είναι οι ακόλουθοι:

ΕΛΕΓΧΟΣ ΜΟΝΑΔΙΚΟΥ ΚΩΔΙΚΟΥ ΜΟΝΑΔΑΣ

Έπειτα από τον τύπο μονάδας, ελέγχεται το gsnUnitCode (Κωδικός ΥπΕΠΘ) τους. Μονάδες χωρίς gsnUnitCode ΔΕΝ συγχρονίζονται. Το gsnUnitCode επιτρέπεται να είναι επταψήφιος αριθμός ή της μορφής "SEKddd" (d= αριθμητικό ψηφίο), αλλιώς θεωρείται άκυρο και η μονάδα ΔΕΝ συμμετέχει στο Κτηματολόγιο.
Ειδικά τα gsnUnitCodes "0000000" και "1111111" βρίσκονται σε "μαύρη λίστα" και θεωρούνται μη έγκυρα για την ταυτοποίηση μονάδων. Όμως, οι μονάδες αυτές συμμετέχουν στο Κτηματολόγιο.

ΕΛΕΓΧΟΣ ΚΑΤΑΣΤΑΣΗΣ ΚΑΙ ΕΓΚΥΡΟΤΗΤΑΣ ΜΟΝΑΔΑΣ

Ελέγχεται και η τιμή του accountStatus για να διαπιστωθεί η κατάσταση και εγκυρότητα κάθε μονάδας:

• ΕΝΕΡΓΗ: σημαίνεται ως ενεργή
• ΛΕΙΤΟΥΡΓΙΑ: σημαίνεται ως ενεργή
• ΥΠΟ ΑΝΑΣΤΟΛΗ: σημαίνεται ως ανενεργή. Δεν επιτρέπεται πρόσβαση χρηστών σε αυτές.
• ΥΠΟ ΚΑΤΑΡΓΗΣΗ: αφαιρείται από το Κτηματολόγιο
• ΚΑΤΑΡΓΗΜΕΝΗ: αφαιρείται από το Κτηματολόγιο
• ΑΓΝΩΣΤΗ ΜΟΝΑΔΑ: αφαιρείται από το Κτηματολόγιο

Οι μονάδες που πληρούν τα παραπάνω κριτήρια, διασταυρώνονται με αυτές που ήδη έχει (από προηγούμενο συγχρονισμό) το Κτηματολόγιο, βάσει του DN, του gsnUnitCode και του ονόματος ώστε να εντοπιστούν τυχόν διπλοεγγραφές και αν η κάθε μονάδα πρέπει να προστεθεί στο Κτηματολόγιο ή να ενημερώσει μια υπάρχουσα εγγραφή.

Κάθε ανωμαλία στον συγχρονισμό καταγράφεται σε αρχείο (logs), ώστε να εξεταστεί από τους διαχειριστές.