AuthenticationString, welchen der IIS liefert, extra- hiert. Die Methode liefert dem Konstruktor der User-Klasse ein Objekt vom Typ DirectoryEntry zurück; der Konstruktor setzt dieses dann als Attribut des erzeugten User-Objekts. Ändert der Anwender seine Sicherheitsfrage, die Antwort oder den Status der Rücksetzfunk- tionalität über die Weboberfläche, werden – nach Validierung der Eingabe – die geänderten Werte als Attribute des User-Objekts gesetzt und die Methode Save() aufgerufen, welche die Werte dann der Reihe nach mit der SetProperty()-Methode (Listing 2) in das AD schreibt. Die Kommunikation zwischen dem User-Model und dem View, welches der Anwender in Form einer Webseite präsentiert bekommt, findet über den Controller statt. Im Controller ist hierzu für jedes Formular eine Aktion hinterlegt, die auf ein oder mehrere HTTP-Verben (GET, POST, PUT, DELETE) reagieren kann. Dies hat den Vorteil, dass die Webapplikation nach außen hin vollständig Representational State Transfer (REST)-konform aufgebaut ist. Das Beispiel in Listing 3 verdeutlicht das Prinzip: Der Anwender greift per GET auf die Ressour- ce /User/Edit/5 zu. Schon anhand des Uniform Resource Identifier (URI) erkennt ActionRe- sult, dass es den Nutzer (/User) Nr. 5 (/5) bearbeiten (/Edit) muss.2 Hat der Anwender das Formular ausgefüllt und sendet es ab, so greift er wieder auf dieselbe Ressource /User/Edit/5 zu, diesmal jedoch per POST-Request. Der Controller erkennt dies und liefert daher nicht das normale Edit-View aus, sondern übergibt die POST-Daten (nach Validierung) an das User-Model und liefert dem Anwender ein angepasstes View, welches diesen z.B. über die erfolgte Änderung der Daten informiert. 3.3 Password Reset Der lesende Zugriff auf das AD geschieht in der zweiten Applikation, Password Reset, analog zu dem der User Self Service Applikation. Im Unterschied zu dieser wird der im AD nachzu- schlagende Eintrag jedoch nicht über den vom IIS gelieferten AuthenticationString identifiziert, sondern über den Vor- und Nachnamen, den der Anwender eingibt und damit über die Felder sn und givenname im AD. In der Skizze der Nutzeroberfläche (Abbildung 3.3) ist dies Schritt 1. Verläuft die im Hintergrund stattfindende Prüfung, ob der Name im AD existiert und ob die Rücksetzfunktionalität für diesen Nutzer freigeschaltet ist, erfolgreich, so bekommt der An- wender zusätzlich das in der Skizze als Schritt 2 gekennzeichnete Formular mit seiner zuvor gewählten Sicherheitsfrage und der Aufforderung, die zugehörige Antwort einzugeben, präsen- tiert. Beantwortet er die Frage korrekt mit der von ihm gewählten Antwort, so erhält er den Hinweis, dass ihm ein neues Kennwort zugestellt wird (Schritt 3). Die eingesetzten Technologien sind hier weitgehend identisch zu denen der ersten Anwendung und seien daher nur kurz erwähnt: Es handelt sich um eine einfache, vollständig REST-konform aufgebaute Webapplikation, die nach dem MVC-Architekturprinzip konzipiert ist. Hinzu kommen bei der Password Reset Applikation die beiden für die Zustellung der SMS und 2Prinzipiell kann so jedes Objekt, nicht nur die Nr. 5, bearbeitet werden. In unserem konkreten Anwendungsfall hat der Anwender jedoch ausschließlich das Recht, seine eigene Instanz des User-Models zu ändern, daher kann hier die Referenz auf eine bestimmte User-ID entfallen. Der Anwender, und damit das zu bearbeitende User-Objekt, wird gegenüber dem Programm über den vom IIS gelieferten AuthenticationString identifiziert.