Υπηρεσία ενιαίας πρόσβασης (SSO) - Οδηγίες
Η σύνδεση μιας υπηρεσίας με την υπηρεσία ενιαίας ταυτοποίησης του ΕΜΠ προϋποθέτει την υποβολή αίτησης σύνδεσης service provider (SP) στο Κέντρο Δικτύων του ΕΜΠ. Για τη ρύθμιση του SP, ο τεχνικός διαχειριστής απαιτείταινα έχει καλή γνώση της τεχνολογίας Single Sign-On, και συγκεκριμένα των εννοιών Identity Provider (IdP), Service Provider (SP), και SAML2.0. Ακολουθούν τα βήματα εγκατάστασης και ρύθμισης του SP.
Βήμα 1: Εγκατάσταση SP
Η εγκατάσταση του SP μπορεί να γίνει είτε με το πακέτο του Shibboleth, είτε του simpleSAMLphp. Το ΚΕΔ έχει αναπτύξει και παρέχει στην κοινότητα του ΕΜΠ ένα Debian docker, το οποίο εκτελεί αυτόματα τα περισσότερα βήματα εγκατάστασης και είναι ήδη παραμετροποιημένο να χρησιμοποιεί τον IdP του Πολυτεχνείου.
Ο διαχειριστής του SP πρέπει να επιλέξει ένα νέο, μοναδικό entityID για την εγκατάσταση του SP (συνήθως με URL της μορφής: https://www.my-smd.gr/shibboleth) και να αρχικοποιήσει το certificate/key pair που θα χρησιμοποιηθεί για την υπογραφή των metadata και την κρυπτογράφηση της επικοινωνίας. Στην περίπτωση του NTUA docker, αυτά ορίζονται στο αρχείο shibboleth2.xml και ειδικότερα στα elements ApplicationDefaults και CredentialResolver.
Σε περίπτωση κατά την οποία δε χρησιμοποιείται το docker, τα metadata του IdP του ΕΜΠ είναι διαθέσιμα εδώ, ενώ το certificate που πρέπει να χρησιμοποιηθεί για την επιβεβαίωση της υπογραφής τους είναι το παρακάτω:
-----BEGIN CERTIFICATE----- MIIDFDCCAfygAwIBAgIJAJYtSBg4TN0WMA0GCSqGSIb3DQEBBQUAMBgxFjAUBgNV BAMTDWxvZ2luLm50dWEuZ3IwHhcNMjQwNDAzMTAwMTA4WhcNMzQwNDAxMTAwMTA4 WjAYMRYwFAYDVQQDEw1sb2dpbi5udHVhLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA9PPd/C1Smrn+DH1bYdJ24qqvA7aDt7izs/c9bmsF1/zOumIj 3Tmi9V/zmeNt2yiV/Nva2ZU3M/cTUxZST7XYWz+758EyqmvKVvHgyOmmF8JdV+9r hFT3R3DEdDnGnep4N7QZySOQ/mOp3IsY2Wxqka3NU672keZq/VhV/B1MPDqhqPGt TPeW/NJGjo2UrMKkeyJLCHQJeNbKOOSzefc5TJYFJHLXqGs7DWIXwqqab0MPJ3Na N7Ap0SEIZWpNS7u/lAAS//1HJQ26zW15GcUhxgi2pMk3GHs6uwWF+DYLEbWg17MQ Er9MFbftJjf9V4GOfUILDvgNlutCPnmM6aB4gQIDAQABo2EwXzA+BgNVHREENzA1 gg1sb2dpbi5udHVhLmdyhiRodHRwczovL2xvZ2luLm50dWEuZ3IvaWRwL3NoaWJi b2xldGgwHQYDVR0OBBYEFNP8/C26TomQ3yAZFMY2W84V40ihMA0GCSqGSIb3DQEB BQUAA4IBAQCERyUECGPGRBHRnRZK/AEupGmgAyNAIjN+j6kW2MHKKRdRTvdvvd3R 7yLSMWOt0Py1bPLTqhT4IJjqFbiQ14wmtpqpFfMoz2NcieDc4UnrUfmbz5+0A3p2 Buqwf1ucVyPf3xXAid96gepNIQ9aT3fqXx3XdDWoaCmFlQQkMaxbkvQ/GpWPi4QC Oz6qrsQVmCiWD0IYdGakTgHjRPhW4z/v2/ALC2p5xgktBNde9c2jCJxJBl08C6xY FWxerIWss2trLp0wYHmtNLQsuzg/u6szNaVvZvjjuJh7UMmUhgwNYwGhaqnqFJua DIHekNqBexowgO5ilDInfPx2/DVxFjkl -----END CERTIFICATE-----
Βήμα 2: Δημιουργία και ορισμός metadata του SP
Μετά την αρχική εγκατάσταση ο SP θα έχει δημιουργήσει αυτόματα μία αρχική έκδοση των metadata σε URL της μορφής http://<URL>/Shibboleth.sso/Metadata. Τα metadata αυτά θα πρέπει να αξιοποιηθούν και να εμπλουτιστούν με επιπλέον περιεχόμενο το οποίο θα περιλαμβάνει:
- Στοιχεία περιγραφής της υπηρεσίας, ιδιαίτερα ένα DisplayName (εμφανίζεται στη σελίδα πιστοποίησης του IdP), όπως επίσης και περιγραφή, URL κτλ.
- Στοιχεία οργανισμού, αν αυτά είναι διαθέσιμα.
- Στοιχεία ContactPerson του (τεχνικού) υπευθύνου της υπηρεσίας.
Ακολουθεί παράδειγμα στοιχείων metadata:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" ID="_540723895hjkt932hjkyu9s8y9njlkjb7" entityID="https://my-service-url/shibboleth"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol"> <md:Extensions> <mdui:UIInfo> <mdui:DisplayName xml:lang="en"> Title of service in english </mdui:DisplayName> <mdui:DisplayName xml:lang="el"> Title of service in greek </mdui:DisplayName> <mdui:Description xml:lang="en"> Description of service in english </mdui:Description> <mdui:Description xml:lang="el"> Description of service in greek </mdui:Description> <mdui:InformationURL> URL of service's information </mdui:InformationURL> <mdui:PrivacyStatementURL xml:lang="en"> URL of Privacy Statement in english </mdui:PrivacyStatementURL> <mdui:PrivacyStatementURL xml:lang="el"> URL of Privacy Statement in greek </mdui:PrivacyStatementURL> </mdui:UIInfo> </md:Extensions> </md:SPSSODescriptor> <md:ContactPerson contactType="technical"> <md:Company> Company Name </md:Company> <md:EmailAddress> Email Address </md:EmailAddress> <md:TelephoneNumber> Telephone Number </md:TelephoneNumber> </md:ContactPerson> </md:EntityDescriptor>
Βήμα 3: Διασύνδεση του νέου SP με τον IdP του ΕΜΠ
Ο διαχειριστής του SP θα πρέπει, τέλος, να επιλέξει τα κατάλληλα υποχρεωτικά και προαιρετικά attributes που επιθυμεί να επιστρέφονται από τον IdP. Το αρχείο attribute-map.xml της εγκατάστασης μπορεί να αποτελέσει οδηγό για την επιλογή τους. Στη συνέχεια, πρέπει να αποστείλει με email στη διεύθυνση help-data@noc.ntua.gr τα metadata του SP και τη λίστα με τα attributes προκειμένου να ολοκληρωθεί η σύνδεση, μέσω προσθήκης του SP στη διαμόρφωση του IdP.
Το βήμα αυτό δεν απαιτείται εφόσον ο SP έχει φροντίσει να ορίσει τα attributes που αναμένει απευθείας μέσα στα metadata μέσα σε AttributeConsumingService element όπως παρακάτω:
<AttributeConsumingService index="0" isDefault="true"> <ServiceName xml:lang="en">GUnet SSN (AMKA) Validation service.</ServiceName> <ServiceDescription xml:lang="en">GUnet service to validate students' social security number (AMKA).</ServiceDescription> <RequestedAttribute FriendlyName="surname" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/> <RequestedAttribute FriendlyName="schacPersonalUniqueCode" Name="urn:oid:1.3.6.1.4.1.25178.1.2.14" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/> <RequestedAttribute FriendlyName="schacDateOfBirth" Name="urn:oid:1.3.6.1.4.1.25178.1.2.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/> </AttributeConsumingService>
Παρακάτω εμφανίζονται ορισμένα ενδεικτικά και βασικά attributes που καλύπτουν τις περισσότερες ανάγκες εγκαταστάσεων:
Attribute | Περιγραφή | Παράδειγμα |
---|---|---|
eduPersonPrincipalName | A scoped identifier for a person. It should be represented in the form user@scope where user is a name-based identifier for the person and where the scope portion MUST be the administrative domain of the identity system where the identifier was created and assigned. | user@ntua.gr |
eduPersonTargetedID | A persistent, non-reassigned, opaque identifier for a principal. Το συγκεκριμένο attribute δεν είναι συμπληρωματικό του eduPersonPrincipalName και οι πάροχοι υπηρεσιών δε θα πρέπει να ζητούν και τα δύο από τον IdP. | wPp7rbbJv45h58taWvtGlM5naX4= |
user@mail.ntua.gr | ||
displayName | preferred name of a person to be used when displaying entries | Όνομα Επώνυμο |
givenName | Όνομα | |
sn | Επώνυμο | |
cn | (Common Name) Ονοματεπώνυμο | |
eduPersonAffiliation | Specifies the user's relationship(s) to the institution in broad categories such as student, faculty, employee, etc. | student |
telephoneNumber | Τηλεφωνικός Αριθμός σε επίσημη μορφή | +30 210 772 2409 |
businessCategory | Κατηγορία προσώπου. Λιγότερο γενική από ότι το affiliation αλλά περισσότερο γενική από τον τίτλο |
Καθηγητής |
title | Τίτλος (χρησιμοποιείται κυρίως στον τηλεφωνικό κατάλογο) |
Επ. Καθηγητής |
employeeNumber | Αριθμός μητρώου μισθοδοσίας για μισθοδοτούμενους χρήστες | 04522 |
eduPersonOrgUnitDN | Πλειότιμο attribute με τα LDAP DNs των Σχολών, Τμημάτων, Εργαστηρίων στα οποία ανήκει το πρόσωπο | ou=Dep4,ou=units,dc=ntua,dc=gr (Ηλεκτρολόγοι) |
grEduPersonUndergraduateBranch | Μοναδικός κωδικός ΥΠΕΠΘ για τη Σχολή στην οποία ανήκει ο φοιτητής | 235 |
schacPersonalUniqueCode | URN που περιλαμβάνει το πανεπιστήμιο, Σχολή και αριθμό μητρώου φοιτητή |
urn:mace:terena.org:schac:personalUniqueCode: gr:ntua.gr:235:05115083 |
schGrAcEnrollment | URN που αναφέρεται στο εξάμηνο εγγραφής |
urn:mace:gunet.gr:schgrac:enrollment: gr:ntua.gr:9::235 |
schGrAcInscription | URN που αναφέρεται στο κανονικό εξάμηνο εγγραφής |
urn:mace:gunet.gr:schgrac:inscription: gr:ntua.gr:1:2015:235 |
Αναφορές: SwitchAAI Attributes
Σε ότι αφορά την πιστοποίηση χρηστών, ο γενικός κανόνας είναι ότι ο εξυπηρετητής ταυτότητας (IdP) του ΕΜΠ επιστρέφει επιτυχή πιστοποίηση και τα ανάλογα attributes για οποιονδήποτε χρήστη με έγκυρα στοιχεία ταυτοποίησης (username στο ΚΗΥ/κεντρική υπηρεσία καταλόγου). Ο εκάστοτε SP θα πρέπει να υλοποιήσει αυτόνομα και εσωτερικά τυχόν περιορισμό πρόσβασης μέσω κατάλληλων attributes από αυτά τα οποία επιστρέφει ο IdP.
Μόνο εφόσον κάτι τέτοιο δεν είναι εφικτό τεχνικά στον SP θα πρέπει να ζητηθεί από το Κέντρο Δικτύων η επιστροφή στοιχείων αποκλειστικά σε συγκεκριμένες περιπτώσεις. Σημειώνεται όμως ότι η τεχνικη αυτή δυνατότητα δεν είναι δεδομένη. Επιπλέον αυτό το οποίο μπορεί να περιοριστεί είναι αποκλειστικά και μόνο η επιστροφή attributes για ένα χρήστη, όχι κενό assertion σε περίπτωση επιτυχημένης πιστοποίησης. Θα πρέπει λοιπόν ο SP πάντα να βασίζεται στην ύπαρξη συγκεκριμένων attributes για να επιβεβαιώνει ότι ο χρήστης πιστοποιήθηκε επιτυχώς και έχει πρόσβαση στις υπηρεσίες που προσφέρει ο SP.
Για την περίπτωση που ζητείται ως πληροφορία από τον SP (ιδιαίτερα σε περιπτώσεις υπηρεσιών τρίτων) παρακάτω εμφανίζονται ορισμένες βασικές διαμορφώσεις της υπηρεσίας IdP στην τυπική (default) μορφή:
Μεταβλητή | Τιμή |
---|---|
Signed Requests | FALSE |
Sign Assertions | FALSE |
Sign Responses | TRUE |
Encrypt Assertions | TRUE |
Encrypt NameID | FALSE |
Encrypt Attributes | FALSE |
Βήμα 4: Δοκιμή SP
Οι δοκιμές καλής λειτουργίας γίνονται από την πλευρά του Κέντρου Δικτύων (παρόχου ταυτότητας) κατά την ενσωμάτωση του SP στον IdP του ΕΜΠ. Ο ίδιος ο SP μπορεί και αυτός να πραγματοποιήσει δοκιμές του SP ακόμα και αν δεν έχει ολοκληρώσει την ενσωμάτωση του στην εφαρμογή του.
Προς το σκοπό αυτό θα πρέπει να αναζητήσει το xml element init:RequestInitiator στα Metadata του SP το οποίο θα περιέχει ένα tag Location όπως το ακόλουθο: Location="http://www.noc.ntua.gr/Shibboleth.sso/Login"
Η σελίδα δοκιμαστικής πιστοποίησης θα έχει την μορφή (με βάση το παραπάνω παράδειγμα): http://www.noc.ntua.gr/Shibboleth.sso/Login?target=http%3A//www.noc.ntua.gr&forceAuthn=true
Αποσύνδεση χρήστη (Logout)
Η αποσύνδεση χρήστη είναι σχετικά προβληματική λόγω χρήσης cookies και μη διαγραφής τους κατά το κλείσιμο του browser ενός χρήστη. Κατά συνέπεια αποτελεί υπηρεσία best effort. Επί παραδείγματι το Standford έχει να αναφέρει τα εξής για το θέμα:
We recommend that you do not put a "logout" feature on your SAML-authenticated application since at best it only clears your application's session state in a given browser. That is, even after a user selects Logout of a given application, when a new window is opened and the user goes back to the application, single-sign-on is still enabled (the user is still authenticated) and can go directly back into the application unless forced reauthentication is required by the application.
Σχετικά αναλυτικές οδηγίες για το ζήτημα βρίσκονται σε αυτόν τον σύνδεσμο. Ο SP μπορεί να στέλνει τον χρήστη σε logout link της ακόλουθης μορφής (για την περίπτωση χρήσης του λογισμικού Shibboleth SP) το οποίο στη συνέχεια θα επιχειρεί να τον αποσυνδέσει και από τον πάροχο ταυτότητας (IdP session), κάτι όμως που σημαίνει ότι ο χρήστης θα χάσει το authenticated session του στον κεντρικό IdP ενώ πιθανώς να επιθυμούσε απλά να κάνει logout από το συγκεκριμένο service SP:
https://service.hostname.ntua.gr/Shibboleth.sso/Logout?return=https://login.ntua.gr/idp/profile/Logout