Installez et configurez le fournisseur d'identité de doctrine (IDP) pour la gestion d'identité de Cisco (id) pour activer SSO

Permettez les demandes de tous les clients

Pour s'assurer que les demandes de tous les clients atteignent, des changements sont exigés de « $shibboleth_home/conf/access-control.xml » 

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

Ajoutez '0.0.0.0/0' aux plages permises. Ceci permet des demandes de n'importe quelle plage d'IP.

Configurez la doctrine pour intégrer avec des id

Secure Hash Algorithm (SHA1) et configuration de chiffrement dans les id

Pour configurer des id pour se transférer sur SHA1, « $shibboleth_home/conf/idp.properties » ouvert et positionnement :

idp.signing.config = shibboleth.SigningConfiguration.SHA1 

Cette configuration peut également être changée :

idp.encryption.optional = rectifient

Si vous le placez pour rectifier, le manque de localiser une clé de chiffrement pour utiliser, quand activé, n'aura pas comme conséquence la panne de demande. Ceci aide à faire le cryptage « opportuniste », c.-à-d., pour chiffrer autant que possible (une clé compatible s'avère dans les métadonnées du pair pour chiffrer avec) mais pour ignorer le cryptage autrement. 

Configurez l'uid et user_principal à la réponse SAML

L'AttributeDefinition est ajouté dans « $shibboleth_home/conf/attribute-resolver.xml » pour tracer le sAMAccountName et l'userPrincipalName au à l'uid et user_principal dans la réponse SAML.

En outre, ajoutez les configurations de connecteur de LDAP avec le <DataConnector> de balise.

Note: ReturnAttributes doit être spécifié avec la valeur « userPrincipalName de sAMAccountName ».

Note: LDAPProperty serait obligatoire au cas où s'il y a une intégration avec un Répertoire actif (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>

Incorporez les changements de « $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'} }" />

Métadonnées d'IDP

Les métadonnées d'IDP est disponible dans le répertoire « $shibboleth_home/metadata ». Le fichier idp-metadata.xml peut être téléchargé aux id par l'intermédiaire de l'interface de programmation (l'API)

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

là où l'idsport n'est pas une entité configurable et la valeur est "8553"

Avertissement : Les métadonnées de doctrine peuvent contenir 2 Certificats de signature, le certificat de signature général et le backchannel. Naviguez vers le fichier idp-backchannel.crt dans « $shibboleth_home/credentials » pour identifier le certificat de backchannel. Si le certificat de canal de retour est disponible dans les métadonnées, vous devriez retirer le certificat de canal de retour du xml de métadonnées avant téléchargement sur des id. C'est parce que la bibliothèque du fedlet 12.0 que les id utilise des supports seulement un certifcate dans les métadonnées. Si plus d'un certificat de signature est disponible, le fedlet utilise le premier certificat disponible. 

Configurez les fournisseurs de métadonnées

Nous devons configurer les fournisseurs de métadonnées avec l'entrée dans $shibboleth_home/metadata-providers.xml.

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

là où l'attribut de " id " peut être n'importe quel nom unique.

Cette entrée indique qu'un fournisseur de métadonnées est inscrit à l'id donné et les métadonnées est disponible dans le fichier spécifié /opt/shibboleth-idp/SP/sp.xml.

Des métadonnées de fournisseur de services (fournisseur de services) des id doivent être copiées sur le metadataFile spécifié dans l'entrée.

Note: Des métadonnées de fournisseur de services des id peuvent être récupérées par l'intermédiaire de OBTIENNENT https://<idshost>:<idsport>/ids/v1/config/spmetadata, où l'idsport n'est pas une entité configurable et la valeur est "8553".