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é

Suite à l’annonce de l’arrêt du produit Forefront TMG (http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx), faisons un point sur les solutions Microsoft de proxy / firewall / accès distant. Les éléments importants à retenir sont :

• Forefront TMG sera supporté par Microsoft jusqu’en 2020 (en support étendu, cf. http://support.microsoft.com/lifecycle/?c2=12300)
• La roadmap de Forefront UAG reste inchangée – c’est depuis 4 ans et continue à être la passerelle de Microsoft. Le produit va donc notamment continuer à bénéficier de nouvelles fonctionnalités au travers de Service Packs et de futures versions ; pour la roadmap officielle, encore un peu de patience !
• DirectAccess peut désormais être déployé (sans Forefront UAG) via le rôle « Remote Access » de Windows Server 2012

Quelle solution pour quel usage ?

Si vous utilisez Forefront TMG en tant que firewall, VPN site-à-site ou forward proxy web (filtrage d’URL, inspection), vous continuerez à bénéficier du support de Forefront TMG comme indiqué précédemment.

Pour un accès au réseau interne pour des employés en mobilité, la solution autrefois basée sur le couple Forefront UAG / DirectAccess est désormais à déployer de préférence avec Windows Server 2012. En effet, le nouveau rôle Remote Access dans Windows Server 2012 permet de mettre en œuvre DirectAccess ou un VPN, plus simplement et avec son lot d’améliorations.

Pour les autres besoins de mobilité, dans lesquels on souhaite publier des applications web à diverses populations, Forefront UAG reste la solution recommandée par Microsoft, en raison de ses services de sécurité applicative, de single sign on et surtout car nos équipes valident nos solutions exclusivement sur cette plateforme. Si vous utilisiez TMG pour publier des applications web de l’entreprise, vous pouvez envisager une migration vers Forefront UAG, plus adapté pour sur ce type de scénario et toujours maintenu.

Focus sur les bénéfices de Forefront UAG

Forefont UAG vous permet principalement de mettre à disposition de vos employés, partenaires et fournisseurs un portail d’accès aux applications internes que vous souhaitez partager. Les points forts de la solution sont :

• Une publication simple et rapide via des assistants de vos applications web, avec une sécurité intégrée (couche applicative). En effet les applications Web sont depuis longtemps très complexes à publier (HTMLl, Javascript, Ajax), et nécessitent donc des moteurs spécifiques de publication (et non un simple reverse proxy) et de sécurité applicative (firewall applicatif, conformité, …).
• Une intégration complète et unique sur le marché avec les solutions Microsoft telles Exchange et Sharepoint, grâce à la collaboration inter-équipes produits chez Microsoft
• Son extensibilité (SSO aux applications, modification du contenu à la volée, définition de politiques de contrôle d’accès en fonction des clients, personnalisation des interfaces…). C’est particulièrement utile pour des scénarios de BYOD (Bring Your Own Device).
• Sa simplicité de gestion : une console d’administration pour la configuration et une interface web pour le monitoring
• Son interopérabilité avec les protocoles de fédération via AD FS : un prochain article décrira quelques scénarios possibles dans cette configuration d’avenir

François TACHOIRES - Consultant Sécurité.