Από την πρώτη φορά που προστέθηκε μια σελίδα σύνδεσης σε μια εφαρμογή Web, η ασφάλεια ήταν ανέκαθεν ένα από τα βασικά στοιχεία που είναι κρίσιμα για την επιτυχία των εφαρμογών στον Ιστό. Ιστορικά, όλα κωδικοποιήθηκαν με το χέρι. Κάθε εφαρμογή Ιστού είχε μια προσαρμοσμένη μέθοδο ελέγχου ταυτότητας και εξουσιοδότησης χρηστών. Οι προγραμματιστές ενσωματώνουν επίσης στοιχεία για εγγραφή, διαχείριση και οποιαδήποτε άλλη λειτουργία απαιτείται. Αν και αρκετά γενικά, αυτή η προσέγγιση επέτρεψε μεγάλη ευελιξία.
Με την έλευση του JAAS, της Υπηρεσίας ελέγχου ταυτότητας και εξουσιοδότησης Java, οι εφαρμογές απέκτησαν ένα σύνολο διεπαφών και μια διαμόρφωση που θα μπορούσαν να χρησιμοποιήσουν για την τυποποίηση αυτών των εργασιών. Ακόμη και με την προσθήκη του JAAS στις προδιαγραφές, το J2EE εξακολουθεί να έχει μερικά προβλήματα να επιλύσει προτού οι προγραμματιστές εφαρμογών μπορούν να σταματήσουν να δημιουργούν προσαρμοσμένα API. Η επιλογή μεταξύ της χρήσης των προτύπων J2EE ή της δημιουργίας μιας προσαρμοσμένης λύσης απαιτεί να γνωρίζετε τις αντισταθμίσεις κάθε και, φυσικά, τις απαιτήσεις της εφαρμογής σας.
Αυτό το άρθρο στοχεύει στην παροχή όλων των πληροφοριών που απαιτούνται για την απόφαση μεταξύ προσαρμοσμένης ασφάλειας ή ασφάλειας κοντέινερ. Συζητώ τις πιο συνηθισμένες λειτουργίες ασφαλείας εφαρμογών για να παρέχουμε το απαραίτητο υπόβαθρο για την ασφάλεια. Μετά από αυτήν τη συζήτηση είναι μια λεπτομερής εξήγηση των εφαρμογών ασφαλείας J2EE που παρέχονται από τις προδιαγραφές καθώς και τις πιο κοινές μεθόδους εφαρμογής προσαρμοσμένης ασφάλειας. Αφού κατανοήσετε καλύτερα κάθε μία από τις μεθόδους, θα πρέπει να έχετε αρκετές πληροφορίες για να επιλέξετε ποια μέθοδο ταιριάζει καλύτερα στις απαιτήσεις της εφαρμογής σας.
Τι είναι το εμπορευματοκιβώτιο;
Πριν συζητήσουμε τους διαφορετικούς τύπους ασφάλειας και τις ανησυχίες εφαρμογής ασφάλειας, ας εξετάσουμε τι δοχείο είναι. Το κοντέινερ είναι ένα περιβάλλον στο οποίο εκτελείται μια εφαρμογή. Είναι επίσης συνώνυμο με έναν διακομιστή εφαρμογών J2EE. Όσον αφορά τα κοντέινερ J2EE, μια εφαρμογή J2EE εκτελείται μέσα στο κοντέινερ, το οποίο έχει συγκεκριμένες ευθύνες σε σχέση με την εφαρμογή. Υπάρχουν πολλοί διαφορετικοί τύποι κοντέινερ J2EE και διαφορετικά επίπεδα υποστήριξης J2EE. Το Tomcat από το Apache είναι ένα κοντέινερ Web που εφαρμόζει μόνο τα τμήματα Servlet (εφαρμογή Web) των προδιαγραφών J2EE. Το WebLogic της BEA είναι ένας πλήρως συμβατός διακομιστής εφαρμογών J2EE, που σημαίνει ότι υποστηρίζει όλες τις πτυχές των προδιαγραφών J2EE και έχει περάσει τις δοκιμές πιστοποίησης J2EE της Sun. Εάν δεν είστε σίγουροι για την υποστήριξη που παρέχει ο διακομιστής εφαρμογών σας, επικοινωνήστε με τον προμηθευτή για περισσότερες πληροφορίες.
Ασφάλεια εφαρμογών
Ένα άλλο θέμα που πρέπει να καλύψουμε πριν ξεκινήσουμε είναι η διάκριση μεταξύ ασφάλεια εφαρμογών και άλλους τύπους ασφάλειας. Η ασφάλεια εφαρμογών είναι η ασφάλεια που εκτελείται απευθείας από μια εφαρμογή ή έμμεσα από ένα πλαίσιο ή κοντέινερ για μια εφαρμογή σε σχέση με τους χρήστες αυτής της εφαρμογής. Ένα παράδειγμα ενός χρήστη της εφαρμογής είναι κάποιος που συνδέεται σε ένα διαδικτυακό βιβλιοπωλείο και αγοράζει μερικά βιβλία Java. Υπάρχουν άλλοι τύποι ασφαλείας, όπως η ασφάλεια δικτύου και η ασφάλεια JVM. Ένα παράδειγμα αυτών των τύπων ασφαλείας είναι ο χρήστης που ξεκινά μια διαδικασία Java σε ένα μηχάνημα. Σε όλο το υπόλοιπο αυτής της εργασίας, όποτε συζητάω για την ασφάλεια, εννοώ την ασφάλεια της εφαρμογής. Οι άλλοι τύποι ασφάλειας φτάνουν εκτός του πεδίου εφαρμογής αυτής της συζήτησης.
Η εστίαση εδώ είναι συγκεκριμένα η ασφάλεια J2EE, η οποία είναι ένας τύπος ασφάλειας εφαρμογών, επειδή ασχολείται με τους χρήστες μιας εφαρμογής J2EE (δηλαδή, καλούντες). Ένας χρήστης μπορεί να είναι κάποιος που χρησιμοποιεί το διαδικτυακό βιβλιοπωλείο ή άλλη εφαρμογή που χρησιμοποιεί τις υπηρεσίες αγοράς της εφαρμογής βιβλιοπωλείου, όπως άλλος διαδικτυακός μεταπωλητής.
Λειτουργίες ασφαλείας εφαρμογών
Υπάρχουν πέντε κύριες λειτουργίες κατά την εξέταση της ασφάλειας της εφαρμογής: έλεγχος ταυτότητας, εξουσιοδότηση, εγγραφή, συντήρηση λογαριασμού (ενημερώσεις) και διαγραφή / απενεργοποίηση λογαριασμού. Αν και μόνο ένα μικρό υποσύνολο όλων των πιθανών λειτουργιών που μπορεί να έχει μια εφαρμογή, αυτές είναι οι πιο θεμελιώδεις και αρκετά τυπικές για όλες τις εφαρμογές. Λιγότερο τυπικά, αυτές οι λειτουργίες γνωρίζουν τον χρήστη (έλεγχο ταυτότητας), γνωρίζουν τι μπορεί να κάνει ο χρήστης (εξουσιοδότηση), δημιουργεί νέους χρήστες (εγγραφή), ενημερώνει τις πληροφορίες χρήστη (συντήρηση λογαριασμού) και αφαιρεί έναν χρήστη ή εμποδίζει την πρόσβαση ενός χρήστη στην εφαρμογή (διαγραφή λογαριασμού).
Οι περισσότερες εφαρμογές επιτρέπουν είτε στον χρήστη είτε στον διαχειριστή να εκτελεί αυτές τις λειτουργίες. Όταν οι χρήστες εκτελούν αυτές τις λειτουργίες, το κάνουν μόνοι τους. Οι διαχειριστές εκτελούν πάντα αυτές τις λειτουργίες για λογαριασμό άλλων χρηστών.
Όπως θα απεικονιστεί, όλες αυτές οι λειτουργίες δεν μπορούν να πραγματοποιηθούν χωρίς προσαρμοσμένη λύση, ακόμη και για έλεγχο ταυτότητας. Θα εξετάσουμε το καθένα εν συντομία για να επεξηγήσουμε περαιτέρω τις έννοιες και τι δεν διαθέτει το J2EE που πρέπει να είναι προσαρμοσμένο.
Αυθεντικοποίηση
Ο έλεγχος ταυτότητας είναι η διαδικασία αναγνώρισης ενός χρήστη που αλληλεπιδρά με μια εφαρμογή. Τη στιγμή αυτής της γραφής, ο έλεγχος ταυτότητας J2EE θα μπορούσε να εφαρμοστεί χρησιμοποιώντας μια ποικιλία λύσεων, καθεμία από τις οποίες ορίζεται ως μέρος της προδιαγραφής J2EE (έκδοση 1.0-1.4). Ο έλεγχος ταυτότητας είναι η κύρια ιδέα αυτής της συζήτησης και θα καλυφθεί λεπτομερέστερα αργότερα. Είναι σημαντικό να συνειδητοποιήσετε ότι ο έλεγχος ταυτότητας είναι η λειτουργία ασφαλείας που έχει τη μεγαλύτερη υποστήριξη στην προδιαγραφή J2EE, αλλά συνήθως απαιτείται προσαρμοσμένος κώδικας ή διαμόρφωση για την εφαρμογή ελέγχου ταυτότητας J2EE (γνωστός και ως έλεγχος ταυτότητας κοντέινερ)
Εξουσιοδότηση
Η εξουσιοδότηση είναι η διαδικασία επαλήθευσης ότι ένας χρήστης έχει άδεια να προβεί σε συγκεκριμένη ενέργεια. Το J2EE καλύπτει αυτό το θέμα, αλλά περιορίζεται σε εξουσιοδότηση βάσει ρόλου, πράγμα που σημαίνει ότι η δραστηριότητα μπορεί να περιοριστεί με βάση τους ρόλους που έχει δώσει ο χρήστης. Για παράδειγμα, οι χρήστες του ρόλου διαχειριστή ενδέχεται να είναι σε θέση να διαγράψουν το απόθεμα, ενώ οι χρήστες στο ρόλο των υπαλλήλων ενδέχεται να μην μπορούν.
Επιπλέον, οι εφαρμογές ενδέχεται να εξετάσουν δύο διαφορετικούς τύπους εξουσιοδότησης: Java Runtime Environment (JRE) / κοντέινερ και εξουσιοδότηση εφαρμογής. Η εξουσιοδότηση JRE / κοντέινερ είναι η διαδικασία προσδιορισμού του εάν ο χρήστης που υποβάλλει το αίτημα έχει δικαιώματα να το κάνει. Το JRE / κοντέινερ το καθορίζει αυτό πριν από την εκτέλεση κώδικα. Ένα παράδειγμα είναι ένα κοντέινερ J2EE που πρέπει πρώτα να ελέγξει εάν ο τρέχων χρήστης έχει δικαιώματα εκτέλεσης ενός servlet (μέσω ενός περιορισμού διεύθυνσης URL πόρου) πριν από την εκτέλεση του servlet. Αυτός ο τύπος εξουσιοδότησης είναι επίσης γνωστός ως δηλωτική ασφάλεια επειδή δηλώνεται στα αρχεία διαμόρφωσης για την εφαρμογή Web. Εάν δεν υποστηρίζεται από το κοντέινερ, η δηλωτική ασφάλεια δεν μπορεί να τροποποιηθεί κατά το χρόνο εκτέλεσης. Η δηλωτική ασφάλεια μπορεί να χρησιμοποιηθεί με πολλούς τρόπους για την εξουσιοδότηση των χρηστών της εφαρμογής J2EE, αλλά αυτό το θέμα δεν εμπίπτει στο πεδίο αυτής της συζήτησης. (Ανατρέξτε στο Κεφάλαιο 12. Προδιαγραφή Servlet 2.3. Η ενότητα 2 καλύπτει τη δηλωτική ασφάλεια και το 8 είναι ένα καλό σημείο εκκίνησης για περιορισμούς ασφαλείας.)
Όπως αναφέρθηκε προηγουμένως, ο χρήστης μπορεί να είναι μια άλλη εφαρμογή ή απλά ένας χρήστης της εφαρμογής. Είτε έτσι είτε αλλιώς, η έγκριση JRE / κοντέινερ πραγματοποιείται κατά τη διάρκεια κάθε αιτήματος. Αυτά τα αιτήματα μπορεί να είναι αιτήματα HTTP από πρόγραμμα περιήγησης σε εφαρμογή Web ή απομακρυσμένες κλήσεις EJB (Enterprise JavaBeans). Σε κάθε περίπτωση, υπό την προϋπόθεση ότι το JRE / κοντέινερ γνωρίζει τον χρήστη, μπορεί να εκτελέσει εξουσιοδότηση βάσει των πληροφοριών αυτού του χρήστη.
Η εξουσιοδότηση αίτησης είναι η διαδικασία εξουσιοδότησης καθώς εκτελείται η εφαρμογή. Η εξουσιοδότηση εφαρμογής μπορεί περαιτέρω να αναλυθεί σε εξουσιοδότηση βάσει ρόλου και τμημάτων. Ένα παράδειγμα εξουσιοδότησης εφαρμογής βάσει ρόλου είναι όταν μια εφαρμογή εφαρμόζει διαφορετικά επίπεδα σήμανσης με βάση το εάν ένας χρήστης είναι υπάλληλος ή επισκέπτης (δηλαδή, έκπτωση εργαζομένου). Το J2EE παρέχει API που ονομάζονται προγραμματική ασφάλεια για να ολοκληρώσετε την εξουσιοδότηση βάσει ρόλου (δείτε το Servlet 2.3 Specification Κεφάλαιο 12, Ενότητα 3 για περισσότερες πληροφορίες).
Η εξουσιοδότηση βάσει τμήματος είναι εξουσιοδότηση βάσει άλλων χαρακτηριστικών ενός χρήστη, όπως ηλικία ή χόμπι. Η εξουσιοδότηση βάσει τμήματος ονομάζεται τέτοια, επειδή ομαδοποιεί τους χρήστες σε τμήματα βάσει συγκεκριμένων χαρακτηριστικών. Το J2EE δεν έχει καμία μέθοδο εφαρμογής εξουσιοδότησης βάσει τμήματος. Ένα παράδειγμα εξουσιοδότησης βάσει τμημάτων είναι αν ένα κουμπί σε μια φόρμα είναι ορατό σε χρήστες άνω των 40 ετών. Ορισμένοι προμηθευτές ενδέχεται να προσφέρουν αυτόν τον τύπο εξουσιοδότησης, αλλά αυτό θα εγγυάται το κλείδωμα του πωλητή σε όλες τις περιπτώσεις.
Εγγραφή
Η εγγραφή είναι η διαδικασία προσθήκης ενός νέου χρήστη στην εφαρμογή. Οι χρήστες εφαρμογών ενδέχεται να είναι σε θέση να δημιουργήσουν νέους λογαριασμούς για τους ίδιους ή η εφαρμογή μπορεί να επιλέξει να περιορίσει αυτήν τη δραστηριότητα στους διαχειριστές εφαρμογών. Η προδιαγραφή J2EE δεν διαθέτει API ή διαμόρφωση που επιτρέπει στις εφαρμογές να προσθέτουν νέους χρήστες. Επομένως, αυτός ο τύπος ασφάλειας είναι πάντα κατασκευασμένος κατά παραγγελία. Η J2EE δεν έχει τη δυνατότητα να πει στο κοντέινερ ότι έχει εγγραφεί νέος χρήστης και ότι οι πληροφορίες της πρέπει να διατηρηθούν και να διατηρηθούν κατά τη διάρκεια της συνεδρίας της.
Συντήρηση
Η συντήρηση λογαριασμού είναι η διαδικασία αλλαγής πληροφοριών λογαριασμού, όπως στοιχεία επικοινωνίας, συνδέσεις ή κωδικοί πρόσβασης. Οι περισσότερες εφαρμογές επιτρέπουν στους χρήστες εφαρμογών, καθώς και στους διαχειριστές, να εκτελούν συντήρηση. Η προδιαγραφή J2EE δεν διαθέτει επίσης API ή διαμόρφωση για τη συντήρηση λογαριασμού. Λείπει ένας μηχανισμός για την ενημέρωση του κοντέινερ ότι οι πληροφορίες χρήστη έχουν αλλάξει.
Διαγραφή
Η διαγραφή λογαριασμού περιορίζεται συνήθως σε διαχειριστές μόνο. Σε σπάνιες περιπτώσεις, ορισμένες εφαρμογές ενδέχεται να επιτρέπουν στους χρήστες να διαγράφουν τους δικούς τους λογαριασμούς. Οι περισσότερες εφαρμογές δεν διαγράφουν ποτέ χρήστες. απλώς απενεργοποιούν τον λογαριασμό, έτσι ώστε ο χρήστης να μην μπορεί πλέον να συνδεθεί. Η σκληρή και γρήγορη διαγραφή συνήθως αψηφείται επειδή τα δεδομένα του λογαριασμού είναι πολύ πιο δύσκολο να ανακτηθούν αν χρειαστεί. Το J2EE δεν παρέχει κανέναν τρόπο αφαίρεσης ή απενεργοποίησης χρηστών από εφαρμογές. Δεν διαθέτει μηχανισμό για να πει στο κοντέινερ ότι ένας συγκεκριμένος χρήστης έχει απενεργοποιηθεί ή καταργηθεί. Η J2EE στερείται επίσης μηχανισμού για άμεση αποσύνδεση ενός χρήστη από την εφαρμογή όταν ο λογαριασμός της έχει διαγραφεί.
Τι είναι ο έλεγχος ταυτότητας κοντέινερ;
Ο έλεγχος ταυτότητας κοντέινερ είναι η διαδικασία γνωστοποίησης στο κοντέινερ της ταυτότητας του χρήστη που υποβάλλει το τρέχον αίτημα. Για τα περισσότερα κοντέινερ, αυτή η διαδικασία περιλαμβάνει τη σύνδεση του τρέχοντος ServletRequest αντικείμενο, το τρέχον νήμα εκτέλεσης και μια εσωτερική περίοδος σύνδεσης με την ταυτότητα του χρήστη. Συνδέοντας μια περίοδο σύνδεσης με την ταυτότητα, το κοντέινερ μπορεί να εγγυηθεί ότι το τρέχον αίτημα και όλα τα επακόλουθα αιτήματα του ίδιου χρήστη μπορούν να συσχετιστούν με την ίδια περίοδο λειτουργίας, έως ότου λήξει η περίοδος σύνδεσης του χρήστη. Αυτό το αντικείμενο συνεδρίας συνήθως δεν είναι το ίδιο με το HttpSession αντικείμενο, αν και το πρώτο χρησιμοποιείται για τη δημιουργία και τη συντήρηση του τελευταίου. Κάθε επόμενο αίτημα από τον ίδιο χρήστη συσχετίζεται με τη συνεδρία χρησιμοποιώντας είτε την επανεγγραφή διευθύνσεων URL είτε ένα cookie περιόδου λειτουργίας, σύμφωνα με το Servlet 2.3 Specification, Κεφάλαιο 7.
Όπως αναφέρθηκε παραπάνω στη συζήτησή μας σχετικά με την εξουσιοδότηση, κάθε ενέργεια που πραγματοποιεί το κοντέινερ καθώς και κάθε ενέργεια που αναλαμβάνει το JRE για λογαριασμό αυτού του χρήστη ελέγχονται προσεκτικά για να διασφαλιστεί ότι ο χρήστης έχει άδεια να εκτελέσει την ενέργεια. Για να επαναλάβουμε το προηγούμενο παράδειγμά μας, όταν το κοντέινερ εκτελεί ένα servlet εκ μέρους του χρήστη, επαληθεύει ότι ο χρήστης ανήκει στο σύνολο των ρόλων που έχουν δικαιώματα για την εκτέλεση αυτού του servlet. Το JRE 1.4 εκτελεί επίσης αυτούς τους ελέγχους για πολλές ενέργειες, όπως όταν ανοίγει ένα αρχείο ή μια υποδοχή. Ο έλεγχος ταυτότητας JRE είναι μια ισχυρή ιδέα και μπορεί να διασφαλίσει ότι κάθε αίτημα προς ένα κοντέινερ είναι ουσιαστικά ασφαλές.
Επί του παρόντος, το J2EE παρέχει μερικούς διαφορετικούς μηχανισμούς για την εφαρμογή ελέγχου ταυτότητας χρήστη. Αυτά περιλαμβάνουν έλεγχο ταυτότητας βάσει φόρμας, έλεγχο ταυτότητας πελάτη HTTPS και βασικό έλεγχο ταυτότητας HTTP. Το JAAS περιλαμβάνεται ως μια απαιτούμενη μέθοδος ελέγχου ταυτότητας που πρέπει να υποστηρίζουν τα κοντέινερ. Ωστόσο, η προδιαγραφή δεν είναι αυστηρή σχετικά με το πώς το κοντέινερ πρέπει να παρέχει αυτήν τη λειτουργικότητα. Επομένως, κάθε κοντέινερ παρέχει διαφορετική υποστήριξη για το JAAS. Επιπλέον, το JAAS από μόνο του είναι ένα αυτόνομο πλαίσιο ελέγχου ταυτότητας και θα μπορούσε να χρησιμοποιηθεί για την εφαρμογή ελέγχου ταυτότητας κοντέινερ ανεξάρτητα από το αν η προδιαγραφή το υποστηρίζει. Θα εξηγήσω αυτήν την ιδέα με περισσότερες λεπτομέρειες αργότερα.
Κάθε ένας από τους μηχανισμούς ελέγχου ταυτότητας παρέχει έναν τυπικό τρόπο παροχής πληροφοριών στο κοντέινερ για τον χρήστη. Αναφέρομαι σε αυτό ως πραγματοποίηση διαπιστευτηρίων. Το κοντέινερ πρέπει ακόμη να χρησιμοποιήσει αυτές τις πληροφορίες για να επαληθεύσει ότι ο χρήστης υπάρχει και έχει επαρκή δικαιώματα για την υποβολή του αιτήματος. Αναφέρομαι σε αυτό ως πιστοποίηση πιστοποίησης. Ορισμένα κοντέινερ παρέχουν διαμόρφωση για ρύθμιση του ελέγχου ταυτότητας διαπιστευτηρίων και άλλα παρέχουν διεπαφές που πρέπει να εφαρμοστούν.
Μέθοδοι ελέγχου ταυτότητας J2EE
Ας δούμε εν συντομία μερικές από τις πιο κοινές μεθόδους για την εφαρμογή και τη διαμόρφωση του ελέγχου ταυτότητας κοντέινερ.
Έλεγχος ταυτότητας βάσει φόρμας
Ο έλεγχος ταυτότητας βάσει φόρμας επιτρέπει στους χρήστες να αναγνωρίζονται και να πιστοποιούνται με τον διακομιστή εφαρμογών J2EE χρησιμοποιώντας οποιαδήποτε φόρμα HTML. Η φόρμα δράσης πρέπει να είναι j_security_check και δύο παράμετροι αιτήματος HTTP (πεδία εισαγωγής φόρμας) πρέπει πάντα να βρίσκονται στο αίτημα, μία που καλείται j_ όνομα χρήστη και το άλλο, j_password. Χρησιμοποιώντας έλεγχο ταυτότητας βάσει φόρμας, η πραγματοποίηση διαπιστευτηρίων πραγματοποιείται όταν η φόρμα υποβάλλεται και το όνομα χρήστη και ο κωδικός πρόσβασης αποστέλλονται στο διακομιστή.
Ακολουθεί ένα παράδειγμα σελίδας JSP (JavaServer Pages) που χρησιμοποιεί έλεγχο ταυτότητας βάσει φόρμας:
Είσοδος Εισαγάγετε το όνομα χρήστη σας:Εισάγετε τον κωδικό σας:
