Première amélioration, il sera possible d’authentifier l’utilisateur sur la base de son jeton SAML. Dans un scénario de B2B par exemple, ceci veut dire que l’utilisateur s’authentifiera sur sa propre infrastructure (Microsoft ou non, mais supportant la fédération d’identité), recevra donc en retour un jeton (dans lequel nous aurons à la fois son identité, mais également des éléments le concernant … rôle, âge, … appelés Claims ou revendications en français). Ensuite, lorsqu’il va se connecter à UAG, il va présenter ce jeton pour l’authentification de bordure. UAG va alors vérifier si il « trust » le tiers qui a généré ce jeton, et si c’est le cas, sur la base de l’identité et des claims dans ce jeton, va donner accès et en déduire des permissions ou des rôles. Ensuite, UAG va continuer à faire son rôle de passerelle de sécurité.
Seconde amélioration, l’application « Portail » d’UAG est maintenant « Claims Aware », c’est-à-dire capable de d’exploiter ce jeton et ses Claims, en particulier pour les autorisations. Par exemple, s’il existe un claim du type « rôle=acheteur », alors on peut accéder au système de commande. Ce qui est intéressant ici c’est que si cette application n’est pas elle-même « Claims Aware », UAG remplira son rôle de passerelle de Web SSO, en transformant cette identité de bordure (jeton SAM) dans le format demandé par l’application (un formulaire Web, un ticket Kerberos (KCD) ou un jeton NTLM).
Enfin, la configuration réalisée au sein d’UAG est à 100% basée sur un assistant.
Sécuriser sa téléphonie IP n’est plus une option. Avec la généralisation de la téléphonie cloud et des infrastructures VoIP, la voix circule désormais sur les mêmes réseaux que les données…
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et…
