Συνδέει το VPN SSO τους χρήστες αυτόματα στις εσωτερικές εφαρμογές;

Μια πύλη VPN που πιστοποιείται μέσω παρόχου ταυτότητας αποδεικνύει ένα πράγμα: ο πάροχος εγγυήθηκε για έναν χρήστη απέναντι στην πύλη. Δεν παρέχει σε αυτόν τον χρήστη διαπιστευτήριο για το wiki του εσωτερικού δικτύου, τον πίνακα παρακολούθησης ή τον διακομιστή build. Αυτές οι υπηρεσίες συνδέουν τους ανθρώπους μέσω της δικής τους ομοσπονδίας και εφαρμόζουν τη δική τους εξουσιοδότηση, και το τούνελ αποφασίζει μόνο ποια πακέτα μπορούν να τις φτάσουν.

Τρεις συνεδρίες, τρεις ξεχωριστές αποφάσεις

Κρατήστε τις καταστάσεις χωριστά, γιατί καθεμία λήγει με το δικό της χρονοδιάγραμμα. Η συνεδρία VPN είναι η αποδοχή ταυτότητας από την πύλη συν η πρόσβαση δικτύου που παραχώρησε. Η συνεδρία προγράμματος περιήγησης στον πάροχο ταυτότητας είναι ό,τι κρατά ακόμη το πρόγραμμα για αυτόν τον πάροχο και μπορεί να το επαναχρησιμοποιήσει σύμφωνα με την πολιτική του. Η συνεδρία εφαρμογής ανήκει σε μία υπηρεσία που επικύρωσε μια απόκριση απευθυνόμενη σε αυτήν.

Η σύγχυση αυτών των καταστάσεων παράγει τη λάθος ερώτηση, συνήθως διατυπωμένη ως γιατί το τούνελ δεν συνδέει τον χρήστη παντού. Αναδιατυπώστε την: ποια εφαρμογή δεν έχει καταχώριση ομοσπονδίας, ποια απορρίπτει τον χρήστη και σε ποια λείπει διαδρομή. Ένα μόνο αίτημα σύνδεσης που ανοίγει την εφαρμογή του εσωτερικού δικτύου μπορεί να επιστρέψει στον πάροχο, γιατί η δεύτερη ανακατεύθυνση είναι νέο αίτημα εξουσιοδότησης για διαφορετικό κοινό.

Συνδέστε την πύλη ως δική της εφαρμογή

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

Η απόκριση πιστοποίησης του τούνελ δεν είναι επαναχρησιμοποιήσιμο διαπιστευτήριο. Τα token ID του OIDC φέρουν αξίωση κοινού που ονομάζει τον πελάτη για τον οποίο εκδόθηκαν, και οι δηλώσεις φορέα SAML περιορίζουν το κοινό στον πάροχο υπηρεσίας που τις λαμβάνει. Μια δεύτερη υπηρεσία που δέχεται την απόκριση της πρώτης είναι λανθασμένα ρυθμισμένη, και η αντιγραφή ενός token σε άλλη εφαρμογή δεν είναι ενοποίηση.

Καταχωρίστε κάθε εσωτερική εφαρμογή και μετά ρυθμίστε το περιβάλλον του προγράμματος περιήγησης

Κάθε υπηρεσία χρειάζεται τις υποστηριζόμενες τιμές SAML ή OIDC: εκδότη, αναγνωριστικό πελάτη, URL επιστροφής κλήσης ή καταναλωτή δήλωσης, απαιτούμενες αξιώσεις και ανάθεση. Η προσβασιμότητα έρχεται επιπλέον, γιατί οι έλεγχοι ταυτότητας δεν παρέχουν ποτέ διαδρομή ή απάντηση DNS.

1. Δημιουργήστε την καταχώριση εφαρμογής και επιβεβαιώστε ότι το ID οντότητας ή πελάτη ταιριάζει με αυτό που στέλνει η εφαρμογή.
2. Καταχωρίστε το ακριβές URL επιστροφής κλήσης, συμπεριλαμβανομένου σχήματος και θύρας· μια μικρή απόκλιση αποτυγχάνει αφού ο χρήστης πιστοποιηθεί.
3. Αναθέστε τους χρήστες ή τις ομάδες και μετά επιβεβαιώστε ότι οι απαιτούμενες αξιώσεις εκδίδονται.
4. Επιτρέψτε τα τελικά σημεία του παρόχου ταυτότητας καθώς και την ιδιωτική εφαρμογή, αλλιώς η ανακατεύθυνση δεν μπορεί να ολοκληρωθεί.

Το περιβάλλον του προγράμματος περιήγησης καθορίζει αν θα επαναχρησιμοποιηθεί μια υπάρχουσα συνεδρία παρόχου. Ένας εγγενής πελάτης που ανοίγει το πρόγραμμα περιήγησης του συστήματος μπορεί να μοιραστεί αυτή την κατάσταση, ενώ μια ενσωματωμένη προβολή με δικό της βάζο cookies συνήθως όχι. Νέο πρόγραμμα περιήγησης, ιδιωτικά παράθυρα και δεύτερο προφίλ ξεκινούν από το μηδέν, κάτι αναμενόμενο και όχι σπασμένη ρύθμιση SSO.

Εκτελέστε τη ροή και διαβάστε πού σταματά

Αναπαράγετε με τον πίνακα δικτύου του προγράμματος περιήγησης και παρακολουθήστε την αλυσίδα ανακατευθύνσεων. Ένα χρήσιμο πέρασμα ακολουθεί ένα άλμα τη φορά: πύλη προς πάροχο, πάροχος πίσω στην εφαρμογή με κωδικό ή δήλωση, εφαρμογή προς το τελικό σημείο token του παρόχου, έκδοση συνεδρίας εφαρμογής. Το άλμα όπου σταματά η αλυσίδα ονομάζει το στοιχείο που πρέπει να διορθωθεί.

Δύο έλεγχοι γραμμής εντολών λύνουν τις συνήθεις αμφιβολίες και οι δύο είναι ασφαλείς από κεντρικό υπολογιστή διαχειριστή:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Όταν τα μεταδεδομένα απαριθμούν τελικά σημεία που δεν καταχωρίσατε ποτέ, η εφαρμογή δείχνει σε άλλον μισθωτή ή εκδότη. Όταν το πρώτο αίτημα προς την εφαρμογή απαντά 302 προς μη αναμενόμενο κεντρικό υπολογιστή, η ρύθμιση ομοσπονδίας της εφαρμογής είναι το σημείο αναζήτησης, όχι το προφίλ VPN.

Διορθώστε τα αιτήματα βρίσκοντας ποιος τα ζήτησε

Ένα δεύτερο αίτημα κωδικού πρόσβασης δεν είναι αυτόματα ελάττωμα. Η εφαρμογή μπορεί να ζητά υψηλότερο επίπεδο διασφάλισης, ή ο πάροχος μπορεί να επιβάλλει μέγιστη ηλικία συνεδρίας και νέα πρόκληση. Η αφαίρεση αυτών των απαιτήσεων για να γίνει η ροή πιο ήσυχη αποδυναμώνει έναν σκόπιμο έλεγχο, οπότε προσδιορίστε ποιο στοιχείο το ζήτησε πριν αλλάξετε πολιτική.

Μετά αποφασίστε τι θα βελτιώσετε. Αν το αίτημα προέρχεται από την εφαρμογή, διορθώστε την καταχώρισή της στην ομοσπονδία. Αν προέρχεται από τον πάροχο βάσει πολιτικής, τεκμηριώστε την απαίτηση. Αν η εφαρμογή δεν είναι προσβάσιμη μετά από επιτυχή σύνδεση, ύποπτη είναι η δρομολόγηση του τούνελ, γιατί η ταυτότητα και η παράδοση πακέτων αποτυγχάνουν σε διαφορετικά σημεία και μοιάζουν μεταξύ τους από τη θέση του χρήστη.