Der Countdown läuft für die Keyfactor Tech Days | Sichern Sie sich noch heute Ihren Platz!

  • Startseite
  • Blog
  • Integration von benutzerdefinierten Funktionen in das FIM-Portal

Integration von benutzerdefinierten Funktionen in das FIM-Portal

Kürzlich wollte ein Kunde seinen Benutzern die Möglichkeit geben, bestimmte alternative SMTP-Adressen für die Entfernung über das FIM-Portal auszuwählen.

Wir haben erwogen, das Schema um mehrere Attribute für jeden Benutzer zu erweitern, um die alternativen SMTP-Adressen und ein entsprechendes Kennzeichen für eine Löschungsanfrage zu speichern, aber da jeder Benutzer Dutzende von alternativen Adressen haben könnte, wäre diese Lösung nicht gut skalierbar.

Wenn Sie die Kontrollkästchen oder Optionsfelder in FIM verwenden, gibt es zwei Möglichkeiten, die verfügbaren Werte in diese Listen einzutragen. Die eine besteht darin, sie im RCDC zu kodieren, was funktioniert, wenn es eine Reihe von Werten gibt, die global für alle Benutzer gelten würden. Bei E-Mail-Adressen würde dies nicht funktionieren. Die andere Möglichkeit besteht darin, einen neuen Ressourcentyp zu erstellen, um die Verwaltung dieser Werte zu ermöglichen. Das Hinzufügen eines Ressourcentyps "secondary smtp" hätte die Größe des Metaversums und die Synchronisierungszeiten stark erhöht. Das wäre so, als würde man mit einem Vorschlaghammer einen losen Dielennagel einschlagen.

Also haben wir unsere SharePoint-Entwicklerfähigkeiten wieder hervorgekramt und eine benutzerdefinierte Funktion erstellt.

Das Ergebnis ist eine Seite, die aussieht, als wäre sie Teil des FIM-Portals, die aber in Wirklichkeit das aspx-Kontrollkästchen und in einer indizierten Zeichenfolge gespeicherte Werte verwendet. Wir haben einfach einen Link zu der Seite auf dem RCDC des Benutzers hinzugefügt:

sv15asv15b

Die Proxy-Adressensammlung wird von AD zum FIM-Dienst über die FIM-Synchronisierung in ein indiziertes mehrwertiges String-Attribut geschrieben. Die benutzerdefinierte Funktion liest diese Werte aus und zeigt dem Benutzer eine Liste von Optionen an, die er ankreuzen kann. Durch das Abwählen eines Elements und das Absenden wird das Attribut der Proxy-Adressensammlung aktualisiert, so dass es an AD zurückfließen kann.

(Diese Funktion befindet sich auf einer SharePoint-Seite und ist nicht Teil des RCDC).

Wir haben die ILM2-Musterseite verwendet, um der Checkbox-Liste das Aussehen des FIM-Portals zu geben. Dann haben wir eine Seite gehostet, die die Funktion in einer Bibliothek auf der SharePoint-Website des Portals bereitstellte.

Der knifflige Teil bestand darin, dem Code Zugriff auf das SharePoint-Objektmodell zu gewähren, um die bestehende Sitzung des Benutzers beizubehalten und nicht zu einer erneuten Authentifizierung auffordern zu müssen. Eine schnelle und schmutzige Methode, dies zu tun, ist, die Vertrauensstufe der Website auf voll einzustellen, aber das ist ein Sicherheitsrisiko. Dadurch würde allen Baugruppen auf dem Server volles Vertrauen gewährt. Ein anderer schneller Ansatz besteht darin, die Assembly in der GAC zu installieren. Dadurch wird ihr volles Vertrauen für alle Anwendungen auf dem Server gewährt, was natürlich eine größere Bandbreite an Berechtigungen bedeutet, als sie benötigt.

Die Lösung bestand darin, die Codezugriffssicherheit mit einer benutzerdefinierten Richtliniendatei anzupassen. Mit dieser Datei können wir eine bestimmte Vertrauensstufe nur für unsere Baugruppe gewähren. Die Berechtigung wird dem Code gewährt und nicht dem Benutzer, der den Code ausführt.

Zuerst haben wir die Datei wss_minimal.config in die CONFIG-Datei des 14-Hive kopiert und sie wss_custom.config genannt.

Sie wurde dann wie unten beschrieben geändert:

Mit der Visual Studio command Eingabeaufforderung extrahierten wir den Public Key Blob in eine Textdatei. Nachdem wir zu dem Verzeichnis mit der .snk-Datei für unsere Assembly navigiert hatten, führten wir diese Befehle aus:

Sn -p MeinDateiname.snk PKNur.snk

Sn -tp PKNur.snk > PKNur.txt

Die resultierende Textdatei hatte einen sehr langen Wert nach der Phrase "Public key is" zu kopieren.

Diesen Wert haben wir dann in einen neuen Abschnitt in der Datei wss_custom kopiert:

 

<CodeGroup class=”UnionCodeGroup” version=”1″ PermissionSetName=”FullTrust”>

<IMembershipCondition class=”StrongNameMembershipCondition” version=”1″ PublicKeyBlob=”[Paste the really long value here]”></IMembershipCondition>

</CodeGroup>

Hier ist ein Bildschirmfoto:

sv15c

In the web.config file, we added this to the <securityPolicy> settings:

<trustLevel name=”WSS_Custom” policyFile=”C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_custom.config” />

Als Nächstes haben wir die Vertrauensstufe in der Datei web.config auf WSS_Custom geändert.

<trust level=”WSS_Custom” originUrl=”” />