Récemment, un client souhaitait permettre à ses utilisateurs de sélectionner des adresses SMTP alternatives spécifiques à supprimer via le portail FIM.
Nous avons envisagé d'étendre le schéma afin d'ajouter plusieurs attributs à chaque utilisateur pour contenir les adresses smtp alternatives et un drapeau correspondant pour indiquer une demande de suppression, mais comme chaque utilisateur peut avoir des dizaines d'adresses alternatives, la solution ne serait pas bien adaptée.
Lorsque vous utilisez les contrôles de case à cocher ou de bouton radio dans le FIM, il existe deux options pour remplir les valeurs disponibles dans ces listes. La première consiste à le coder dans le RCDC, ce qui fonctionne s'il existe un ensemble de valeurs qui s'appliquent globalement à tous les utilisateurs. Dans le cas des adresses électroniques, cela ne fonctionnerait pas. L'autre option consiste à créer un nouveau type de ressource pour permettre la gestion de ces valeurs. L'ajout d'un type de ressource "smtp secondaire" aurait considérablement augmenté la taille du métavers et les temps de synchronisation. C'était comme utiliser un marteau de forgeron pour enfoncer un clou de parquet mal fixé.
Nous avons donc dépoussiéré nos compétences de développeur SharePoint et créé une fonction personnalisée.
Le résultat est une page qui semble faire partie du portail FIM, mais qui utilise en réalité le contrôle de case à cocher aspx et des valeurs stockées dans une chaîne indexée. Nous avons simplement ajouté un lien vers la page sur le RCDC de l'utilisateur :
La collection d'adresses proxy est écrite depuis AD vers le service FIM via FIM Sync dans un attribut multivalué de type chaîne indexée. La fonction personnalisée lit ces valeurs et présente à l'utilisateur une liste d'options à cocher. Le fait de désélectionner un élément et de le soumettre met à jour l'attribut de la collection d'adresses proxy de manière à ce qu'il puisse être renvoyé à AD.
(Il convient de noter que cette fonctionnalité se trouve sur une page SharePoint et ne fait pas partie du RCDC).
Nous avons utilisé la page maîtresse d'ILM2 pour donner à la liste de cases à cocher l'aspect et la convivialité du portail FIM. Ensuite, nous avons hébergé une page que la fonctionnalité a déployée sur une bibliothèque du site SharePoint du portail.
La partie la plus délicate a été d'accorder au code l'accès au modèle d'objet SharePoint afin de conserver la session existante de l'utilisateur et de ne pas avoir à demander une nouvelle authentification. Une façon rapide et pratique de le faire est de définir le niveau de confiance du site sur "full", mais c'est un risque pour la sécurité. Cela permettrait d'accorder une confiance totale à tous les assemblages sur le serveur. Une autre approche rapide consiste à installer l'assembly dans le GAC. Cela lui accorde une confiance totale dans toutes les applications du serveur, ce qui représente évidemment un éventail de permissions plus large que ce dont il a besoin.
La solution a consisté à personnaliser la sécurité d'accès au code à l'aide d'un fichier de politique personnalisé. Ce fichier nous permet d'accorder un niveau de confiance spécifique à notre assemblage uniquement. La permission est accordée au code et non à l'utilisateur qui exécute le code.
Tout d'abord, nous avons copié le fichier wss_minimal.config dans le fichier CONFIG de la ruche 14 et l'avons nommé wss_custom.config.
Il a ensuite été modifié comme décrit ci-dessous :
En utilisant l'invite de Visual Studio command , nous avons extrait le Public Key Blob dans un fichier texte. Après avoir navigué jusqu'au répertoire contenant le fichier .snk de notre assemblage, nous avons exécuté les commandes suivantes :
Sn -p MonNomDeFichier.snk PKOnly.snk
Sn -tp PKOnly.snk > PKOnly.txt
Le fichier texte résultant comportait une très longue valeur après la phrase "Public key is" à copier.
Nous avons ensuite copié cette valeur dans une nouvelle section du fichier wss_custom :
<CodeGroup class=”UnionCodeGroup” version=”1″ PermissionSetName=”FullTrust”>
<IMembershipCondition class=”StrongNameMembershipCondition” version=”1″ PublicKeyBlob=”[Paste the really long value here]”></IMembershipCondition>
</CodeGroup>
Voici une capture d'écran :
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” />
Ensuite, nous avons modifié le niveau de confiance dans le fichier web.config en WSS_Custom.
<trust level=”WSS_Custom” originUrl=”” />
