Ενιαία σύνδεση

Η ενιαία σύνδεση επιτρέπει σε έναν εξωτερικό πάροχο ταυτότητας (IdP) να αποφασίζει ποιος μπορεί να συνδεθεί στον διακομιστή σας Control Center. Υποστηρίζονται δύο πρωτόκολλα — SAML 2.0 και OpenID Connect — και τα δύο καταλήγουν στο ίδιο σημείο: ένα νέο διαπιστευτήριο συσκευής που είναι δυσδιάκριτο από μια πρόσκληση ή μια σύζευξη μέσω QR σε όλη τη μετέπειτα διαδρομή.

Η μορφή μιας σύνδεσης

Οι συνδέσεις SAML γίνονται με τη διαμεσολάβηση του προγράμματος περιήγησης. Ο IdP δεν ανοίγει ποτέ σύνδεση προς τον διακομιστή σας· το πρόγραμμα περιήγησης του χρήστη μεταφέρει τα πάντα:

browser ──> /saml/login ──> IdP ──POST SAMLResponse──> /saml/acs
                                                          │  verify
                                                          ▼
                                              provision user (maybe)
                                                          │
                                                          ▼
                                  browser handoff: device PSK in the URL
                                  fragment (never a query parameter)

Επειδή το πρόγραμμα περιήγησης είναι ο μεταφορέας, ένας διακομιστής πίσω από NAT λειτουργεί μια χαρά για συνδέσεις: localhost, LAN, Tailscale, VPN ή σήραγγα εξυπηρετούν όλα — μόνο το πρόγραμμα περιήγησης του χρήστη πρέπει να φτάνει στο ACS URL. Η αναμετάδοση WebSocket που χρησιμοποιεί ο απομακρυσμένος έλεγχος από κινητό δεν μπορεί να μεταφέρει τον κύκλο ανταλλαγής HTTP, γι’ αυτό τα σημεία εισόδου SSO στοχεύουν πάντα την προέλευση HTTP του διακομιστή.

Το OpenID Connect ακολουθεί την ίδια μορφή με έναν κύκλο ανταλλαγής authorization-code + PKCE· οι διεκδικήσεις διαβάζονται από το endpoint token του εκδότη μέσω TLS, οπότε το πρόγραμμα περιήγησης δεν παρέχει ποτέ δεδομένα ταυτότητας.

Οι προσαρμογείς

Το Control Center μοιράζει την ευθύνη σκόπιμα:

Τμήμα	Πού	Είναι υπεύθυνο για
εγγενές cc_saml	packages/cc_natives/native/saml/	Επαλήθευση XML-DSig, κανονικοποίηση, επικύρωση προφίλ SAML — ανατίθενται στο καρφιτσωμένο crate saml σε καθαρή Rust πίσω από ένα C ABI χωρίς κατάσταση
SamlService / OidcService	cc_server_core	κατάσταση σύνδεσης (ιχνηλάτες εκκρεμών αιτημάτων, αποδιπλοποίηση replay), διακόπτες πολιτικής επικύρωσης, η κοινή κλήση παροχής
SsoProvisioner	cc_server_core	εντοπισμός ή δημιουργία του χρήστη, καρφίτσωμα του υποκειμένου του παρόχου, εκχώρηση συμμετοχών βάσει της πολιτικής αυτόματης συμμετοχής
ScimService	cc_server_core	η επιφάνεια push του SCIM 2.0 (κύκλος ζωής παροχής/αποπαροχής)
SsoSettingsService	cc_server_core	οι αποθηκευμένες γραμμές σύνδεσης, η ζωντανή επανεφαρμογή, το token SCIM

Δεν υπάρχει σκόπιμα κανένας εφεδρικός μηχανισμός κρυπτογραφίας SAML σε καθαρή Dart: η χειροποίητη XML-DSig/κανονικοποίηση είναι ακριβώς εκεί όπου ζουν οι ευπάθειες περιτύλιξης υπογραφής, οπότε μια βιβλιοθήκη cc_saml που λείπει απορρίπτει και τη σύνδεση SAML και την εκκίνηση του διακομιστή. Το εγγενές τμήμα είναι εκ σχεδιασμού χωρίς κατάσταση — η κατάσταση μεταξύ αιτημάτων ζει στις υπηρεσίες Dart, μίας χρήσης και βραχύβια.

Τι επαληθεύει μια σύνδεση

Μέσα στο επαληθευμένο εγγενές τμήμα και στην υπηρεσία, με σειρά:

1. η υπογραφή του assertion (απαιτείται πάντα· αυτή του φακέλου απάντησης είναι προαιρετική ανά διαμόρφωση) — δομικά ανθεκτική στην περιτύλιξη υπογραφής, επειδή το επικυρωμένο φορτίο είναι δεσμευμένο στο επαληθευμένο στοιχείο,
2. ο εκδότης ταιριάζει με τον διαμορφωμένο IdP,
3. το audience κατονομάζει αυτόν τον πάροχο υπηρεσίας,
4. ο προορισμός είναι το ACS URL μας,
5. το InResponseTo ταιριάζει με ένα εκκρεμές AuthnRequest που εκδώσαμε (οι μη ζητηθείσες, εκκινούμενες από τον IdP απαντήσεις είναι απενεργοποιημένες από προεπιλογή),
6. τα παράθυρα διάρκειας ζωής ισχύουν εντός της ανοχής χρονισμού (προεπιλογή 90s) και
7. το αναγνωριστικό assertion δεν έχει ξαναεμφανιστεί (cache replay).

Οι αποτυχίες επιστρέφουν ως κωδικοί με τύπο — signature, expired, audience, destination, issuer, request-match — και τα endpoints απαντούν με γενικά σφάλματα, ώστε ένας επιτιθέμενος να μη μαθαίνει τίποτα για το γιατί απέτυχε μια πλαστογράφηση.

Λογαριασμοί και καρφίτσωμα υποκειμένου

Η πρώτη σύνδεση SSO καρφιτσώνει το αμετάβλητο υποκείμενο του παρόχου (issuer μαζί με SAML NameID / OIDC sub, ή SCIM externalId) στον λογαριασμό. Από εκεί και πέρα, το υποκείμενο — όχι το email — αναγνωρίζει τη σύνδεση. Αν κάποιος άλλος παρουσιάσει αργότερα το ίδιο email από τον ίδιο ή άλλον IdP, ο καρφιτσωμένος λογαριασμός τον απορρίπτει. Αυτό εμποδίζει ένα ανακυκλωμένο email σε έναν πάροχο να γίνει κατάληψη λογαριασμού.

Παροχή και αποπαροχή

Η παροχή JIT συμβαίνει κατά τη σύνδεση (SsoProvisioner). Το SCIM είναι μια ξεχωριστή επιφάνεια push (ScimService) που καρφιτσώνει το ίδιο υποκείμενο στη γραμμή χρήστη· δεν εκχωρεί συμμετοχές σε χώρους εργασίας. Η αποπαροχή — SCIM active: false ή DELETE — αρνείται αν ο λογαριασμός είναι ιδιοκτήτης χώρου εργασίας (μεταφέρετε πρώτα την κυριότητα). Διαφορετικά, ανακαλεί πρώτα κάθε διαπιστευτήριο συσκευής (οι συνεδρίες πέφτουν μέσα σε δευτερόλεπτα μέσω της παρακολούθησης συσκευών), αφαιρεί κάθε συμμετοχή σε χώρο εργασίας και σηματοδοτεί τον λογαριασμό ως απενεργοποιημένο. Η γραμμή χρήστη επιβιώνει: η απόδοση είναι μόνιμη. Η επανενεργοποίηση αποκαθιστά τη σύνδεση αλλά δεν επαναχορηγεί ποτέ συμμετοχές.

Τι μένει εκτός

• Η αντιστοίχιση ομάδας→ρόλου συμβαίνει κατά τη σύνδεση από τα χαρακτηριστικά SAML / τις διεκδικήσεις OIDC — οι ομάδες SCIM που ωθούνται δεν αποθηκεύονται.
• Ο ρόλος ιδιοκτήτη είναι απρόσιτος από το SSO — ούτε ως προεπιλεγμένος ρόλος ούτε μέσω αντιστοίχισης ομάδας.
• Η αναμετάδοση WebSocket δεν είναι ποτέ κανάλι SSO· τα κινητά που φτάνουν στον διακομιστή μόνο μέσω της αναμετάδοσης δεν μπορούν να ολοκληρώσουν κύκλο ανταλλαγής μέσω προγράμματος περιήγησης απέναντί του.