On peut une imaginer une application disponible sur Azure, ou bien accéder aux services de BPOS/Office 365.

Le « Sésame » va me permettre de me connecter à tous ces services, sans avoir à gérer X identités (une pour mon SI, une sur celui de mon partenaire, une pour Azure et BPOS…) et donc accéder à tous ces services sans me authentifier X fois.

Dans cette vision d’architecture, le choix est laissé à l’architecte quant à la localisation de son application (réseau privé, cloud…). Pour les applications internes, il va falloir non seulement les publier et en sécuriser l’accès (attaques, tentatives de vol d’information), mais aussi être en mesure de rendre compatibles des applications non développées sur la fédération d’identité avec notre nouvelle infrastructure. C’est là qu’entre en jeu UAG, à la fois pour sécuriser toutes les applications du réseau interne (Celles ADFS et celles qui ne le sont pas), mais aussi fournir les briques de WebSSO, permettant de transformer ce jeton SAML utilisé en authentification de bordure en « une identité applicative ».

Au sein de cet article je vais vous montrer comment tirer bénéfice de la fédération avec UAG. Vous comprendrez alors pourquoi les équipes de développement ont réalisé de gros investissements sur le scénario ADFS avec la version SP1 de Forefront Unified Access Gateway.

Le scénario : ADFS et UAG · iTPro.fr