Nouveautés avec le SP2 (août 2012)

Quelles sont les nouveautés apportées par le SP2 ? http://technet.microsoft.com/en-us/library/jj590875.aspx.

Outre un support amélioré de Sharepoint 2010 et de systèmes d’exploitation d’appareils mobiles (Windows Phone 7.5, iOS 5.X pour iPone et iPad, Android 4.X pour smartphones et tablettes), le SP2 apporte principalement des fonctionnalités autour de la publication d’applications « claims-aware » avec ADFS 2.0. Il est désormais possible :

• D’utiliser un même serveur ADFS avec plusieurs trunks

• De publier le serveur ADFS avec un ADFS proxy plutôt qu’UAG, et ainsi de supporter (entre autres) les scénarios de fédération avec Office365

UAG et ADFS : le pouvoir des claims avec le contrôle d’accès UAG

Partons du constat suivant : si la gestion du cycle de vie des identités « employés internes » et de leurs droits d’accès est un challenge pour les entreprises, c’est presque mission impossible pour des identités externes. Or aujourd’hui, les scénarios suivants sont monnaie courante :

1.      Donner/Contrôler un accès à des utilisateurs externes (partenaires, fournisseurs) à des sites et services hébergés sur un intranet de l’entreprise

2.      Faciliter l’accès des employés depuis l’intranet ou en mobilité à des sites et services hébergés en externe (clouds publics ou privés)

3.      Proposer un accès contrôlé à tout type d’utilisateur (interne ou externe) à certains sites web hébergés sur un intranet. Dans un contexte BYOD (Bring Your Own Device), les composants clients peuvent être utilisés pour contrôler l’accès en fonction de caractéristiques du device (non disponible aujourd’hui pour les OS mobiles).

Déployer Forefront UAG 2010 SP2 avec ADFS 2.0 permet de proposer une solution technique à ces besoins, et nous allons voir comment. L’article suivant fait référence concernant l’interopérabilité UAG et ADFS (http://blogs.technet.com/b/edgeaccessblog/archive/2010/04/14/forefront-uag-and-adfs-better-together.aspx), cependant avec le SP2 d’UAG il est désormais possible d’utiliser un ADFS Proxy dans l’architecture.

Accès à des applications internes par des utilisateurs externes

Forefront UAG fournit les fonctionnalités portail, reverse proxy et contrôle d’accès (authorization and endpoint policies). ADFS est quant à lui la brique de fédération : consommation, génération et transformation de jetons contenant des claims, utiles à l’authentification et l’autorisation des utilisateurs.

Ci-dessous un exemple de scénario :

Notez qu’il est possible de publier le serveur au travers d’UAG si le déploiement d’un serveur ADFS Proxy n’est pas souhaité.

Enfin, la relation de confiance avec le partenaire peut être établie avec des passerelles de fédération tierces, autres qu’AD FS. Les guides How-To sur Technet détaillent notamment l’interopérabilité avec les solutions RSA SecurID, IBM Tivoli Federated Identity Manager, Ping Identity, CA Federation Server, Oracle Identity Federation, Shibboleth 2 : http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(v=WS.10).aspx.

Accès à des applications cloud pour des employés

Grâce à la publication d’ADFS via ADFS Proxy, il devient possible d’utiliser cette architecture simplement pour donner accès aux internes à des applications cloud. UAG peut être alors utilisé par exemple pour rediriger les utilisateurs sur des applications internes (par exemple Sharepoint Online qui ferait référence à des liens sur une application publiée par UAG). L’employé bénéficie ainsi d’un SSO entre les applications internes et cloud.

Accès à des applications internes dans des scénarios BYOD

Lorsque l’on donne accès à une application à travers un portail UAG, il est possible de régler différents paramètres d’authentification et d’autorisation. En plus du résultat dépendant du jeton de sécurité fourni (claim d’authentification et claims d’attributs), il est possible de configurer dans UAG des règles spécifiques au client utilisé. L’intérêt de la solution est l’application d’une politique de sécurité d’entreprise ; les devices considérés comme non sûrs et où l’information pourrait être détournée sont interdits d’accès.

Les informations sur le device peuvent être transmises via deux technologies :

• UAG EndPoint Components : cela nécessite l’installation d’un composant client UAG sur le device, et la configuration de politiques d’accès dans UAG. Cette solution est la plus souple, et fonctionne sur divers systèmes (activeX pour Windows/IE, applet Java pour Linux-Mac/Firefox-Safari). Elle est recommandée dans la plupart des scénarios.

• NAP (Network Access Protection) : cela nécessite l’ajout d’un serveur NPS, la configuration de politique de santé, et la présence d’un client NAP activé et configuré sur l’OS. Cette solution est plutôt à privilégier pour des déploiements DirectAccess ou VPN/SSL avec des PCs Windows.

Forefront UAG sait donc s’adapter en fonction du device. La matrice de compatibilité complète est disponible ici : http://technet.microsoft.com/en-us/library/dd920232.aspx

Dans l’exemple ci-après, on aurait :

• Authentification au trunk portail UAG déléguée à ADFS

• Accès au portail autorisé uniquement si

• Les conditions de claims utilisateur sont respectées

• Les composants client UAG Endpoint sont installés

• Les conditions définies dans les règles d’accès EndPoint sont respectées (par exemple Windows, Linux ou Mac avec antivirus installé, refusé pour les mobiles et autres)

• Accès à l’application web uniquement si

• Les conditions de claims utilisateur spécifiques à l’application sont respectées

• Les conditions définies dans les règles d’accès EndPoint spécifiques à l’application sont respectées

• Accès à l’URL web finale de l’application si le type de requête est autorisé

Bien entendu, la fédération n’est pas indispensable ici et il est tout à fait possible d’adapter le scénario avec d’autres types d’authentification au niveau du portail UAG. La liste est disponible ici : http://technet.microsoft.com/en-us/library/dd861486.aspx.

Conclusion

Ces scénarios rappellent les intérêts principaux de la solution couplée ADFS / UAG, à savoir :

• Pas de comptes à gérer pour les partenaires pour l’authentification et l’autorisation aux applications publiées

• Du SSO aux applications et une expérience unifiée pour l’utilisateur

• Une interopérabilité avec les partenaires grâce aux standards de fédération (WS-Federation et SAML 2.0)

• Un contrôle d’accès en fonction de caractéristiques du device utilisé. Avec l’arrivée prochaine des tablettes Windows 8, ces scénarios ont de l’avenir

Enfin il faut noter qu’il est possible :

• De publier conjointement dans un même portail des applications non claims-aware, mais dans ce cas, un compte d’accès à l’application est nécessaire et on perd le SSO.

• De faire du SSO à partir de l’authentification AD FS avec des applications supportant KCD (Kerberos Constrained Delegation), mais dans ce cas des comptes shadow sont nécessaires.

Il est alors presque indispensable de mettre en œuvre une solution supplémentaire de provisioning comme Forefront Identity Manager pour la gestion de ces comptes supplémentaires, et/ou d’AD RMS pour la protection des données.

François TACHOIRES - Consultant Sécurité