Nombre d’organisations et d’universités utilisent le composant open-source JASIG Central Authentication Service (CAS) pour l’authentification SSO à leurs applications Web. Le composant CAS JASIG ne supporte pas nativement les différents profils SAML 2.0 ou le protocole WS-Federation ; par ailleurs AD FS 2.0 ne supporte pas nativement l’ajout d’autres référentiels d’authentification autrement que par l’ajout de Claims Providers.

La problématique est donc posée pour assurer l’interopérabilité entre les deux mondes.

L’une des pistes envisageables est d’associer :

  • Microsoft Active Directory Federation Services 2.0 qui permet de faire interopérer les protocoles majeurs de fédération, à savoir SAML 2.0 et WS-Federation.
  • Windows Identity Foundation qui nous permettra de construire une passerelle supplémentaire pour d’un côté consommer les tickets CAS et de l’autre fournir des jetons d’authentification compréhensibles par AD FS.

 

 

JASIG Central Authentication Service (CAS)

CAS est un protocole de Single Sign-On pour le web. Non seulement cela permet à l’utilisateur de s’authentifier une seule fois dans une session web, mais aussi les applications web n’ont plus à gérer un mot de passe pour l’utilisateur.  Cette solution est assez largement déployée dans les universités. Ce composant est téléchargeable sur le site du projet : http://www.jasig.org/cas.

 

Windows Identity Foundation

Microsoft Windows Identity Foundation est un framework fournissant des APIs pour développer des applications de fédération ou « claims-aware », c’est-à-dire capables de consommer des revendications contenues dans un jeton envoyé par un fournisseur de confiance. Il est téléchargeable ici : http://www.microsoft.com/en-us/download/details.aspx?id=4451. Il sera inclus dans Microsoft .NET Framework 4.5.

 

AD FS 2.0

Active Directory Federation Services 2.0 permet aux organisations d’homogénéiser l’expérience des utilisateurs, qu’ils accèdent à des applications hébergées sur site ou dans le nuage. De plus la collaboration hors des frontières est facilitée grâce à l’interopérabilité avec SAML et WS-Federation.
Notez que l’update rollup 2 a été publié le 14/05/2012, avec la correction de 4 bugs et l’ajout d’une fonctionnalité, à savoir le support du paramètre RelayState pour SAML (voir Supporting Identity Provider Initiated RelayState). Il est disponible ici : http://support.microsoft.com/kb/2681584.

 

Comment effectuer l’intégration?

Créer un Custom STS à partir du template fourni avec WIF

Créer un nouveau Web Site à partir du template ASP.NET Security Token Service Web Site.
Pour vos tests vous pouvez également utiliser le template « Claims-Aware ASP.NET Web Site » pour avoir une application consommatrice de jetons, ou bien un des exemples fournis avec un WIF.

 

Configurer l’authentification  avec CAS

Redirection de l’utilisateur

Quand l’utilisateur arrive sur la page login.aspx du Custom STS, on le redirige sur l’URL d’authentification CAS https://cas.server/cas/serviceValidate?service=<URL du custom STS>, à l’aide du code suivant :

string signInUrl = System.Configuration.ConfigurationManager.AppSettings.Get("SignInURL").ToString();
signInUrl = signInUrl + "?service=" + returnUrl;
Response.Redirect(signInUrl, false);

 SignInURL est de la forme suivante :

<add key="SignInURL" value="https://cas.server/cas/login" />

 

Valdiation du ticket CAS
L’utilisateur est redirigé par CAS avec un ticket. Il s’agit ensuite de faire valider auprès de CAS par le Custom STS si ce ticket est bien valide. Pour cela il suffit de soumettre ce ticket à CAS dans ure requête POST à l’URL https://cas.server/cas/serviceValidate?service=<URL du custom STS>&ticket=<numéro du ticket>. La réponse est contenue dans un XML de cette forme :
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas"><cas:authenticationSuccess><cas:user>user</cas:user></cas:authenticationSuccess></cas:serviceResponse>

 

Génération d’un jeton
Si le ticket est bien valide, on génère un jeton avec les claims souhaitées. Ici nous avons seulement l’identifiant de l’utilisateur que l’on peut placer dans une claim de type NameId par exemple. Il est recommandé également de générer une claim de type Authentication pour déclarer que l’utilisateur a bien été authentifié par CAS. Le jeton généré contient alors les claims suivantes :

 

Publication des metadata
Régénérer des metadata correspondant à votre Custom STS. Vous remarquerez qu’à la création, un fichier xml de metadata est automatiquement généré. Le plus simple pour l’actualiser, est d’utiliser l’utilitaire suivant : http://static.thinktecture.com/christianweyer/FederationMetadataGenerator_1.0.zip
Attention, il est nécessaire de bien faire correspondre la clé du web.config <add key="IssuerName" value="https://sts.contoso.com/STSWebSite"/> avec l’ID publié dans les metadata.

 

Configurer le custom STS dans AD FS 2.0

Custom STS comme Claims Provider Trust
Il suffit d’ajouter un nouveau Claims Provider Trust en suivant l’assistant, et en fournissant l’URL des metadata du Custom STS et des règles doivent être ajoutées pour indiquer quelles claims sont reçues du Custom STS. Des règles de transformation peuvent être ajoutées à ce niveau.

  

Application comme Relying Party
L’application doit être ajoutée en tant que Relying Party et des règles doivent être ajoutées pour indiquer quelles claims sont transmises à l’application (en fonction de ce dont elle a besoin). Des règles de transformation peuvent être ajoutées à ce niveau également.

 

Flux en jeu

 Le diagramme suivant récapitule les flux en jeu. Notez que la première fois, l’utilisateur devra choisir son fournisseur d’identité dans une liste déroulante, car AD FS fonctionne nativement avec Active Directory (Claims Provider par défaut).

 


 

Conclusion

Cet article montre comment utiliser l’authentification CAS dans un contexte de fédération AD FS, grâce à la mise en place d’un composant « Custom STS ». Il est sans doute également possible de modifier certaines pages ASP d’AD FS, la solution de l’article présentant l’avantage de conserver la configuration de base AD FS. Il est par ailleurs envisageable de réutiliser cette architecture avec d’autres sources d’authentification, comme un annuaire LDAP par exemple.

Nicolas Mangin, Félix Ndouga, François Tachoires