Ασφάλεια

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

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

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

Οι υπηρεσίες REST (που αντιπροσωπεύουν την αντιπροσωπευτική κατάσταση μεταφοράς) ξεκίνησαν ως μια εξαιρετικά απλοποιημένη προσέγγιση για τις υπηρεσίες Web που είχε τεράστιες προδιαγραφές και περίπλοκες μορφές, όπως WSDL για την περιγραφή της υπηρεσίας, ή ΣΑΠΟΥΝΙ για τον καθορισμό της μορφής του μηνύματος. Στο REST, δεν έχουμε κανένα από αυτά. Μπορούμε να περιγράψουμε την υπηρεσία REST σε ένα αρχείο απλού κειμένου και να χρησιμοποιήσουμε οποιαδήποτε μορφή μηνύματος που θέλουμε, όπως JSON, XML ή ακόμα και απλό κείμενο. Η απλοποιημένη προσέγγιση εφαρμόστηκε και στην ασφάλεια των υπηρεσιών REST. κανένα καθορισμένο πρότυπο δεν επιβάλλει έναν συγκεκριμένο τρόπο ελέγχου ταυτότητας χρηστών.

Αν και οι υπηρεσίες REST δεν έχουν καθοριστεί πολύ, σημαντικό είναι η έλλειψη πολιτείας. Αυτό σημαίνει ότι ο διακομιστής δεν διατηρεί καμία κατάσταση πελάτη, με τις συνεδρίες ως καλό παράδειγμα. Έτσι, ο διακομιστής απαντά σε κάθε αίτημα σαν να ήταν το πρώτο που έκανε ο πελάτης. Ωστόσο, ακόμη και τώρα, πολλές εφαρμογές εξακολουθούν να χρησιμοποιούν έλεγχο ταυτότητας βάσει cookie, η οποία κληρονομείται από τον τυπικό αρχιτεκτονικό σχεδιασμό ιστότοπου. Η απάτριδα προσέγγιση του REST καθιστά τα cookie συνεδρίας ακατάλληλα από την άποψη της ασφάλειας, αλλά παρόλα αυτά, εξακολουθούν να χρησιμοποιούνται ευρέως. Εκτός από την παραβίαση της απαιτούμενης ανιθαγένειας, η απλοποιημένη προσέγγιση ήρθε ως μια αναμενόμενη αντιστάθμιση ασφάλειας Σε σύγκριση με το πρότυπο WS-Security που χρησιμοποιείται για υπηρεσίες Web, είναι πολύ πιο εύκολο να δημιουργήσετε και να καταναλώσετε υπηρεσίες REST, επομένως η ευκολία πέρασε από την οροφή. Η αντιστάθμιση είναι αρκετά λεπτή ασφάλεια. η παραβίαση συνεδρίας και η πλαστογράφηση αιτήσεων μεταξύ ιστότοπων (XSRF) είναι τα πιο κοινά ζητήματα ασφαλείας.

Στην προσπάθεια να απαλλαγείτε από τις συνεδρίες πελατών από τον διακομιστή, μερικές φορές έχουν χρησιμοποιηθεί μερικές άλλες μέθοδοι, όπως ο έλεγχος ταυτότητας Basic ή Digest HTTP. Και οι δύο χρησιμοποιούν ένα Authorization επικεφαλίδα για μετάδοση διαπιστευτηρίων χρήστη, με κάποια κωδικοποίηση (HTTP Basic) ή κρυπτογράφηση (HTTP Digest). Φυσικά, έφεραν τα ίδια ελαττώματα που βρέθηκαν σε ιστότοπους: Το HTTP Basic έπρεπε να χρησιμοποιηθεί μέσω HTTPS, καθώς το όνομα χρήστη και ο κωδικός πρόσβασης αποστέλλονται σε εύκολα αναστρέψιμη κωδικοποίηση base64 και το HTTP Digest ανάγκασε τη χρήση παρωχημένου MD5 κατακερματισμού που αποδεικνύεται ανασφαλής.

Τέλος, ορισμένες εφαρμογές χρησιμοποίησαν αυθαίρετα διακριτικά για έλεγχο ταυτότητας πελατών. Αυτή η επιλογή φαίνεται να είναι η καλύτερη που έχουμε, προς το παρόν. Εάν εφαρμοστεί σωστά, επιδιορθώνει όλα τα προβλήματα ασφαλείας των HTTP Basic, HTTP Digest ή cookie περιόδου λειτουργίας, είναι απλό στη χρήση και ακολουθεί το μοτίβο των απάτριδων.

πού να χρησιμοποιήσετε το node js

Ωστόσο, με τέτοια αυθαίρετα διακριτικά, υπάρχει ελάχιστο πρότυπο. Κάθε πάροχος υπηρεσιών είχε την ιδέα του τι πρέπει να τοποθετήσει το διακριτικό και πώς να το κωδικοποιήσει ή να το κρυπτογραφήσει. Η κατανάλωση υπηρεσιών από διαφορετικούς παρόχους απαιτούσε επιπλέον χρόνο ρύθμισης, απλώς για να προσαρμοστεί στη συγκεκριμένη μορφή διακριτικού που χρησιμοποιείται. Οι άλλες μέθοδοι, από την άλλη πλευρά (cookie συνεδρίας, HTTP Basic και HTTP Digest) είναι πολύ γνωστές στους προγραμματιστές και σχεδόν όλα τα προγράμματα περιήγησης σε όλες τις συσκευές λειτουργούν μαζί τους. Τα πλαίσια και οι γλώσσες είναι έτοιμα για αυτές τις μεθόδους, έχοντας ενσωματωμένες λειτουργίες για την απρόσκοπτη αντιμετώπιση τους.

Έλεγχος ταυτότητας JWT

Το JWT (συντομευμένο από το JSON Web Token) είναι η λείπει τυποποίηση για τη χρήση διακριτικών για έλεγχο ταυτότητας στον ιστό γενικά, όχι μόνο για υπηρεσίες REST. Προς το παρόν, είναι σε κατάσταση πρόχειρου ως RFC 7519 . Είναι ανθεκτικό και μπορεί να μεταφέρει πολλές πληροφορίες, αλλά εξακολουθεί να είναι απλό στη χρήση, παρόλο που το μέγεθός του είναι σχετικά μικρό. Όπως και οποιοδήποτε άλλο διακριτικό, το JWT μπορεί να χρησιμοποιηθεί για να μεταβιβάσει την ταυτότητα των επικυρωμένων χρηστών μεταξύ ενός παρόχου ταυτότητας και ενός παρόχου υπηρεσιών (που δεν είναι απαραίτητα τα ίδια συστήματα). Μπορεί επίσης να φέρει όλη την αξίωση του χρήστη, όπως δεδομένα εξουσιοδότησης, επομένως ο πάροχος υπηρεσιών δεν χρειάζεται να μεταβεί στη βάση δεδομένων ή σε εξωτερικά συστήματα για να επαληθεύσει τους ρόλους και τα δικαιώματα χρήστη για κάθε αίτημα. αυτά τα δεδομένα εξάγονται από το διακριτικό.

Εδώ είναι πώς σχεδιάζεται η ασφάλεια JWT:

• Οι πελάτες συνδέονται αποστέλλοντας τα διαπιστευτήριά τους στον πάροχο ταυτότητας.
• Ο πάροχος ταυτότητας επαληθεύει τα διαπιστευτήρια. εάν όλα είναι εντάξει, ανακτά τα δεδομένα χρήστη, δημιουργεί ένα JWT που περιέχει λεπτομέρειες και δικαιώματα χρήστη που θα χρησιμοποιηθούν για πρόσβαση στις υπηρεσίες και ορίζει επίσης τη λήξη στο JWT (το οποίο μπορεί να είναι απεριόριστο).
• Ο πάροχος ταυτότητας υπογράφει και, εάν χρειάζεται, κρυπτογραφεί το JWT και το στέλνει στον πελάτη ως απάντηση στο αρχικό αίτημα με διαπιστευτήρια.
• Ο πελάτης αποθηκεύει το JWT για περιορισμένο ή απεριόριστο χρονικό διάστημα, ανάλογα με τη λήξη που έχει ορίσει ο πάροχος ταυτότητας.
• Ο πελάτης στέλνει το αποθηκευμένο JWT σε μια κεφαλίδα εξουσιοδότησης για κάθε αίτημα στον πάροχο υπηρεσιών.
• Για κάθε αίτημα, ο πάροχος υπηρεσιών λαμβάνει το JWT από το Authorization επικεφαλίδα και αποκρυπτογραφεί, εάν χρειαστεί, επικυρώνει την υπογραφή και αν όλα είναι εντάξει, εξάγει τα δεδομένα χρήστη και τα δικαιώματα. Με βάση αυτά τα δεδομένα αποκλειστικά, και πάλι χωρίς να αναζητήσετε περισσότερες λεπτομέρειες στη βάση δεδομένων ή να επικοινωνήσετε με τον πάροχο ταυτότητας, μπορεί να αποδεχτεί ή να απορρίψει το αίτημα του πελάτη. Η μόνη απαίτηση είναι ότι η ταυτότητα και οι πάροχοι υπηρεσιών έχουν συμφωνία σχετικά με την κρυπτογράφηση, έτσι ώστε η υπηρεσία να μπορεί να επαληθεύσει την υπογραφή ή ακόμη και να αποκρυπτογραφήσει ποια ταυτότητα κρυπτογραφήθηκε.

Αυτή η ροή επιτρέπει μεγάλη ευελιξία, διατηρώντας παράλληλα τα πράγματα ασφαλή και εύκολο να αναπτυχθούν. Χρησιμοποιώντας αυτήν την προσέγγιση, είναι εύκολο να προσθέσετε νέους κόμβους διακομιστή στο σύμπλεγμα παρόχων υπηρεσιών, αρχικοποιώντας τους μόνο με τη δυνατότητα επαλήθευσης της υπογραφής και αποκρυπτογράφησης των διακριτικών παρέχοντάς τους ένα κοινόχρηστο μυστικό κλειδί. Δεν απαιτείται αναπαραγωγή συνεδρίας, συγχρονισμός βάσης δεδομένων ή επικοινωνία μεταξύ κόμβων. ΠΕΡΙΣΣΟΤΕΡΑ στην πλήρη δόξα του.

Η κύρια διαφορά μεταξύ JWT και άλλων αυθαίρετων διακριτικών είναι η τυποποίηση του περιεχομένου του διακριτικού. Μια άλλη προτεινόμενη προσέγγιση είναι να στείλετε το διακριτικό JWT στο Authorization κεφαλίδα χρησιμοποιώντας το σχήμα Bearer. Το περιεχόμενο της κεφαλίδας πρέπει να έχει την εξής μορφή:

Authorization: Bearer

Εφαρμογή ασφάλειας REST

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

Αντί να ενεργοποιεί τη διαδικασία ελέγχου ταυτότητας με ανακατεύθυνση σε μια σελίδα σύνδεσης όταν ένας πελάτης ζητά έναν ασφαλή πόρο, ο διακομιστής REST επικυρώνει όλα τα αιτήματα χρησιμοποιώντας τα διαθέσιμα δεδομένα στο ίδιο το αίτημα, το διακριτικό JWT σε αυτήν την περίπτωση. Εάν ένας τέτοιος έλεγχος ταυτότητας αποτύχει, η ανακατεύθυνση δεν έχει νόημα. Το REST API απλώς στέλνει έναν κωδικό HTTP 401 (Μη εξουσιοδοτημένη) απάντηση και οι πελάτες πρέπει να γνωρίζουν τι να κάνουν. Για παράδειγμα, ένα πρόγραμμα περιήγησης θα εμφανίσει ένα δυναμικό div που θα επιτρέπει στον χρήστη να παρέχει το όνομα χρήστη και τον κωδικό πρόσβασης.

Από την άλλη πλευρά, μετά από έναν επιτυχημένο έλεγχο ταυτότητας σε κλασικούς ιστότοπους πολλών σελίδων, ο χρήστης ανακατευθύνεται χρησιμοποιώντας τον κωδικό HTTP 301 (Μεταφέρεται μόνιμα), συνήθως σε μια αρχική σελίδα ή, ακόμη καλύτερα, στη σελίδα που ο χρήστης αρχικά ζήτησε να ενεργοποιηθεί τη διαδικασία ελέγχου ταυτότητας. Με το REST, και πάλι αυτό δεν έχει νόημα. Αντ 'αυτού, θα συνεχίζαμε απλώς με την εκτέλεση του αιτήματος σαν να μην ήταν ασφαλής ο πόρος, να επιστρέψουμε τον κωδικό HTTP 200 (OK) και το αναμενόμενο σώμα απόκρισης.

Παράδειγμα ασφάλειας άνοιξη

Τώρα, ας δούμε πώς μπορούμε να εφαρμόσουμε το REST API που βασίζεται σε διακριτικά JWT χρησιμοποιώντας Ιάβα και Ανοιξη , ενώ προσπαθούμε να επαναχρησιμοποιήσουμε την προεπιλεγμένη συμπεριφορά της Spring Security όπου μπορούμε.

Όπως ήταν αναμενόμενο, το πλαίσιο Spring Security έρχεται με πολλές έτοιμες για προσθήκη τάξεις που ασχολούνται με «παλιούς» μηχανισμούς εξουσιοδότησης: cookie συνεδρίας, HTTP Basic και HTTP Digest. Ωστόσο, δεν διαθέτει την εγγενή υποστήριξη για το JWT και πρέπει να λερώσουμε τα χέρια μας για να λειτουργήσει. Για μια πιο λεπτομερή επισκόπηση, θα πρέπει να συμβουλευτείτε τον επίσημο Τεκμηρίωση ασφαλείας άνοιξη .

Τώρα, ας ξεκινήσουμε με το συνηθισμένο Ορισμός φίλτρου ασφαλείας άνοιξη σε web.xml:

springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilterChain /*

Σημειώστε ότι το όνομα του φίλτρου ασφαλείας ασφαλείας πρέπει να είναι ακριβώς springSecurityFilterChain για το υπόλοιπο της διαμόρφωσης Spring να λειτουργεί έξω από το κουτί.

Στη συνέχεια έρχεται η δήλωση XML των φασολιών που σχετίζονται με την ασφάλεια. Για να απλοποιήσουμε το XML, θα ορίσουμε τον προεπιλεγμένο χώρο ονομάτων σε security προσθέτοντας xmlns='http://www.springframework.org/schema/security' στο ριζικό στοιχείο XML. Το υπόλοιπο XML μοιάζει με αυτό:

(1) (2) (3) (4) (5) (6) (7) (8)

• (1) Σε αυτήν τη γραμμή, ενεργοποιούμε @PreFilter, @PreAuthorize, @PostFilter, @PostAuthorize σχολιασμοί για τυχόν ανοιξιάτικα φασόλια στο πλαίσιο.
• (2) Ορίζουμε τα τελικά σημεία σύνδεσης και εγγραφής για να παραλείψουμε την ασφάλεια. ακόμη και το «ανώνυμο» θα πρέπει να μπορεί να κάνει αυτές τις δύο λειτουργίες.
• (3) Στη συνέχεια, ορίζουμε την αλυσίδα φίλτρου που εφαρμόζεται σε όλα τα αιτήματα προσθέτοντας δύο σημαντικές διαμορφώσεις: Αναφορά σημείου εισόδου και ρύθμιση της δημιουργίας συνεδρίας σε stateless (δεν θέλουμε να δημιουργηθεί η περίοδος λειτουργίας για λόγους ασφαλείας καθώς χρησιμοποιούμε διακριτικά για κάθε αίτημα).
• (4) Δεν χρειαζόμαστε csrf προστασία επειδή τα κουπόνια μας είναι απρόσβλητα σε αυτό.
• (5) Στη συνέχεια, συνδέουμε το ειδικό φίλτρο ελέγχου ταυτότητας στην προκαθορισμένη αλυσίδα φίλτρων της άνοιξης, λίγο πριν από το φίλτρο σύνδεσης φόρμας.
• (6) Αυτό το φασόλι είναι η δήλωση του φίλτρου ελέγχου ταυτότητας. δεδομένου ότι επεκτείνει την Άνοιξη AbstractAuthenticationProcessingFilter, πρέπει να το δηλώσουμε σε XML για να συνδέσουμε τις ιδιότητές του (το αυτόματο καλώδιο δεν λειτουργεί εδώ). Θα εξηγήσουμε αργότερα τι κάνει το φίλτρο.
• (7) Ο προεπιλεγμένος χειριστής επιτυχίας AbstractAuthenticationProcessingFilter δεν είναι αρκετά καλό για σκοπούς REST επειδή ανακατευθύνει τον χρήστη σε μια σελίδα επιτυχίας. αυτός είναι ο λόγος που βάζουμε το δικό μας εδώ.
• (8) Η δήλωση του παρόχου που δημιουργήθηκε από το authenticationManager χρησιμοποιείται από το φίλτρο μας για έλεγχο ταυτότητας χρηστών.

Τώρα ας δούμε πώς εφαρμόζουμε τις συγκεκριμένες τάξεις που δηλώνονται στο XML παραπάνω. Σημειώστε ότι η Άνοιξη θα τους καλύψει. Ξεκινάμε με τα πιο απλά.

RestAuthenticationEntryPoint.java

public class RestAuthenticationEntryPoint implements AuthenticationEntryPoint { @Override public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException) throws IOException { // This is invoked when user tries to access a secured REST resource without supplying any credentials // We should just send a 401 Unauthorized response because there is no 'login page' to redirect to response.sendError(HttpServletResponse.SC_UNAUTHORIZED, 'Unauthorized'); } }

Όπως εξηγήθηκε παραπάνω, αυτή η τάξη επιστρέφει τον κωδικό HTTP 401 (Μη εξουσιοδοτημένο) όταν αποτύχει ο έλεγχος ταυτότητας, αντικαθιστώντας την προεπιλεγμένη ανακατεύθυνση της άνοιξης.

JwtAuthenticationSuccessHandler.java

public class JwtAuthenticationSuccessHandler implements AuthenticationSuccessHandler { @Override public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) { // We do not need to do anything extra on REST authentication success, because there is no page to redirect to } }

Αυτή η απλή παράκαμψη καταργεί την προεπιλεγμένη συμπεριφορά ενός επιτυχημένου ελέγχου ταυτότητας (ανακατεύθυνση στο σπίτι ή οποιαδήποτε άλλη σελίδα που ο χρήστης ζήτησε). Εάν αναρωτιέστε γιατί δεν χρειάζεται να παρακάμψουμε το AuthenticationFailureHandler, είναι επειδή η προεπιλεγμένη εφαρμογή δεν θα ανακατευθύνει οπουδήποτε αν δεν έχει οριστεί το URL ανακατεύθυνσης, οπότε αποφεύγουμε να ορίσουμε τη διεύθυνση URL, η οποία είναι αρκετά καλή.

JwtAuthenticationFilter.java

public class JwtAuthenticationFilter extends AbstractAuthenticationProcessingFilter { public JwtAuthenticationFilter() { super('/**'); } @Override protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) { return true; } @Override public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException { String header = request.getHeader('Authorization'); if (header == null || !header.startsWith('Bearer ')) { throw new JwtTokenMissingException('No JWT token found in request headers'); } String authToken = header.substring(7); JwtAuthenticationToken authRequest = new JwtAuthenticationToken(authToken); return getAuthenticationManager().authenticate(authRequest); } @Override protected void successfulAuthentication(HttpServletRequest request, HttpServletResponse response, FilterChain chain, Authentication authResult) throws IOException, ServletException { super.successfulAuthentication(request, response, chain, authResult); // As this authentication is in HTTP header, after success we need to continue the request normally // and return the response as if the resource was not secured at all chain.doFilter(request, response); } }

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

JwtAuthenticationProvider.java

public class JwtAuthenticationProvider extends AbstractUserDetailsAuthenticationProvider { @Autowired private JwtUtil jwtUtil; @Override public boolean supports(Class authentication) { return (JwtAuthenticationToken.class.isAssignableFrom(authentication)); } @Override protected void additionalAuthenticationChecks(UserDetails userDetails, UsernamePasswordAuthenticationToken authentication) throws AuthenticationException { } @Override protected UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication) throws AuthenticationException { JwtAuthenticationToken jwtAuthenticationToken = (JwtAuthenticationToken) authentication; String token = jwtAuthenticationToken.getToken(); User parsedUser = jwtUtil.parseToken(token); if (parsedUser == null) { throw new JwtTokenMalformedException('JWT token is not valid'); } List authorityList = AuthorityUtils.commaSeparatedStringToAuthorityList(parsedUser.getRole()); return new AuthenticatedUser(parsedUser.getId(), parsedUser.getUsername(), token, authorityList); } }

Σε αυτό το μάθημα, χρησιμοποιούμε το προεπιλεγμένο Spring AuthenticationManager, αλλά το κάνουμε με το δικό μας AuthenticationProvider που κάνει την πραγματική διαδικασία ελέγχου ταυτότητας. Για να το εφαρμόσουμε αυτό, επεκτείνουμε το AbstractUserDetailsAuthenticationProvider, το οποίο απαιτεί μόνο να επιστρέψουμε UserDetails με βάση το αίτημα ελέγχου ταυτότητας, στην περίπτωσή μας, το διακριτικό JWT τυλιγμένο στο JwtAuthenticationToken τάξη. Εάν το διακριτικό δεν είναι έγκυρο, ρίχνουμε μια εξαίρεση. Ωστόσο, εάν είναι έγκυρο και αποκρυπτογράφηση από JwtUtil είναι επιτυχής, εξάγουμε τα στοιχεία χρήστη (θα δούμε ακριβώς πώς στην κλάση JwtUtil), χωρίς να έχουμε πρόσβαση καθόλου στη βάση δεδομένων. Όλες οι πληροφορίες σχετικά με τον χρήστη, συμπεριλαμβανομένων των ρόλων του, περιέχονται στο ίδιο το διακριτικό.

JwtUtil.java

public class JwtUtil { @Value('${jwt.secret}') private String secret; /** * Tries to parse specified String as a JWT token. If successful, returns User object with username, id and role prefilled (extracted from token). * If unsuccessful (token is invalid or not containing all required user properties), simply returns null. * * @param token the JWT token to parse * @return the User object extracted from specified token or null if a token is invalid. */ public User parseToken(String token) { try { Claims body = Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); User u = new User(); u.setUsername(body.getSubject()); u.setId(Long.parseLong((String) body.get('userId'))); u.setRole((String) body.get('role')); return u; } catch (JwtException | ClassCastException e) { return null; } } /** * Generates a JWT token containing username as subject, and userId and role as additional claims. These properties are taken from the specified * User object. Tokens validity is infinite. * * @param u the user for which the token will be generated * @return the JWT token */ public String generateToken(User u) { Claims claims = Jwts.claims().setSubject(u.getUsername()); claims.put('userId', u.getId() + ''); claims.put('role', u.getRole()); return Jwts.builder() .setClaims(claims) .signWith(SignatureAlgorithm.HS512, secret) .compact(); } }

Τέλος, το JwtUtil Το μάθημα είναι υπεύθυνο για την ανάλυση του διακριτικού σε User αντικείμενο και δημιουργία του διακριτικού από το User αντικείμενο. Είναι απλό αφού χρησιμοποιεί το jjwt βιβλιοθήκη να κάνει όλη τη δουλειά του JWT. Στο παράδειγμά μας, αποθηκεύουμε απλώς το όνομα χρήστη, το αναγνωριστικό χρήστη και τους ρόλους χρήστη στο διακριτικό. Θα μπορούσαμε επίσης να αποθηκεύσουμε περισσότερα αυθαίρετα πράγματα και να προσθέσουμε περισσότερες λειτουργίες ασφαλείας, όπως η λήξη του διακριτικού. Η ανάλυση του διακριτικού χρησιμοποιείται στο AuthenticationProvider όπως φαίνεται παραπάνω. Το generateToken() Η μέθοδος καλείται από τις υπηρεσίες REST σύνδεσης και εγγραφής, οι οποίες δεν είναι ασφαλείς και δεν θα ενεργοποιήσουν ελέγχους ασφαλείας ή απαιτούν να υπάρχει ένα διακριτικό στο αίτημα. Στο τέλος, δημιουργεί το διακριτικό που θα επιστραφεί στους πελάτες, με βάση το χρήστη.

συμπέρασμα

Παρόλο που οι παλιές, τυποποιημένες προσεγγίσεις ασφαλείας (cookie περιόδου σύνδεσης, HTTP Basic και HTTP Digest) θα λειτουργήσουν και με τις υπηρεσίες REST, όλοι έχουν προβλήματα που θα ήταν ωραίο να αποφευχθούν χρησιμοποιώντας ένα καλύτερο πρότυπο. Το JWT φτάνει έγκαιρα για να σώσει την ημέρα, και το πιο σημαντικό είναι πολύ κοντά στο να γίνει πρότυπο IETF.

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

Κατανόηση των βασικών

Τι είναι το REST;

Το REST, συντομογραφία για την αντιπροσωπευτική μεταφορά κράτους, είναι ένα αρχιτεκτονικό στυλ για την έκθεση σταθερών API μεταξύ των υπηρεσιών ιστού.

Τι είναι το JWT;

Το JSON Web Token (JWT) είναι ένα πρότυπο για την κωδικοποίηση πληροφοριών που μπορούν να μεταδοθούν με ασφάλεια ως αντικείμενο JSON.