SAML2

Authentification SAML2 pour PowerShell Universal.

SAML2 nécessite une licence.

PowerShell Universal peut être configuré pour s'intégrer à un fournisseur d'identité SAML2. Cette documentation fournit les détails nécessaires à la configuration de PSU avec un tel système.

Chargement automatique des métadonnées

PowerShell Universal offre 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. Cette méthode recueille autant d'informations que possible. L'Entity ID devra tout de même être fourni.

Le chemin de rappel sera affiché en haut de la fenêtre modale de la propriété.

Saisie manuelle des valeurs

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.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Vous devez le mapper à 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. Vous trouverez ci-dessous un exemple de configuration de Shibboleth.

Paramètres de l'Entity ID

HTTPS est requis pour l'authentification SAML2.

Plusieurs paramètres de base peuvent être configurés dans la console d'administration de PowerShell Universal. Pour ajouter la prise en charge de SAML2, cliquez sur Sécurité \ Authentification. Dans le coin supérieur droit, vous pouvez sélectionner SAML2 dans le menu déroulant.

Une fois l'intégration SAML2 ajoutée, vous pouvez configurer les paramètres de base pour communiquer avec votre fournisseur d'identité. Vous aurez besoin au minimum de l'Entity ID et de l'Identity Provider Entity ID configurés.

En règle générale, 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 obligatoire. Il peut s'agir d'un chemin local au service PSU ou du nom distinctif d'un certificat installé dans le magasin de certificats Personal Computer.

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 qu'il nécessite un mot de passe, vous pouvez le spécifier via le paramètre -ServiceCertificatePassword de Set-PSUAuthenticationMethod. La valeur de ce paramètre est une SecureString. Vous pouvez utiliser le module SecretManagement pour charger des secrets.

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')

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é lors de la configuration du fournisseur et recevra un seul paramètre contenant un objet avec les options pour l'authentification SAML2.

L'objet est de type Saml2Options. Le sous-objet SPOptions se trouve ici.

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'
}

Exemple : Entra ID

Configurez une application d'entreprise Entra ID dans Azure. Vous trouverez un guide étape par étape ici. Vous devrez récupérer l'ID d'application, le document de métadonnées de fédération ainsi que le point de terminaison SAML-P. Dans votre inscription d'application, cliquez sur le bouton Points de terminaison.

Étape par étape

Dans PowerShell Universal :

Cliquez sur Sécurité \ Authentification.
Ajoutez le fournisseur d'authentification SAML2.
Cliquez sur le bouton Modifier les propriétés.

Pour l'Entity ID, vous devrez saisir l'ID d'application Entra ID précédé du préfixe spn:

Par exemple : spn:2cf33625-e312-4659-a7bd-66ade51a0ea2

Pour l'Identity Provider Entity ID, vous devrez récupérer l'entity ID depuis le document de métadonnées de fédération. Ouvrez l'URL du document dans un navigateur web.

Pour l'adresse de métadonnées, insérez l'URL du document de métadonnées de fédération.

Pour l'URL de retour, insérez l'URL de votre serveur PowerShell Universal avec le chemin /Saml/Acs.

https://localhost/Saml2/Acs

Pour l'URL du service d'authentification unique, insérez le point de terminaison SAML-P depuis Azure.

Une fois terminé, enregistrez les paramètres et activez le fournisseur SAML. Cliquez sur Se déconnecter et accédez à l'URL de votre console d'administration.

https://localhost/admin

Vous serez redirigé vers Azure pour vous connecter, puis redirigé vers PowerShell Universal après l'authentification.

Toute erreur survenue sera consignée dans le journal de PowerShell Universal. Si la connexion échoue, vous pouvez accéder à /login pour vous connecter avec un compte local.

Mappage des revendications

Pour fournir des revendications de groupe à PowerShell Universal, vous devrez exposer les revendications de groupe depuis votre inscription d'application. Cliquez sur Configuration des jetons, puis sur Ajouter une revendication de groupes.

Après avoir cliqué sur Ajouter une revendication de groupes, vous aurez la possibilité de sélectionner les groupes à fournir. Si vous sélectionnez Tous les groupes, les revendications de groupe seront transmises à PowerShell Universal.

Si vous sélectionnez Groupes affectés à l'application, assurez-vous de cocher la valeur Émettre les groupes en tant que revendications de rôles. Ce paramètre nécessite un plan Entra ID payant.

Pour affecter un groupe à votre inscription d'application, localisez votre application dans Applications d'entreprise et cliquez sur Utilisateurs et groupes. Ensuite, cliquez sur Ajouter un utilisateur\groupe et sélectionnez les groupes que vous souhaitez affecter à votre application.

Une fois les revendications de groupe configurées dans Entra ID, vous pouvez mettre à jour les mappages de revendications de PowerShell Universal pour les groupes fournis.

Pour chaque rôle que vous souhaitez affecter à un groupe Entra ID, spécifiez le Type de revendication et la Valeur de revendication pour ce rôle. Par exemple, j'ai un groupe dans mon environnement avec l'ID 446832da-d4ad-4972-b0a2-eda736129928. Le Type de revendication pour cet objet est http://schemas.microsoft.com/ws/2008/06/identity/claims/role.

Pour affecter ce groupe au groupe administrateur, je procéderais comme suit.

Les utilisateurs de ce groupe feront désormais partie du rôle Administrateur dans PowerShell Universal. Si vous avez sélectionné une propriété de groupe SAML différente, la valeur peut être différente (par exemple, sAMAccountName).

Dépassements de groupe

Pour les organisations disposant de nombreux groupes, il est recommandé de limiter le nombre de groupes transmis à PowerShell Universal. Cela peut résoudre les problèmes d'autorisation liés à un trop grand nombre de groupes dépassant les limites de l'application. Dans les paramètres de l'application d'entreprise, cliquez sur Authentification unique, puis sur le bouton Modifier sous Attributs et revendications.

Cliquez sur la revendication de groupes pour afficher les options. Les options avancées vous permettront de filtrer les groupes transmis au serveur PowerShell Universal. Vous pouvez également configurer les revendications de groupe via la configuration des jetons dans l'inscription d'application pour l'application d'entreprise.

Exemple : Okta

Cet exemple montre comment configurer l'authentification SAML2 Okta pour une utilisation avec PowerShell Universal.

Dans Okta, vous devrez configurer votre application de manière similaire à ce qui suit. HTTPS est requis par SAML2, et vous devrez inclure l'URL de votre instance PSU dans l'URL d'authentification unique, suivie de /Saml2/Acs. Le chemin est sensible à la casse.

La restriction d'audience doit correspondre à l'URL de votre serveur PowerShell Universal.

Pour que vos utilisateurs puissent accéder à PowerShell Universal, vous devez vous assurer qu'ils ont été affectés à l'application Okta.

Dans l'onglet Authentification de votre application, cliquez sur le bouton Afficher les instructions de configuration SAML.

Vous devrez récupérer les deux URL et télécharger le certificat pour configurer PowerShell Universal. Consultez l'étape suivante pour savoir comment utiliser ces URL dans le fichier authentication.ps1.

authentication.ps1

Le fichier authentication.ps1 est utilisé pour configurer PowerShell Universal.

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"

Paramètre

Description

Type

EntityId

Cette valeur doit correspondre à ce que vous avez saisi dans la restriction d'audience dans Okta.

string

IdentityProviderEntityId

Il s'agit de la valeur présentée dans la page des instructions de configuration SAML.

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 téléchargé sur la page des instructions de configuration SAML.

string

SingleSignOnServiceUrl

Il s'agit de l'URL d'authentification fournie sur la page des instructions de configuration SAML.

string

Exemple : Shibboleth

Cet exemple montre comment configurer Shibboleth pour une utilisation avec PowerShell Universal. Il fournit la configuration la plus simple et ne suit pas nécessairement les meilleures pratiques.

Cet exemple suppose que vous avez installé Shibboleth Identity Provider v4 avec une intégration Active Directory.

ldap.properties

Les propriétés LDAP ont été configurées pour s'authentifier sur le domaine local à l'aide d'un compte 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.

# 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

relying-party.xml

Le fichier relying-party.xml a été mis à jour pour activer l'IdP ouvert. Cela signifie que tout Entity ID peut communiquer avec le fournisseur d'identité. Vous pouvez également configurer cela pour imposer des Entity ID spécifiques. La configuration par défaut a également été ajustée pour utiliser le bean SAML2.AttributeQuery.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:c="http://www.springframework.org/schema/c"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
                           
       default-init-method="initialize"
       default-destroy-method="destroy">

    <!--
    Unverified RP configuration, defaults to no support for any profiles. Add <ref> elements to the list
    to enable specific default profile settings (as below), or create new beans inline to override defaults.
    
    "Unverified" typically means the IdP has no metadata, or equivalent way of assuring the identity and
    legitimacy of a requesting system. To run an "open" IdP, you can enable profiles here.
    -->
    <bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
			<bean parent="SAML2.SSO" p:encryptAssertions="false" />
            </list>
        </property>
    </bean>

    <!-- Default configuration, with default settings applied for all profiles. -->
    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <!-- SAML 1.1 and SAML 2.0 AttributeQuery are disabled by default. -->
                <!--
                <bean parent="Shibboleth.SSO" />
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                -->
                <bean parent="SAML2.SSO" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>
</beans>

attribute-resolver.xml

Le fichier attribute-resolver.xml a été mis à jour pour utiliser le connecteur de données LDAPDirectory. Il charge l'adresse e-mail, le prénom, le SN et le nom d'affichage depuis Active Directory. Il mappe ensuite le nom principal, qui correspond au nom d'utilisateur de la personne qui se connecte, au type de revendication requis à l'aide d'un encodeur d'attribut.

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This file is an EXAMPLE configuration file containing some example attributes
    based on some commonly used approaches when LDAP is the principal data source.
     
    Not all attribute definitions or data connectors are demonstrated, but some
    LDAP attributes common to Shibboleth deployments (and some not so common) are
    included.

    This example is in no way usable as a substitute for reading the documentation.    
-->
<AttributeResolver
        xmlns="urn:mace:shibboleth:2.0:resolver"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd">

    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->

    <!-- Simple attributes are exported directly from the LDAP connector. -->

    <AttributeDefinition id="uid" xsi:type="PrincipalName" />
    <AttributeDefinition id="username" xsi:type="PrincipalName">
         <AttributeEncoder xsi:type="SAML2String" name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" friendlyName="displayName" encodeType="false" />
    </AttributeDefinition>

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <!-- Example LDAP Connector -->

    <DataConnector id="myLDAP" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN}" 
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
        connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
        responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}"
        connectionStrategy="%{idp.attribute.resolver.LDAP.connectionStrategy}"
        noResultIsError="true"
        multipleResultsIsError="true"
        excludeResolutionPhases="c14n/attribute"
        exportAttributes="mail displayName sn givenName">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
        <ConnectionPool
            minPoolSize="%{idp.pool.LDAP.minSize:3}"
            maxPoolSize="%{idp.pool.LDAP.maxSize:10}"
            blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}"
            validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}"
            validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}"
            validateDN="%{idp.pool.LDAP.validateDN:}"
            validateFilter="%{idp.pool.LDAP.validateFilter:(objectClass=*)}"
            expirationTime="%{idp.pool.LDAP.idleTime:PT10M}"/>
    </DataConnector>

</AttributeResolver>

attribute-filter.xml

Le fichier attribute-filter.xml a été mis à jour pour publier plusieurs attributs mappés par le connecteur de données LDAPDirectory, ainsi que le nom d'utilisateur qui sera utilisé comme identité dans PowerShell Universal.

<?xml version="1.0" encoding="UTF-8"?>
<!-- 
    This file is an EXAMPLE policy file.  While the policy presented in this 
    example file is illustrative of some simple cases, it relies on the names of
    non-existent example services and the example attributes demonstrated in the
    default attribute-resolver.xml file.

    This example does contain some usable "general purpose" policies that may be
    useful in conjunction with specific deployment choices, but those policies may
    not be applicable to your specific needs or constraints.    
-->
<AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
        xmlns="urn:mace:shibboleth:2.0:afp"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd">

<AttributeFilterPolicy id="example1">
        <PolicyRequirementRule xsi:type="ANY" />
        <AttributeRule attributeID="username">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="displayName">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="uid">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="mail">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="sn">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
    </AttributeFilterPolicy>
 


</AttributeFilterPolicyGroup>

PrécédentOpenID Connect SuivantWS-Federation

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?