SAML2

SAML2 erfordert eine Lizenz.

PowerShell Universal kann für die Integration mit einem SAML2-Identitätsanbieter konfiguriert werden. Diese Dokumentation enthält die Details zur Konfiguration von PSU mit einem solchen System.

Metadaten automatisch laden

PowerShell Universal bietet einen Mechanismus, um das Metadatendokument direkt vom SAML2-Identitätsanbieter zu laden, anstatt Konfigurationsoptionen manuell anzugeben. Dabei werden so viele Informationen wie möglich erfasst. Die Entity ID muss dennoch angegeben werden.

Der Callback-Pfad wird oben im Modal der Eigenschaft angezeigt.

Metadaten laden

Werte manuell angeben

Einstellungen des Identitätsanbieters

Sie müssen Ihren Identitätsanbieter für die PowerShell Universal-Anwendung konfigurieren. Sie müssen eine akzeptable Entity ID einrichten und Attribute zuordnen. PowerShell Universal erfordert, dass das Attribut name zugeordnet ist. Der Attributname muss der folgende sein.

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

Sie sollten dies der Benutzeridentität zuordnen, die innerhalb von PowerShell Universal verwendet werden soll.

Weitere Attribute können zugeordnet werden und stehen während der Rollenauswertung zur Verfügung. Ein Beispiel für die Konfiguration von Shibboleth finden Sie unten.

Entity ID-Einstellungen

HTTPS ist für die SAML2-Authentifizierung erforderlich.

Es gibt mehrere grundlegende Einstellungen, die Sie in der PowerShell Universal-Verwaltungskonsole konfigurieren können. Um SAML2-Unterstützung hinzuzufügen, klicken Sie auf Security \ Authentication. In der oberen rechten Ecke können Sie SAML2 aus dem Dropdown-Menü auswählen.

Sobald die SAML2-Integration hinzugefügt wurde, können Sie die grundlegenden Einstellungen für die Kommunikation mit Ihrem Identitätsanbieter konfigurieren. Sie müssen mindestens die Entity ID und die Identity Provider Entity ID konfigurieren.

Typischerweise sind diese Entity IDs URLs, die in Ihrem Identitätsanbieter konfiguriert sind.

SAML2-Eigenschaften

Das Dienstzertifikat wird zum Signieren von Anfragen verwendet. Es ist nicht erforderlich. Dies kann entweder ein für den PSU-Dienst lokaler Pfad oder der Distinguished Name eines im Zertifikatspeicher „Personal Computer“ installierten Zertifikats sein.

Zusätzliche Einstellungen

Zusätzlich zu den in der Verwaltungskonsole verfügbaren Einstellungen können Sie Folgendes in der Konfigurationsdatei authentication.ps1 festlegen.

ServiceCertificatePassword

Wenn Sie einen Dateipfad für Ihr Zertifikat verwenden und dieses ein Passwort erfordert, können Sie es über -ServiceCertificatePassword von Set-PSUAuthenticationMethod angeben. Der Wert dieses Parameters ist ein SecureString. Sie können das SecretManagement-Modul nutzen, um Geheimnisse zu laden.

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

Der Parameter -Configure ist ein Skriptblock, mit dem zusätzliche Einstellungen festgelegt werden können, die von Set-PSUAuthenticationMethod nicht bereitgestellt werden. Der Skriptblock wird aufgerufen, wenn der Anbieter konfiguriert wird, und erhält einen einzelnen Parameter, der ein Objekt mit den Optionen für die SAML2-Authentifizierung enthält.

Das Objekt ist vom Typ Saml2Options. Das Unterobjekt von SPOptions finden Sie hier.

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

Beispiel: Entra ID

Richten Sie eine Entra ID Enterprise Application in Azure ein. Eine Schritt-für-Schritt-Anleitung finden Sie hier. Sie müssen die Anwendungs-ID und das Dokument mit den Verbundmetadaten sowie den SAML-P-Anmeldeendpunkt abrufen. Klicken Sie in Ihrer Anwendungsregistrierung auf die Schaltfläche „Endpunkte“.

Schritt für Schritt

Innerhalb von PowerShell Universal:

1. Klicken Sie auf Security \ Authentication.
2. Fügen Sie den SAML2-Authentifizierungsanbieter hinzu.
3. Klicken Sie auf die Schaltfläche Edit Properties.

Für die Entity ID müssen Sie die Entra ID-Anwendungs-ID mit dem Präfix spn: angeben

Zum Beispiel: spn:2cf33625-e312-4659-a7bd-66ade51a0ea2

Für die Identity Provider Entity ID müssen Sie die Entity ID aus dem Federation-Metadatendokument abrufen. Öffnen Sie die Dokument-URL in einem Webbrowser.

Fügen Sie für Metadata Address die URL des Federation-Metadatendokuments ein.

Fügen Sie für die Return URL die URL Ihres PowerShell Universal-Servers mit dem Pfad /Saml/Acs ein.

https://localhost/Saml2/Acs

Fügen Sie für Single Sign-On Service URL den SAML-P-Anmeldeendpunkt aus Azure ein.

PSU-Konfiguration

Speichern Sie nach Abschluss die Einstellungen und aktivieren Sie den SAML-Anbieter. Klicken Sie auf Abmelden und navigieren Sie zur URL Ihrer Verwaltungskonsole.

https://localhost/admin

Sie werden zur Anmeldung an Azure weitergeleitet und nach der Authentifizierung zurück zu PowerShell Universal umgeleitet.

Alle auftretenden Fehler werden im PowerShell Universal-Protokoll aufgeführt. Wenn die Anmeldung fehlschlägt, können Sie zu /login navigieren, um sich mit einem lokalen Konto anzumelden.

Claim-Zuordnung

Um PowerShell Universal Gruppen-Claims bereitzustellen, müssen Sie die Gruppen-Claims aus Ihrer App-Registrierung verfügbar machen. Klicken Sie auf Token Configuration und dann auf Add groups claim.

Entra ID-Gruppen-Claims

Nachdem Sie auf Add groups claim geklickt haben, haben Sie die Möglichkeit auszuwählen, welche Gruppen bereitgestellt werden. Wenn Sie All Groups auswählen, werden die Gruppen-Claims an PowerShell Universal bereitgestellt

Wenn Sie Groups assigned to the application auswählen, stellen Sie sicher, dass Sie den Wert Emit groups as role claims aktivieren. Diese Einstellung erfordert einen kostenpflichtigen Entra ID-Plan.

Einstellung „Emit groups as role claims“

Um Ihrer App-Registrierung eine Gruppe zuzuweisen, suchen Sie Ihre App in Enterprise Applications und klicken Sie auf User and Groups. Klicken Sie anschließend auf Add User\Group und wählen Sie die Gruppen aus, die Sie Ihrer Anwendung zuweisen möchten.

Sobald Sie den Gruppen-Claim in Entra ID konfiguriert haben, können Sie die Claim-Zuordnungen von PowerShell Universal auf die bereitgestellten Gruppen aktualisieren.

Geben Sie für jede Rolle, die Sie einer Entra ID-Gruppe zuweisen möchten, den Claim Type und den Claim Value für diese Rolle an. Beispielsweise habe ich in meiner Umgebung eine Gruppe mit der ID 446832da-d4ad-4972-b0a2-eda736129928. Der Claim Type für dieses Objekt ist http://schemas.microsoft.com/ws/2008/06/identity/claims/role.

Um dies der Administratorgruppe zuzuweisen, würde ich Folgendes tun.

Claim-Zuordnung

Benutzer dieser Gruppe wären nun Teil der Administrator-Rolle in PowerShell Universal. Wenn Sie eine andere SAML-Gruppeneigenschaft ausgewählt haben, kann der Wert abweichen (z. B. sAMAccountName).

Gruppenüberschreitungen

Für Organisationen mit vielen Gruppen sollten Sie die Anzahl der an PowerShell Universal bereitgestellten Gruppen begrenzen. Dies kann Autorisierungsprobleme mindern, die entstehen, wenn zu viele Gruppen bereitgestellt werden und dadurch Grenzwerte innerhalb der Anwendung überschritten werden. Klicken Sie in den Einstellungen der Enterprise Application auf Single sign-on und anschließend auf die Schaltfläche Edit unter Attributes & Claims.

Klicken Sie auf den Gruppen-Claim, um die Optionen anzuzeigen. Die erweiterten Optionen ermöglichen es Ihnen, die Gruppen zu filtern, die an den PowerShell Universal-Server bereitgestellt werden. Sie können Gruppen-Claims auch über die Token-Konfiguration in der Application Registration für die Enterprise Application konfigurieren.

Beispiel: Okta

Dieses Beispiel zeigt, wie die Okta SAML2-Authentifizierung für die Verwendung mit PowerShell Universal konfiguriert wird.

In Okta müssen Sie Ihre Anwendung ähnlich wie folgt konfigurieren. HTTPS ist für SAML2 erforderlich, und Sie müssen die URL Ihrer PSU-Instanz in der Single Sign On URL angeben, gefolgt von /Saml2/Acs. Beim Pfad wird zwischen Groß- und Kleinschreibung unterschieden.

Die Audience Restriction sollte die URL Ihres PowerShell Universal-Servers sein.

Damit Ihre Benutzer auf PowerShell Universal zugreifen können, müssen Sie sicherstellen, dass sie der Okta-Anwendung zugewiesen wurden.

Klicken Sie auf der Registerkarte Sign On Ihrer Anwendung auf die Schaltfläche View SAML setup instructions.

Sie müssen die beiden URLs erfassen und das Zertifikat herunterladen, um PowerShell Universal zu konfigurieren. Im nächsten Schritt erfahren Sie, wie Sie diese URLs innerhalb der Datei authentication.ps1 verwenden.

authentication.ps1

Die Datei authentication.ps1 wird zur Konfiguration von PowerShell Universal verwendet.

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"

Parameter	Beschreibung	Typ
EntityId	Dieser Wert sollte mit dem übereinstimmen, was Sie in Okta unter Audience Restriction eingetragen haben.	string
IdentityProviderEntityId	Dies ist der Wert, der auf der Seite View SAML setup instructions angezeigt wurde.	string
CallbackPath	Dies ist der Pfad, zu dem der Benutzer umgeleitet wird, wenn kein Umleitungspfad angegeben wurde	string
SigningKey	Dies ist die Zertifikatsdatei, die auf der Seite View SAML setup instructions heruntergeladen wurde.	string
SingleSignOnServiceUrl	Dies ist die Anmelde-URL, die auf der Seite View SAML setup instructions angegeben wurde.	string

Beispiel: Shibboleth

Dieses Beispiel zeigt, wie Shibboleth für die Verwendung mit PowerShell Universal konfiguriert wird. Es bietet die grundlegendste Konfiguration und folgt nicht notwendigerweise Best Practices.

Dabei wird davon ausgegangen, dass Sie Shibboleth Identity Provider v4 mit Active Directory-Integration installiert haben.

ldap.properties

Die LDAP-Eigenschaften wurden so konfiguriert, dass die Authentifizierung gegen die lokale Domäne mit einem Domänenadministratorkonto erfolgt. Die LDAP-URL wurde konfiguriert und TLS wurde deaktiviert.

Unten finden Sie das vollständige Beispiel der Datei 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=[e-mail]
idp.authn.LDAP.bindDN=[e-mail]

# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=[e-mail]
idp.authn.LDAP.dnFormat=[e-mail]

# 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

Die Datei relying-party.xml wurde aktualisiert, um einen offenen IdP zu aktivieren. Das bedeutet, dass jede Entity ID mit dem Identitätsanbieter kommunizieren kann. Sie können dies auch so konfigurieren, dass bestimmte Entity IDs erzwungen werden. Die Standardkonfiguration wurde ebenfalls angepasst, um das Bean SAML2.AttributeQuery zu verwenden.

<?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

Die Datei attribute-resolver.xml wurde aktualisiert, um den LDAPDirectory Data Connector zu verwenden. Sie lädt die E-Mail-Adresse, den Vornamen, SN und den Anzeigenamen aus Active Directory. Anschließend ordnet sie den Principal Name, der der Benutzername des sich anmeldenden Benutzers ist, mithilfe eines Attribut-Encoders dem erforderlichen Claim Type zu.

<?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

Die Datei attribute-filter.xml wurde aktualisiert, um mehrere der vom LDAPDirectory Data Connector zugeordneten Attribute freizugeben sowie den Benutzernamen, der als Identität innerhalb von PowerShell Universal verwendet wird.

<?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>