SAML2

SAML2 requiere una licencia.

PowerShell Universal puede configurarse para integrarse con un proveedor de identidad SAML2. Esta documentación proporciona los detalles para configurar PSU con dicho sistema.

Carga automática de metadatos

PowerShell Universal proporciona un mecanismo para cargar el documento de metadatos directamente desde el proveedor de identidad SAML2 en lugar de proporcionar manualmente las opciones de configuración. Esto recopilará toda la información posible. Aún será necesario proporcionar el Entity ID.

La ruta de callback se mostrará en la parte superior del modal de la propiedad.

Carga de metadatos

Proporcionar los valores manualmente

Configuración del proveedor de identidad

Deberá configurar su proveedor de identidad para la aplicación PowerShell Universal. Deberá establecer un entity ID aceptable y asignar atributos. PowerShell Universal requiere que el atributo name esté asignado. El nombre del atributo debe ser el siguiente.

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

Debería asignarlo a la identidad de usuario que desee utilizar dentro de PowerShell Universal.

Se pueden asignar atributos adicionales que estarán disponibles durante la evaluación de roles. A continuación encontrará un ejemplo de configuración de Shibboleth.

Configuración del Entity ID

Se requiere HTTPS para la autenticación SAML2.

Existen varias opciones básicas que puede configurar en la consola de administración de PowerShell Universal. Para añadir compatibilidad con SAML2, haga clic en Security \ Authentication. En la esquina superior derecha, puede seleccionar SAML2 en el menú desplegable.

Una vez añadida la integración de SAML2, puede configurar los ajustes básicos para comunicarse con su proveedor de identidad. Necesitará configurar al menos el Entity ID y el Identity Provider Entity ID.

Normalmente, estos entity ID son URL configuradas dentro de su proveedor de identidad.

Propiedades de SAML2

El certificado de servicio se utiliza para firmar solicitudes. No es obligatorio. Puede ser una ruta local al servicio de PSU o el nombre distinguido de un certificado instalado en el almacén de certificados Personal Computer.

Configuración adicional

Además de las opciones disponibles en la consola de administración, también puede establecer lo siguiente en el fichero de configuración authentication.ps1.

ServiceCertificatePassword

Si utiliza una ruta de fichero para su certificado y este requiere una contraseña, puede especificarla mediante el parámetro -ServiceCertificatePassword de Set-PSUAuthenticationMethod. El valor de este parámetro es un SecureString. Puede aprovechar el módulo SecretManagement para cargar secretos.

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

El parámetro -Configure es un bloque de script que se puede utilizar para establecer opciones adicionales no expuestas por Set-PSUAuthenticationMethod. El bloque de script se invocará cuando se configure el proveedor y recibirá un único parámetro que contiene un objeto con las opciones para la autenticación SAML2.

El objeto es del tipo Saml2Options. El subobjeto de SPOptions se puede encontrar aquí.

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

Ejemplo: Entra ID

Configure una aplicación empresarial de Entra ID en Azure. Puede encontrar una guía paso a paso aquí. Deberá obtener el ID de la aplicación y el documento de metadatos de federación, así como el punto de conexión de inicio de sesión SAML-P. Dentro del registro de su aplicación, haga clic en el botón Endpoints.

Paso a paso

En PowerShell Universal:

1. Haga clic en Security \ Authentication.
2. Añada el proveedor de autenticación SAML2.
3. Haga clic en el botón Edit Properties.

En Entity ID, deberá poner el ID de la aplicación de Entra ID con el prefijo spn:

Por ejemplo: spn:2cf33625-e312-4659-a7bd-66ade51a0ea2

En Identity Provider Entity ID, deberá obtener el entity ID del documento de metadatos de federación. Abra la URL del documento en un navegador web.

En Metadata Address, inserte la URL del documento de metadatos de federación.

En Return URL, inserte la URL de su servidor PowerShell Universal con la ruta /Saml/Acs.

https://localhost/Saml2/Acs

En Single Sign-On Service URL, inserte el endpoint de inicio de sesión SAML-P de Azure.

Configuración de PSU

Una vez completado, guarde la configuración y habilite el proveedor SAML. Haga clic en cerrar sesión y navegue a la URL de su consola de administración.

https://localhost/admin

Se le redirigirá a Azure para iniciar sesión y volverá a PowerShell Universal después de la autenticación.

Cualquier error que se produzca aparecerá en el log de PowerShell Universal. Si no consigue iniciar sesión, puede navegar a /login para iniciar sesión con una cuenta local.

Asignación de claims

Para proporcionar claims de grupo a PowerShell Universal, deberá exponer los claims de grupo desde su registro de aplicación. Haga clic en Token Configuration y después en Add groups claim.

Claims de grupo de Entra ID

Después de hacer clic en Add groups claim, tendrá la opción de seleccionar qué grupos se proporcionan. Si selecciona All Groups, los claims de grupo se proporcionarán a PowerShell Universal

Si selecciona Groups assigned to the application, asegúrese de marcar el valor Emit groups as role claims. Esta opción requiere un plan de pago de Entra ID.

Opción Emit groups as role claims

Para asignar un grupo a su registro de aplicación, localice su aplicación en Enterprise Applications y haga clic en User and Groups. A continuación, haga clic en Add User\Group y seleccione los grupos que desea asignar a su aplicación.

Una vez que tenga el claim de grupos configurado en Entra ID, podrá actualizar las asignaciones de claims de PowerShell Universal a los grupos proporcionados.

Para cada rol que desee asignar a un grupo de Entra ID, especifique el Claim Type y el Claim Value de ese rol. Por ejemplo, tengo un grupo en mi entorno con el ID 446832da-d4ad-4972-b0a2-eda736129928. El Claim Type para este objeto es http://schemas.microsoft.com/ws/2008/06/identity/claims/role.

Para asignarlo al grupo de administradores, haría lo siguiente.

Asignación de claims

Los usuarios de este grupo formarían ahora parte del rol Administrator en PowerShell Universal. Si seleccionó una propiedad de grupo SAML diferente, el valor puede ser distinto (por ejemplo, sAMAccountName).

Excesos de grupos

En organizaciones con muchos grupos, conviene limitar el número de grupos proporcionados a PowerShell Universal. Esto puede aliviar los problemas de autorización que surgen al proporcionar demasiados grupos, lo que provoca que se superen los límites de la aplicación. Dentro de la configuración de la aplicación empresarial, haga clic en Single sign-on y después en el botón Edit debajo de Attributes & Claims.

Haga clic en el claim de grupos para ver las opciones. Las opciones avanzadas le permitirán filtrar los grupos que se proporcionan al servidor de PowerShell Universal. También puede configurar los claims de grupo mediante la configuración de tokens en el registro de aplicación de la aplicación empresarial.

Ejemplo: Okta

Este ejemplo muestra cómo configurar la autenticación SAML2 de Okta para su uso con PowerShell Universal.

Dentro de Okta, deberá configurar su aplicación de forma similar a la siguiente. SAML2 requiere HTTPS y deberá incluir la URL de su instancia de PSU en Single Sign On URL, seguida de /Saml2/Acs. La ruta distingue entre mayúsculas y minúsculas.

El Audience Restriction debe ser la URL de su servidor PowerShell Universal.

Para que sus usuarios puedan acceder a PowerShell Universal, deberá asegurarse de que se les haya asignado la aplicación de Okta.

En la pestaña Sign On de su aplicación, haga clic en el botón View SAML setup instructions.

Deberá capturar las dos URL y descargar el certificado para configurar PowerShell Universal. Consulte el siguiente paso para saber cómo utilizar estas URL en el fichero authentication.ps1.

authentication.ps1

El fichero authentication.ps1 se utiliza para configurar 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"

Parámetro	Descripción	Tipo
EntityId	Este valor debe coincidir con lo que puso en Audience Restriction dentro de Okta.	string
IdentityProviderEntityId	Este es el valor que se presentó en la página View SAML setup instructions.	string
CallbackPath	Esta es la ruta a la que se redirigirá al usuario si no se proporcionó ninguna ruta de redirección	string
SigningKey	Este es el fichero de certificado que se descargó en la página View SAML setup instructions.	string
SingleSignOnServiceUrl	Esta es la URL de inicio de sesión que se proporcionó en la página View SAML setup instructions.	string

Ejemplo: Shibboleth

Este ejemplo muestra cómo configurar Shibboleth para su uso con PowerShell Universal. Proporciona la configuración más básica y no necesariamente sigue las mejores prácticas.

Se supone que ha instalado Shibboleth Identity Provider v4 con integración de Active Directory.

ldap.properties

Las propiedades LDAP se han configurado para autenticar contra el dominio local utilizando una cuenta de administrador de dominio. Se ha configurado la URL de LDAP y se ha deshabilitado TLS.

A continuación encontrará el ejemplo completo del fichero 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

El fichero relying-party.xml se ha actualizado para habilitar el IdP abierto. Esto significa que cualquier entity ID puede comunicarse con el proveedor de identidad. También puede configurarlo para exigir entity ID específicos. La configuración predeterminada también se ha ajustado para utilizar el 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

El fichero attribute-resolver.xml se ha actualizado para utilizar el conector de datos LDAPDirectory. Carga la dirección de correo electrónico, el nombre de pila, el SN y el nombre para mostrar desde Active Directory. A continuación, asigna el Principal Name, que será el nombre de usuario del usuario que inicia sesión, al tipo de claim requerido mediante un codificador de atributos.

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

El fichero attribute-filter.xml se ha actualizado para liberar varios de los atributos asignados por el conector de datos LDAPDirectory, así como el nombre de usuario que se utilizará como identidad dentro de 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>