Proxy Federation dans OAM et IdP

Cet article explique le concept de proxy de fédération et explique comment configurer facilement IdP pour qu'il devienne un processeur de service et qu'il délègue l'authentification à un autre IdP distant au lieu d'authentifier l'utilisateur localement.

Le proxy Federation est généralement utilisé lorsqu'un hub de fédération agit comme suit :

Cette approche a l'avantage de :

Modèle de confiance directe

Dans ce modèle, les différents serveurs Federation se font confiance directement et aucune entité intermédiaire ne joue le rôle de proxy.

Ce modèle a l'avantage de réduire la complexité des flux de fédération, car seuls deux serveurs sont impliqués dans l'opération SSO, mais il a parfois l'inconvénient de créer un énorme surcroît de gestion que les partenaires pourraient ne pas accepter.

Prenons l'exemple d'une entreprise internationale appelée ACME Corp, qui a des bureaux dans le monde entier. La structure de l'entreprise est composée de trois grandes organisations représentant une région différente du monde, et chaque organisation est responsable de son domaine de sécurité :

Chaque organisation dispose de son propre domaine de sécurité, ce qui signifie :

Maintenant, disons qu'ACME Corp veut avoir un accord de fédération en place avec certains fournisseurs de services, dont certains sont des fournisseurs, d'autres des services achetés par ACME Corp, tels qu'un service d'appel de conférence, ainsi qu'un service Webex.

Pour établir une fédération entre les différentes organisations ACME Corp et les SP, le serveur Federation de chaque organisation doit établir une relation de confiance avec chaque SP distant :

Ce diagramme représente tous les accords qui devraient être mis en place :

Description de l'image Direct_Trust_Model.jpg

Cette approche est généralement évitée, car elle publie au partenaire la complexité interne de l'infrastructure d'ACME Corp.

Les protocoles SSO et SAML de fédération ont été définis pour permettre à deux domaines de sécurité distincts d'effectuer un SSO interdomaine d'une manière qu'un partenaire n'aurait pas besoin de connaître sur l'implémentation et le déploiement de la sécurité de l'autre partenaire. Dans ce cas, il devient évident que cette promesse est rompue et que la complexité des choix de sécurité d'ACME Corp a un impact sur les partenaires SP.

Modèle de confiance par courtage

Dans ce modèle, il existe le concept de proxy de fédération dans lequel certaines entités doivent être utilisées pour agir en tant que proxies/SP afin d'effectuer des opérations SSO de fédération pour le compte d'autres SP.

Si nous reprenons notre exemple d'ACME Corp, l'approche correcte pour implémenter Federation SSO avec d'autres partenaires SP est via un modèle de sécurisation par courtage ou un proxy de fédération, où :

Cette approche est plus conforme à la philosophie Federation/SAML, où les partenaires externes ignorent l'infrastructure de sécurité et les composants d'ACME Corp, et interagissent uniquement avec un seul IdP.

Cette solution résout également la surcharge de gestion élevée lorsque le nombre d'accords était particulièrement élevé et que toute mise à jour de l'accord était un processus long. Avec cette approche :

Le schéma suivant représente les accords de fédération requis dans un modèle de sécurisation par broker (ou proxy de fédération) :

Description de l'image Brokered_Trust_Model.jpg

Proxy de fédération dans OAM

L'objectif d'un proxy Federation est de transformer l'élément IdP en SP afin que, lors de la réception d'une demande SSO d'un premier SP distant, au lieu d'interroger localement l'utilisateur, l'élément IdP devienne un SP et déclenche une nouvelle opération SSO de fédération avec un second élément IdP distant.

Une fois la deuxième opération SSO de fédération terminée, le proxy IdP a identifié l'utilisateur et peut créer une réponse SSO pour le SP d'origine.

OAM prend en charge Federation Proxy Now pour tous les protocoles :

Un SP peut donc effectuer une connexion unique de fédération avec IdP via SAML 1.1, et IdP devient un SP et une connexion unique de fédération avec une seconde connexion unique distante IdP via SAML 2.0. Le SP d'origine n'a pas besoin de connaître le protocole utilisé entre OAM/SP et le second IdP, ni même qu'une seconde opération SSO de fédération a eu lieu.

Dans un proxy de fédération maintenant, IdP peut être configuré pour "transférer" la méthode d'authentification de fédération indiquée dans le deuxième SSO de fédération vers le SP d'origine.

Configurer OAM pour le proxy Federation

Comme indiqué précédemment, IdP utilise OAM pour l'authentification de l'utilisateur : à chaque fois qu'une opération SSO de fédération a lieu, IdP appelle OAM en indiquant un modèle d'authentification, afin de s'assurer que l'utilisateur est authentifié correctement et de le mettre en question si nécessaire.

Comme vous le savez, OAM définit des modèles spécifiques qui sont liés à OAM/SP : si un utilisateur non authentifié demande l'accès à une ressource protégée par un FederationScheme (ou un modèle utilisant un module d'authentification semblable à FederationPlugin), OAM appelle OAM/SP qui déclenche une opération SSO de fédération avec un IdP distant.

Par conséquent, pour que IdP fasse un proxy de fédération maintenant, au lieu que IdP appelle OAM avec un modèle d'authentification local, IdP doit être appelé avec FederationScheme. A partir de là :

Commande WLST

Pour configurer IdP afin qu'il utilise le SSO de fédération pour authentifier un utilisateur au lieu d'un mécanisme d'authentification locale, exécutez l'une des commandes suivantes :

Reportez-vous à l'article sur l'authentification dans IdP pour plus d'informations sur la configuration d'OAM pour l'authentification. Dans cet exemple, configurez IdP de manière globale pour utiliser Federation SSO comme mécanisme d'authentification par défaut :

  1. Entrez dans l'environnement WLST en exécutant : $IAM_ORACLE_HOME/common/bin/wlst.sh.

  2. Connectez-vous au serveur d'administration WLS : connect().

  3. Accédez au branchement d'exécution de domaine : domainRuntime().

  4. Exécutez la commande setIdPDefaultScheme() : setIdPDefaultScheme("FederationScheme").

  5. Quittez l'environnement WLST : exit().

Avec cette modification, FederationScheme est utilisé pour authentifier les utilisateurs.

D'autres schémas de fédération peuvent être utilisés pour authentifier l'utilisateur, OAM étant configuré au niveau global (tous les utilisateurs de tous les SP sont authentifiés à l'aide de ce schéma de fédération) ou au niveau du partenaire de fournisseur de services (tous les utilisateurs qui exécutent l'authentification SSO de fédération avec ce SP SPécifique sont authentifiés à l'aide de ce schéma de fédération). N'oubliez pas que vous pouvez créer un schéma de fédération pour un élément IdP spécifique, via la commande OAM WLST createAuthnSchemeAndModule ou via la section Modifier le partenaire IdP de la console d'administration OAM.

Détermination du deuxième élément IdP à utiliser

Lorsqu'un modèle de fédération est utilisé pour l'authentification dans OAM, OAM/SP doit déterminer la valeur IdP à utiliser pour l'opération SSO de fédération :

Pour définir un partenaire IdP en tant que partenaire SSO par défaut IdP :

Méthodes d'authentification de fédération par proxy

Comme expliqué dans un article précédent, lorsque IdP construit une assertion, il met en correspondance le modèle OAM local utilisé pour authentifier l'utilisateur avec une méthode d'authentification de fédération.

Dans le cas d'un proxy SSO de fédération maintenant, cela signifie qu'un élément FederationScheme est mis en correspondance avec une méthode d'authentification de fédération. Par exemple, si le schéma doit être mis en correspondance avec urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport pour SAML 2.0, l'administrateur utilise une commande semblable à la suivante :

Dans certains cas, il peut être préférable de transférer la méthode d'authentification de fédération reçue de la seconde IdP au lieu de mettre en correspondance localement le modèle de fédération avec une méthode d'authentification de fédération.

Pour configurer IdP afin de transmettre les méthodes d'authentification de fédération dans un proxy SSO de fédération.

A présent, utilisez la commande useProxiedFedAuthnMethod() :

  1. Entrez dans l'environnement WLST en exécutant : $IAM_ORACLE_HOME/common/bin/wlst.sh.

  2. Connectez-vous au serveur d'administration WLS : connect().

  3. Accédez au branchement d'exécution de domaine : domainRuntime().

  4. Exécutez la commande useProxiedFedAuthnMethod() : useProxiedFedAuthnMethod(enabled="true/false",authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME").

  5. Quittez l'environnement WLST : exit().

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuite sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation du produit, visitez le site Oracle Help Center.