> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/securite/enterprise-security/saml2.md). # SAML2 Configurez l'authentification SAML2 dans PowerShell Universal avec des fournisseurs d'identité comme Entra ID, Okta et Shibboleth, y compris les métadonnées et le mappage des revendications. {% hint style="info" %} SAML2 nécessite une [licence](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal peut être configuré pour s'intégrer à un fournisseur d'identité SAML2. Cette documentation fournit les détails de la configuration de PSU avec un tel système. ## Chargement automatique des métadonnées PowerShell Universal fournit un mécanisme permettant de charger le document de métadonnées directement depuis le fournisseur d'identité SAML2 plutôt que de fournir manuellement les options de configuration. Cela recueillera autant d'informations que possible. L'Entity ID devra tout de même être fourni. Le chemin de rappel sera affiché en haut du modal de la propriété. ## Fournir les valeurs manuellement ### Paramètres du fournisseur d'identité Vous devrez configurer votre fournisseur d'identité pour l'application PowerShell Universal. Vous devrez définir un entity ID acceptable et mapper les attributs. PowerShell Universal exige que l'attribut name soit mappé. Le nom de l'attribut doit être le suivant. {% code collapsedlinecount="10" %} ``` http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name ``` {% endcode %} Vous devriez mapper ceci à l'identité utilisateur que vous souhaitez utiliser dans PowerShell Universal. Des attributs supplémentaires peuvent être mappés et seront disponibles lors de l'[évaluation des rôles](/powershell-universal/fr/securite/security.md#authorization). Vous trouverez ci-dessous un exemple de configuration de Shibboleth. ### Paramètres de l'Entity ID {% hint style="info" %} [HTTPS ](/powershell-universal/fr/config/hosting.md#configuring-https)est requis pour l'authentification SAML2. {% endhint %} Il existe plusieurs paramètres de base que vous pouvez configurer dans la console d'administration de PowerShell Universal. Pour ajouter la prise en charge de SAML2, cliquez sur Secure > Authentication. Dans le coin supérieur droit, vous pouvez sélectionner SAML2 dans la liste déroulante. Une fois l'intégration SAML2 ajoutée, vous pouvez configurer les paramètres de base pour communiquer avec votre fournisseur d'identité. Vous devrez au minimum configurer l'Entity ID et l'Identity Provider Entity ID. Habituellement, ces entity ID sont des URL configurées dans votre fournisseur d'identité. Le certificat de service est utilisé pour signer les requêtes. Il n'est pas requis. Il peut s'agir d'un chemin local au service PSU ou du nom distinctif d'un certificat installé dans le magasin de certificats Personnel de l'ordinateur. ### Paramètres supplémentaires En plus des paramètres disponibles dans la console d'administration, vous pouvez également définir les éléments suivants dans le fichier de configuration `authentication.ps1`. #### ServiceCertificatePassword Si vous utilisez un chemin de fichier pour votre certificat et que celui-ci nécessite un mot de passe, vous pouvez le spécifier au moyen du paramètre `-ServiceCertificatePassword` de `Set-PSUAuthenticationMethod`. La valeur de ce paramètre est un `SecureString`. Vous pouvez tirer parti du module SecretManagement pour charger les secrets. {% code collapsedlinecount="10" %} ```powershell Set-PSUAuthenticationMethod ` -Type "Saml2" ` -EntityId "http://psu.ironman.local/sp" ` -IdentityProviderEntityId 'https://ironman.local/idp' ` -MetadataAddress 'https://idp.ironman.local/idp/shibboleth' ` -CallbackPath "https://localhost:5000/" ` -ServiceCertificate cert.pfx ` -ServiceCertificatePassword (Get-Secret -Name 'certPassword') ``` {% endcode %} #### Configure Le paramètre `-Configure` est un bloc de script qui peut être utilisé pour définir des paramètres supplémentaires non exposés par `Set-PSUAuthenticationMethod`. Le bloc de script sera appelé lorsque le fournisseur est configuré et recevra un seul paramètre contenant un objet avec les options de l'authentification SAML2. L'objet est de type [Saml2Options](https://github.com/Sustainsys/Saml2/blob/v2.11.0/Sustainsys.Saml2.AspNetCore2/Saml2Options.cs). Le sous-objet de SPOptions se trouve [ici](https://github.com/Sustainsys/Saml2/blob/v2.11.0/Sustainsys.Saml2/Configuration/SPOptions.cs). {% code collapsedlinecount="10" %} ```powershell Set-PSUAuthenticationMethod ` -Type "Saml2" ` -EntityId "http://psu.ironman.local/sp" ` -IdentityProviderEntityId 'https://ironman.local/idp' ` -MetadataAddress 'https://idp.ironman.local/idp/shibboleth' ` -Configure { $options = $args[0] $options.SPOptions.DiscoveryServiceUrl = 'https://idp.ironman.local/discovery' } ``` {% endcode %} ## Exemple : Entra ID Configurez une application d'entreprise Entra ID dans Azure. Vous trouverez un [guide étape par étape ici](/powershell-universal/fr/securite/enterprise-security/openid-connect.md#configuring-azure-entra-id-azure-active-directory). Vous devrez récupérer l'ID de l'application et le document de métadonnées de fédération ainsi que le point de terminaison de connexion SAML-P. Dans votre inscription d'application, cliquez sur le bouton Endpoints. ### Étape par étape **Dans PowerShell Universal :** 1. Cliquez sur Secure > Authentication. 2. Ajoutez le fournisseur d'authentification SAML2. 3. Cliquez sur le bouton Edit Properties. Pour Entity ID, vous devrez indiquer l'ID de l'application Entra ID précédé de `spn:` Par exemple : `spn:2cf33625-e312-4659-a7bd-66ade51a0ea2` Pour Identity Provider Entity ID, vous devrez récupérer l'entity ID à partir du document de métadonnées de fédération. Ouvrez l'URL du document dans un navigateur web. Pour Metadata Address, insérez l'URL du document de métadonnées de fédération. Pour Return URL, insérez l'URL de votre serveur PowerShell Universal avec le chemin `/Saml/Acs`. {% code collapsedlinecount="10" %} ``` https://localhost/Saml2/Acs ``` {% endcode %} Pour Single Sign-On Service URL, insérez le point de terminaison de connexion SAML-P d'Azure. Une fois l'opération terminée, enregistrez les paramètres et activez le fournisseur SAML. Cliquez sur se déconnecter et naviguez vers l'URL de votre console d'administration. {% code collapsedlinecount="10" %} ``` https://localhost/admin ``` {% endcode %} Vous serez redirigé vers Azure pour la connexion, puis redirigé de nouveau vers PowerShell Universal après l'authentification. Toutes les erreurs qui surviennent seront répertoriées dans le journal de PowerShell Universal. Si vous n'arrivez pas à vous connecter, vous pouvez naviguer vers `/login` pour vous connecter avec un compte local. ### Mappage des revendications Afin de fournir les revendications de groupe à PowerShell Universal, vous devrez exposer les revendications de groupe depuis votre inscription d'application. Cliquez sur Token Configuration, puis sur Add groups claim. Après avoir cliqué sur Add groups claim, vous aurez l'option de sélectionner quels groupes sont fournis. Si vous sélectionnez All Groups, les revendications de groupes seront fournies à PowerShell Universal Si vous sélectionnez Groups assigned to the application, assurez-vous de cocher la valeur Emit groups as role claims. Ce paramètre nécessite un forfait Entra ID payant. Pour assigner un groupe à votre inscription d'application, repérez votre appli dans Enterprise Applications et cliquez sur User and Groups. Ensuite, cliquez sur Add User\Group et sélectionnez les groupes que vous souhaitez assigner à votre application. Une fois la revendication de groupes configurée dans Entra ID, vous pouvez ensuite mettre à jour les mappages de revendications de PowerShell Universal vers les groupes fournis. Pour chaque rôle que vous souhaitez assigner à un groupe Entra ID, spécifiez le Claim Type et la Claim Value pour ce rôle. Par exemple, j'ai dans mon environnement un groupe portant l'ID 446832da-d4ad-4972-b0a2-eda736129928. Le Claim Type de cet objet est . Pour assigner ceci au groupe administrateur, je ferais ce qui suit. Les utilisateurs de ce groupe feraient désormais partie du rôle Administrator dans PowerShell Universal. Si vous avez sélectionné une propriété de groupe SAML différente, la valeur peut être différente (p. ex. sAMAccountName). ### Dépassements de groupes Pour les organisations comptant de nombreux groupes, vous voudrez limiter le nombre de groupes fournis à PowerShell Universal. Cela peut atténuer les problèmes d'autorisation qui surviennent lorsque trop de groupes sont fournis, ce qui fait dépasser les limites de l'application. Dans les paramètres de l'application d'entreprise, cliquez sur Single sign-on, puis sur le bouton Edit sous Attributes & Claims. Cliquez sur la revendication de groupes pour voir les options. Les options avancées vous permettront de filtrer les groupes fournis au serveur PowerShell Universal. Vous pouvez aussi configurer les revendications de groupes au moyen de la configuration des jetons dans l'inscription d'application de l'application d'entreprise. ## Exemple : Okta Cet exemple montre comment configurer l'authentification SAML2 d'Okta pour l'utiliser avec PowerShell Universal. Dans Okta, vous devrez configurer votre application de manière semblable à ce qui suit. HTTPS est requis par SAML2, et vous devrez inclure l'URL de votre instance PSU dans Single Sign On URL, suivie de `/Saml2/Acs`. Le chemin respecte la casse. L'Audience Restriction doit être l'URL de votre serveur PowerShell Universal. Pour que vos utilisateurs puissent accéder à PowerShell Universal, vous devrez vous assurer qu'ils ont été assignés à l'application Okta. Dans l'onglet Sign On de votre application, cliquez sur le bouton View SAML setup instructions. Vous devrez récupérer les deux URL et télécharger le certificat pour configurer PowerShell Universal. Consultez la prochaine étape pour savoir comment utiliser ces URL dans le fichier `authentication.ps1`. ### authentication.ps1 Le fichier authentication.ps1 est utilisé pour configurer PowerShell Universal. {% code collapsedlinecount="10" %} ```powershell Set-PSUAuthenticationMethod -Type "Saml2" ` -EntityId "https://localhost:5001" ` -IdentityProviderEntityId "http://www.okta.com/exk5dvbyzgASPiOFp5d7" ` -CallbackPath "https://localhost:5001" ` -SigningKey "C:\Users\adamr\Downloads\okta.cert" ` -SingleSignOnServiceUrl "https://dev-36706648.okta.com/app/dev-36706648_psusaml_1/exk5dvbyzgASPiOFp5d7/sso/saml" ``` {% endcode %} | Paramètre | Description | Type | | ------------------------ | --------------------------------------------------------------------------------------------------------- | ------ | | EntityId | Cette valeur doit correspondre à ce que vous avez indiqué dans Audience Restriction dans Okta. | string | | IdentityProviderEntityId | Il s'agit de la valeur présentée dans la page View SAML setup instructions. | string | | CallbackPath | Il s'agit du chemin vers lequel l'utilisateur sera redirigé si aucun chemin de redirection n'a été fourni | string | | SigningKey | Il s'agit du fichier de certificat qui a été téléchargé dans la page View SAML setup instructions. | string | | SingleSignOnServiceUrl | Il s'agit de l'URL de connexion fournie dans la page View SAML setup instructions. | string | ## Exemple : Shibboleth Cet exemple montre comment configurer Shibboleth pour l'utiliser avec PowerShell Universal. Il fournit la configuration la plus élémentaire et ne suit pas nécessairement les meilleures pratiques. Ceci suppose que vous avez installé Shibboleth Identity Provider v4 avec l'intégration Active Directory. ### ldap.properties Les propriétés LDAP ont été configurées pour s'authentifier auprès du domaine local à l'aide d'un compte d'administrateur de domaine. L'URL LDAP a été configurée et TLS a été désactivé. Vous trouverez ci-dessous l'exemple complet du fichier `ldap.properties`. {% code collapsedlinecount="10" %} ``` # LDAP authentication (and possibly attribute resolver) configuration # Note, this doesn't apply to the use of JAAS authentication via LDAP ## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator idp.authn.LDAP.authenticator=adAuthenticator ## Connection properties ## idp.authn.LDAP.ldapURL=ldap://ironman.local:389 idp.authn.LDAP.useStartTLS = false # Time in milliseconds that connects will block #idp.authn.LDAP.connectTimeout = PT3S # Time in milliseconds to wait for responses #idp.authn.LDAP.responseTimeout = PT3S # Connection strategy to use when multiple URLs are supplied, either ACTIVE_PASSIVE, ROUND_ROBIN, RANDOM #idp.authn.LDAP.connectionStrategy = ACTIVE_PASSIVE ## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust idp.authn.LDAP.sslConfig = jvmTrust ## If using certificateTrust above, set to the trusted certificate's path idp.authn.LDAP.trustCertificates=%{idp.home}/credentials/ldap-server.crt ## If using keyStoreTrust above, set to the truststore path idp.authn.LDAP.trustStore=%{idp.home}/credentials/ldap-server.truststore ## Return attributes during authentication idp.authn.LDAP.returnAttributes=passwordExpirationTime,loginGraceRemaining,sn,mail ## DN resolution properties ## # Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator # for AD: CN=Users,DC=example,DC=org idp.authn.LDAP.baseDN=CN=Users,DC=ironman, DC=local idp.authn.LDAP.subtreeSearch = true idp.authn.LDAP.userFilter=(sAMAccountName={user}) # bind search configuration # for AD: idp.authn.LDAP.bindDN=adminuser@domain.com idp.authn.LDAP.bindDN=administrator@ironman.local # Format DN resolution, used by directAuthenticator, adAuthenticator # for AD use idp.authn.LDAP.dnFormat=%s@domain.com idp.authn.LDAP.dnFormat=%s@ironman.local # pool passivator, either none, bind or anonymousBind #idp.authn.LDAP.bindPoolPassivator = none # LDAP attribute configuration, see attribute-resolver.xml # Note, this likely won't apply to the use of legacy V2 resolver configurations idp.attribute.resolver.LDAP.ldapURL=%{idp.authn.LDAP.ldapURL} idp.attribute.resolver.LDAP.connectTimeout=%{idp.authn.LDAP.connectTimeout:PT3S} idp.attribute.resolver.LDAP.responseTimeout=%{idp.authn.LDAP.responseTimeout:PT3S} idp.attribute.resolver.LDAP.connectionStrategy=%{idp.authn.LDAP.connectionStrategy:ACTIVE_PASSIVE} idp.attribute.resolver.LDAP.baseDN=%{idp.authn.LDAP.baseDN:undefined} idp.attribute.resolver.LDAP.bindDN=%{idp.authn.LDAP.bindDN:undefined} idp.attribute.resolver.LDAP.useStartTLS=%{idp.authn.LDAP.useStartTLS:true} idp.attribute.resolver.LDAP.trustCertificates=%{idp.authn.LDAP.trustCertificates:undefined} idp.attribute.resolver.LDAP.searchFilter=(sAMAccountName=$resolutionContext.principal) # LDAP pool configuration, used for both authn and DN resolution #idp.pool.LDAP.minSize = 3 #idp.pool.LDAP.maxSize = 10 #idp.pool.LDAP.validateOnCheckout = false #idp.pool.LDAP.validatePeriodically = true #idp.pool.LDAP.validatePeriod = PT5M #idp.pool.LDAP.validateDN = #idp.pool.LDAP.validateFilter = (objectClass=*) #idp.pool.LDAP.prunePeriod = PT5M #idp.pool.LDAP.idleTime = PT10M #idp.pool.LDAP.blockWaitTime = PT3S ``` {% endcode %} ### relying-party.xml Le fichier `relying-party.xml` a été mis à jour pour activer l'IdP ouvert. Cela signifie que n'importe quel entity ID peut communiquer avec le fournisseur d'identité. Vous pouvez aussi le configurer pour imposer des entity ID spécifiques. La configuration par défaut a également été ajustée pour utiliser le bean `SAML2.AttributeQuery`. {% code collapsedlinecount="10" %} ``` ``` {% endcode %} ### attribute-resolver.xml Le fichier `attribute-resolver.xml` a été mis à jour pour utiliser le connecteur de données LDAPDirectory. Il charge l'adresse courriel, le prénom, le SN et le nom d'affichage depuis Active Directory. Il mappe ensuite le Principal Name, qui sera le nom d'utilisateur de l'utilisateur qui se connecte, au type de revendication requis à l'aide d'un encodeur d'attribut. {% code collapsedlinecount="10" %} ``` ``` {% endcode %} ### attribute-filter.xml Le fichier `attribute-filter.xml` a été mis à jour pour publier plusieurs des attributs mappés par le connecteur de données LDAPDirectory ainsi que le nom d'utilisateur qui sera utilisé comme identité dans PowerShell Universal. {% code collapsedlinecount="10" %} ``` ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/powershell-universal/fr/securite/enterprise-security/saml2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.