Die WS-Security ist ein standardisierter Bestandteil der WS-*-Spezifikation. Der von IBM, Microsoft und der Firma Visign entwickelte und von einem Gremium im Zuge von Oasis Open weiterentwickelte Industriestandard. Die Norm enthält Vorgaben, wie die Integrität und Verschlüsselung von Nachrichten im Zusammenhang mit Web Services gewährleistet werden kann. WS-Security verschreibt jedoch nicht alle Einzelheiten, sondern stützt sich vielmehr auf die bestehenden "Verfahren" (XML-Signatur und XML-Verschlüsselung).
Die WS-Security umfasst drei Hauptmechanismen: die Fähigkeit, Sicherheitstoken als Teil der SOAP-Nachricht zu übermitteln, die Chiffrierung von Messages. Dieser legt fest, wo und wie Unterschriften, Kodierungsinformationen und Sicherheits-Token in die SOAP-Nachricht einzufügen sind. Für die Erzeugung des SecurityToken gibt es folgende Profile: Folgende WS*-Spezifikationen sind eng mit der WS-Sicherheit verwandt: Statt WS-Sicherheit (Message-Layer) können Sie auch auf der Transportschicht über Zusatzprotokolle wie z.B. HTTPS einrichten.
Die Sicherheit der Nachrichtenschicht sorgt für eine bessere Übersicht.
Diese Anleitung zeigt, wie Web Services durch Kennwortverfahren gesichert werden können. Die Web Service Security Specification (WSS)[1] gibt es für Web Services im Sicherheitsbereich. Das Hauptobjekt des UsernameTokenProfile ist der BenutzernameToken, der an den Service im SOAP-Header übergeben wird. Bsp. 1: Das Element UsernameToken: Unter dem Benutzernamen wird der Benutzernamen spezifiziert, Passwort beinhaltet entweder das Klartextkennwort oder den Hashwert des Klartextkennworts abhängig vom Typ des Attributs, NICHT und Erstellt sollten Replay-Angriffe verhindern, bei denen ein BenutzernameToken von einem Hacker aufgefangen und vom Hacker selbst in SOAP-Nachrichten ausgenutzt wird.
Mit einem Benutzernamen-Token kann ein Hacker eine Meldung abhören und zu einem beliebigen Termin an den Dienst zurücksenden. Der mitgelieferte BenutzernameToken würde den Täter zur Benutzung des Dienstes berechtigen. Damit dies nicht passiert, wird jeder BenutzernameToken mit einer einmaligen Zahl gekennzeichnet (Nonce). Dieser Service speichert diese Zahl und lehnt neue BenutzernameToken mit der selben Nummern ab.
Damit die Anzahl der verwendeten Zahlen nicht weiter zunimmt, wird in jedem BenutzernamenToken ein Timestamp (Created) übergeben. Ein BenutzernameToken ist nach Verstreichen der Zeit nicht mehr aktuell. Nicht immer ist es möglich, den Hashwert des Passwortes im Passwortelement zu übergeben, da der Dienst unter Umständen keinen Zugang zu den Klartextpasswörtern der Nutzer hat und daher nicht einmal deren Hashwert zum Abgleich errechnen kann.
Die zu übertragenden Benutzernamen-Token müssen dann mit WS-Security verschlüsselt werden. Nachfolgend wird erläutert, wie dies mit dem Web Service Stack Metro[3] erreicht werden kann. Zur Demonstration, wie ein Webservice mit einem BenutzernamenToken abgesichert werden kann, muss er zunächst angelegt werden. Es wird kein Schwerpunkt auf eine aufwändige Umsetzung gesetzt, es geht einfach darum, einen Webservice zu schaffen, der dann gespeichert werden kann.
In NetBeans legen Sie ein weiteres zu sicherndes Webdienstprojekt an. Das für den Web Service geschaffene Basis-Framework muss nun mit neuem Schwung gefüllt werden: Erweitern Sie unter Project den Web Services-Verzeichnis und doppelklicken Sie auf UsernameTokenService -> Switch to Source View (in der oberen linken Ecke des Hauptfensters).
Der eingesetzte Webservice sollte nun so abgesichert sein, dass nur noch authentisierte Anwender ihn nutzen können. Authentisierung sollte durch BenutzernameToken durchgeführt werden. Dazu sind folgende Arbeitsschritte erforderlich: Klicken Sie mit der rechten Maustaste auf UsernameTokenService im Ordner Web Services -> Web Service Attribute bearbeiten -> Check Secure Service.
Jetzt ist es möglich, einen Sicherheitsmechanismus auszusuchen. Für die Datensicherung mit BenutzernameToken muss der korrespondierende Eintrag gewählt werden-> Sicherheitsmechanismus: Benutzernamenauthentifizierung mit symmetrischem Schlüssel. Zum Schluss stellen Sie den gesicherten Webservice auf GlassFish bereit: Klicken Sie mit der rechten Maustaste auf Project -> Select "Undeploy and Deploy". Nach dem Deployment des Services muss ein User für seine Nutzung angelegt werden.
Wählen Sie in der Registerkarte NetBeans Services -> Server erweitern -> Rechtsklicken Sie auf GlassFish V2 und wählen Sie GlassFish V2 aus. Die Verbindung zu http://localhost:4848 wird über den Webbrowser hergestellt. Klicke im rechten Teilfenster Konfiguration -> Sicherheit -> Realms -> Datei und dann auf Benutzer verwalten. Sie können jetzt den Web-Service-Benutzer anlegen:
Klicke auf Neu -> Benutzer-ID: Mandant, Gruppenliste: freigelassen, Neues Passwort und Neues Passwort bestätigen: Mandant -> OK. Nach dem Anlegen des Web Service und dem Anlegen eines berechtigten Benutzers kann der Mandant eingesetzt werden.
Datei -> Neues Projekt...-> Kategorien: Java und Projekte: Java-Anwendung -> Weiter -> Projektname: BenutzerServiceSOClient, Hauptklasse erstellen:lient. Anmerkung: Die URL für die WSDL-Datei lautet wie folgt: X korrespondiert per Default mit dem Name der implementierenden Klasse des Web Service plus dem Zusatz Service. Zugleich setzt die Spezifizierung dieses Attributes das Namensattribut des Service-Elements in der für den Web Service erzeugten WSDL-Datei auf ABC-Service.
Dies gilt nicht nur für die WSDL-URL, sondern auch für die Aufrufe des Web Service. Rechtsklicken Sie auf das erstellte Objekt -> Eigenschaften -> links wählen Sie die Bibliothek aus -> rechts auf " JAR/Ordner hinzufügen ", um die Bibliothek webservices-rt. jar und webservices-tools. jar aus METRO_HOME/lib -> OK aus.
Die Stub-Klassen für den Web Service-Aufruf müssen dann erzeugt werden: Erweitern Sie im Rahmen des Projektes den Verzeichnis "Web Service References" -> klicken Sie mit der rechten Maustaste auf UsernameTokenServiceService -> Web Service Attribute bearbeiten -> Check bei Use development default (Hinweis: Der Häkchen bei NetBeans wird nicht angezeigt, Fehler in NetBeans, wenn der Verzeichnis META-INF nach einem Mausklick auf Finish im Verzeichnis "Source Packages" angelegt wurde).
Mit Hilfe der Angaben im BenutzernamenToken nimmt er dann die Zugangskontrolle vor. Beim Betrachten des Verschlüsselungsverfahrens werden Sie feststellen, dass der BenutzernameToken auch mit dem öffentlichen Key des Server kodiert werden kann. Es dürfen nur asymmetrische Verschlüsselungen mit Hilfe der Public-Key-Kryptographie durchgeführt werden. Jetzt muss der tatsächliche Applikationscode für den Abruf des gespeicherten Dienstes eingetragen werden.
Die Vorgehensweise ist wie folgt: im Client. In der Gattung Security werden diese Angaben gespeichert. BenutzerpasswortInfo in statische Variable, die für diesen Zweck bereitgestellt werden und daher Sicherheit für den Benutzer des JAX-WS-Handlers bieten. Er generiert dann aus den Nutzdaten den gewünschten Benutzernamen-Token. 7. security.
BenutzernameTokenHandler implementieren: Paketsicherheit; java.util importieren. Zehn. Jetzt muss es ein Kunde sein. Haupt (siehe Beispiel 5): Zu Anfang werden die für den Serviceabruf zu benutzenden Nutzdaten aus der Befehlskonsole ausgelesen und in BenutzerkennwortInfo gespeichert.
Anschließend werden die erzeugten Service-Client-Klassen benutzt und der UsernameTokenHandler als Behandler für Service-Aufrufe eingefügt. Danach erfolgt der tatsächliche Serviceabruf. Schließlich kann der Klient begonnen werden: Klicken Sie dann mit der rechten Maustaste auf den Kunden. Der vorliegende Beitrag beschreibt die erforderlichen Maßnahmen, um einen Webdienst mit NetBeans und GlassFish mit einem Passwort zu sichern und einen zugehörigen Kunden zu erzeugen.
Zuerst wurde der zu unterstützende Webservice angelegt und mit dem Sicherungsmechanismus Benutzerauthentifizierung mit symmetrischem Schlüssel zur Aktivierung der Authentisierung mit BenutzernameToken gesichert. Anschließend wurde in GlassFish ein Nutzer für die Benutzung des Dienstes angelegt, der einen Benutzernamen und ein Kennwort angibt. Nachdem die Stub-Klassen angelegt waren, musste die erzeugte Konfigurations-Datei angepasst und zusammen mit der gewünschten Keystore-Datei an den richtigen Ort kopiert werden.
Das Herzstück der Clientanwendungslogik war das Festlegen des angefragten Usernamens und Passwortes in einem JAX-WS-Handler. xml.ws importieren. Importsicherheit.