Le module HTTP de l’extension lève également un évènement SecurityIdentityValidated une fois que les rôles poussés par le système Shibboleth ont été exploités, que l’objet ShibIdentity a été constitué avec les informations extraites sur la base de cet entête, et qu’un objet GenericPrincipal a été créé sur cette base.

C’est cet objet qui sera positionné au niveau HttpContext.Current.User pour ASP.NET. La souscription à cet évènement au niveau du fichier global.asax vous permet, par exemple, d’auditer les constitutions avec succès d’un contexte de sécurité via l’instanciation d’un objet GenericPrincipal au sein de l’application.

Par ailleurs, en fonction de votre environnement cible et des traitements à réaliser sur cette base, vous pouvez cependant souhaiter utiliser un objet principal personnalisé de façon à centraliser certains traitements.

Le code suivant précise l’ossature d’une classe personnalisée MyPrincipal.

public class MyPrincipal : GenericPrincipal, IMyPrincipal

{

…

public MyPrincipal(IPrincipal principal)

: base(principal)

{

…

}

…

}

Avec une définition appropriée de cette classe, tout ce que vous avez à faire est maintenant est d'assurer que le module HTTP utilise une instance de MyPrincipal au lieu de la valeur par défaut GenericPrincipal lorsqu'il établit identité de l'utilisateur en positionnant HttpContext.Current.User.

Le principe du traitement de l’événement SecurityIdentityValidated dans le module HTTP est l'endroit pour le faire, comme illustré ci-après.

void ShibAuthenticationModule_SecurityIdentityValidated(object sender,

SecurityIdentityValidatedEventArgs args)

{

MyPrincipal customPrincipal = new MyPrincipal((IPrincipal) args.User);

IShibIdentity ssoid =(IShibIdentity) args.User.Identity;

// TODO: provision the customPrincipal principal accordingly

args.User = customPrincipal;

}

Il convient de positionner la propriété User de l’argument SecurityIdentityValidatedEventArgs avec l’instance de l’objet MyPrincipal souhaité.

Dans la version courante, le fournisseur d’authentification n’offre pas de paramétrage particulier en dehors des éléments de configuration déjà précisé.

La configuration du fournisseur d’appartenance se fait directement dans le provider de la partie <roleManager>.

<roleManager defaultProvider="ShibRoleProvider" enabled="true" cacheRolesInCookie="true">

<providers>

<add name="ShibRoleProvider"

type="Upmc.Shibboleth.ShibRoleProvider, Shib4MOSS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=F20DC168DFD54966"

applicationName="/"

roleHttpHeaders="primary-affiliation|unscoped-affiliation|supannRoleGenerique"

roleValues="member|student|affiliate|etudiant"/>

</providers>

</roleManager>

Dans la version courante, les propriéts suivantes peuvent être configuréescomme suit :

Ex.: primary-affiliation|unscoped-affiliation|supannRoleGenerique

Ex.: member|student|affiliate|etudiant

Ces éléments de configuration peuvent être le cas échéant chiffrés.

Nous décrivons ci-après la procédure de chiffrement manuel. ASP.NET prend en charge de façon automatique le déchiffrement.

Pour un chiffrement avec une clé RSA, ceci suppose de réaliser les opérations suivantes depuis un invité de commandes :

Positionnez-vous dansle répertoire de la version du Framework .NET à l’aide de la commande suivante:

cd \WINDOWS\Microsoft.Net\Framework\v2.0.*

Exécutez la commande aspnet_regiis.exe avec les options suivantes :

L’option -pa suivi du nom du conteneur de clé RSA pour le fournisseur par défaut RsaProtectedConfigurationProvider;

L’identité du pool d’application pour l’application ASP.NET relative à la zone SharePoint considérée. Il s’agit par défaut du compte NETWORK SERVICE. Par exemple, la commande suivante confère au compte NETWORK SERVICE un accès au conteneur de clé RSA de niveau machine NetFrameworkConfigurationKey.