Permita las peticiones de todos los clientes

Para asegurarse de que las peticiones de todos los clientes alcancen, los cambios se requieren en “$shibboleth_home/conf/access-control.xml” 

key= <entry " AccessByIPAddress " >
parent= <bean " shibboleth.IPRangeAccessControl” de " AccessByIPAddress” del id=
p: allowedRanges= " # {{'127.0.0.1/32', '0.0.0.0/0', '::1/128', '10.78.93.103/32'}}”/>
</entry>

Agregue '0.0.0.0/0' a los rangos permitidos. Esto permite las peticiones de cualquier rango del IP.

Santo y seña de la configuración a integrar con los IdS

Algoritmo de troceo seguro (SHA1) y configuración de encripción en los IdS

Para configurar los IdS para omitir el SHA1, “$shibboleth_home/conf/idp.properties abierto” y el conjunto:

idp.signing.config = shibboleth.SigningConfiguration.SHA1 

Esta configuración puede también ser cambiada:

idp.encryption.optional = verdad

Si usted la fija para verdad, el error localizar una clave de encripción para utilizar, cuando está habilitado, no dará lugar al error de la petición. Esto ayuda a hacer el cifrado “oportunista”, es decir, para cifrar siempre que sea posible (una clave compatible se encuentra en los meta datos del par para cifrar con) pero para saltar el cifrado de otra manera. 

Configure el uid y user_principal a la respuesta de SAML

El AttributeDefinition se agrega en “$shibboleth_home/conf/attribute-resolver.xml” para asociar el sAMAccountName y el userPrincipalName al al uid y user_principal en la respuesta de SAML.

Además, agregue las configuraciones del conector del ldap con el <DataConnector> de la etiqueta.

Note: ReturnAttributes necesita ser especificado con el valor “userPrincipalName del sAMAccountName”.

Note: LDAPProperty es obligatorio en caso de que si hay una integración con un Active Directory (AD).

<AttributeDefinition xsi:type="Simple" id="ciscoUPN" sourceAttributeID="userPrincipalName">
 <Dependency ref="LDAP" />
 <AttributeEncoder xsi:type="SAML1String" name="user_principal" />
 <AttributeEncoder xsi:type="SAML2String" name="user_principal" friendlyName="user_principal" />
</AttributeDefinition>
 
<AttributeDefinition xsi:type="Simple" id="ciscoUID" sourceAttributeID="sAMAccountName">
 <Dependency ref="LDAP" />
 <AttributeEncoder xsi:type="SAML1String" name="uid" />
 <AttributeEncoder xsi:type="SAML2String" name="uid" friendlyName="uid" />
</AttributeDefinition>
 
    <DataConnector id="LDAP" xsi:type="LDAPDirectory"
     ldapURL="ldap://adfsserver.cisco.com"
     baseDN="CN=users,DC=cisco,DC=com"
     principal="administrator@cisco.com"
     principalCredential="<cred>">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
      <ReturnAttributes>sAMAccountName userPrincipalName</ReturnAttributes>
      <LDAPProperty name="java.naming.referral" value="follow"/>
    </DataConnector>

Incorpore los cambios en “$shibboleth_home/conf/attribute-filter.xml”

<PolicyRequirementRule xsi:type="ANY" />
 
 
        <AttributeRule attributeID="ciscoUID">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
 
        <AttributeRule attributeID="ciscoUPN">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"   
        p:attributeSourceIds="#{ {'ciscoUPN'} }" />
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"   
        p:attributeSourceIds="#{ {'ciscoUID'} }" />

Meta datos de IdP

Los meta datos de IdP están disponibles en la carpeta “$shibboleth_home/metadata”. El archivo idp-metadata.xml se puede cargar a los IdS vía la interfaz de programación de aplicaciones (el API)

PONGA https://<idshost>:<idsport>/ids/v1/config/idpmetadata

donde no está el idsport una entidad configurable y el valor es el "8553"

Advertencia: Los meta datos del santo y seña pueden contener 2 Certificados de firma, el certificado de firma general y el backchannel. Navegue al archivo idp-backchannel.crt en “$shibboleth_home/credentials” para identificar el certificado del backchannel. Si el certificado del canal posterior está disponible en los meta datos, usted debe quitar el certificado del canal posterior del xml de los meta datos antes de la carga a los IdS. Esto es porque la biblioteca del fedlet 12.0 que los IdS utilizan los soportes solamente un certifcate en los meta datos. Si más de un certificado de firma está disponible, el fedlet utiliza el primer certificado disponible. 

Proveedores de los meta datos de la configuración

Necesitamos configurar los proveedores de los meta datos con la entrada en $shibboleth_home/metadata-providers.xml.

<MetadataProvider id="smart-86"  xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/SP/sp.xml"/>

donde el atributo " identificación " puede ser cualquier nombre único.

Esta entrada indica que un proveedor de los meta datos está registrado con la identificación dada y los meta datos están disponibles en el archivo especificado /opt/shibboleth-idp/SP/sp.xml.

Los meta datos del proveedor de servicio (SP) de los IdS se deben copiar al metadataFile especificados en la entrada.

Note: Los meta datos SP de los IdS se pueden extraer vía GET https://<idshost>:<idsport>/ids/v1/config/spmetadata, donde no está una entidad el idsport configurable y el valor es el "8553".