Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.
| Inhalt | Abbildung | Source | SCWCD | |||
| |< | < | > | >| | Generated by CoCoDiL | ||
| Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality. |
Authentication
Darunter versteht man den Prozeß die Identität eines Clienten bzw. Anwenders festzustellen. Das einfachste Mittel ist durch Eingabe von Benutzernamen und Passwort. In Zukunft könnten das Scannen von Fingerabdruck, Augen Iris sein. Die Authentication beschäftigt sich nicht mit Rechtevergabe ist aber die Vorraussetzung dazu.
Authorization
Ist die Identität des Benutzers festgestellt, so ist der nächste logische Schritt die Authorization. Hier geht es darum festzustellen ob der Anwender die Rechte hat, auf die angeforderten Ressourcen zuzugreifen.
Data Integrity
Data Integrity ist der Prozeß zu versichern, dass während der Übertragung sich die Daten nicht verändert haben. Dies kann z.B. durch Prüfsummenbildung geschehen.
Confidentialy
Confidentialy sichert, dass kein unerlaubter Anwender vertrauliche Daten lesen kann. Während Authorization versucht den Zugang zu Daten zu regeln, versucht Confidentialy die Daten selbst dann zu schützen, falls ein Unbefugter die Daten schon bekommen hat. Dies geht durch Verschlüsselungsstrategien.
| In the deployment descriptor, declare a security constraint, a Web resource, the transport guarantee, the login configuration, and a security role. |
Eine Security Constraint definiert welche Ressourcen auf welche Art geschützt werden sollen. Sie besteht aus i.a. drei Unterelementen
web-resource-collection
Mit einem URL-Pattern spezifiziert man, welche Ressourcen zu schützen sind. Zusätzlich können noch Angaben zu den für den Zugriff auf die jeweiligen Ressource erlaubten HTTP-Methoden gemacht werden.
auth-constraint
Alle Benutzer, die die angegebene Rolle innehaben, können auf die geschätzten Web-Ressource zugreifen. Die Rollen müssen in der Datei web.xml in dem Element security-role definiert sein.
Beispiel:
Statt eines bestimmten Rollennamens kann auch der Matchcode '*' verwendet werden, soll die Ressource für alle der Anwendung bekannten Rollen freigegeben werden. Wird dagegen keine der Rollen angegeben, ist dieser Teil der Wbanwendung für alle Benutzer gesperrt.
user-data-constraint
Das Unterelement transport-guarantee kann folgende Werte annehmen:
| Name | Bedeutung |
| None | Keine Anforderung (Default Wert) |
| Integral | Daten dürfen beim Versenden nicht verändert werden |
| Confidential | Daten dürfen beim Versenden nicht von Dritten eingesehen werden |
Beispiel:
Dieses security Constraint schützt alle Ressourcen deren UI mit /admin anfängt. Es dürfen nur Benutzer mit der Rolle admin auf diese Ressourcen zugreifen. Ausserdem kann der Zugriff nur über die get Methode erfolgen. Bei der Übertragen der Daten muss garantiert sein, dass diese nicht von Dritten einsehbar ist.
login-config
Mit dem Element login-config wird in der Datei web.xml bestimmt welche Typ zur Authentifizierung genommen wird (siehe weiter unter).
Beispiel:
Das Element auth-method kann eine der Methoden BASIC,DIGEST,FORM oder CLIENT-CERT annehmen. Der realm-name wird bei dem Formalar das der Brwoser zur Eingabe von Benutzer und Passwort eingibt, angezeigt.
Wird die Authentifizierung FORM benutzt, muss die Seite zur Login Eingabe und die Fehlerseite falls der Login fehlerhaft ist angegeben werden.
| Compare and contrast the authentication types (BASIC, DIGEST, FORM, and CLIENT-CERT); describe how the type works; and given a scenario, select an appropriate type. |
Es werden 5 Möglichkeiten angeboten, wie man einen Anwender indentifizieren kann.
| Name | Bedeutung |
| BASIC | HTTP-Authentifizierung auf der Basis von Benutzername und Passwort |
| DIGEST | Verschlüsselte Übergabe des Passworts |
| FORM | Basis Authentifizierung, über ein benutzerdefiniertes Login-Formular |
| CLIENT-CERT | Https-Client-Authentifizierung |
HTTP BASIC Authentication
Die Identitifizierung läuft folgendermassen ab.
HTTP DIGEST Authentication
Die Identifizierung läuft fast identisch mit der Methode BASIC ab. Allerdings gibt es einen Mechanismus um das Passwort zu verschlüsseln.
HTTP FORM Authentication
Dies ist die einzigste Typ indem der Programmierer die Anmeldeseite selber gestalten kann. Folgende Konventionen gelten für eine selber formulierte Anmeldeseite:
HTTPS CLIENT-CERT Authentication
Es wird das HTTPS Protokoll (SSL-Verbindung) verwendet und die Daten werden mit einem Public-Key Verfahren verschlüsselt. Dies ist die sicherste Methode benötigt aber eine Zertifizierung von einer autorisierten Stellen. Genaue Kenntnisse über das Verfahren, ist für die Zertifizierung wahrscheinlich nicht notwendig.
Die Vor- und Nachteile habe ich in einer Tabelle zusammengefasst
| TYP | VORTEILE | NACHTEILE |
| BASIC | Jeder Browser unterstützt es | Aussehen der Login-Page nicht wählbar |
| Sehr einfach zu konfigurieren | Sehr unsicher Passwort und Benutzername nicht verschlüsselt | |
| DIGEST | Sehr einfach zu konfigurieren | Aussehen der Login-Page nicht wählbar |
| Sicherer als BASIC. Es wird Passwort verschlüsselt | Nicht jeder Browser unterstützt es | |
| FORM | Alle Browser unterstützen es | Nicht sicher da Benutzer und Passwort nicht verschlüsselt |
| Look and Feel Login-Page wählbar | Sollte nur im Zusammenhang mit HTTPS oder Cookies verwendet werden | |
| Einfach zu konfigurieren | ||
| HTTPS CLIENT CERT | Das sichertse aller Verfahren | Zertifizierung durch autorisierte Stelle notwendig |
| Wird von allen Browser unterstützt | teuer |
| Inhalt | Abbildung | Source | SCWCD | |||
| |< | < | > | >| | Generated by CoCoDiL | ||