Instale e configurar o fornecedor da identidade do Shibboleth (IdP) para o serviço da identidade de Cisco (IdS) para permitir o SSO

Permita pedidos de todos os clientes

Para assegurar-se de que os pedidos de todos os clientes alcancem, as mudanças são exigidas em “$shibboleth_home/conf/access-control.xml” 

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

Adicionar '0.0.0.0/0' às escalas permitidas. Isto permite pedidos de toda a escala IP.

Configurar o Shibboleth para integrar com IdS

Algoritmo de mistura segura (SHA1) e configuração de criptografia nos IdS

Para configurar IdS para optar o SHA1, “$shibboleth_home/conf/idp.properties aberto” e grupo:

idp.signing.config = shibboleth.SigningConfiguration.SHA1 

Esta configuração pode igualmente ser mudada:

idp.encryption.optional = retificam

Se você a ajusta para retificar, a falha encontrar uma chave de criptografia para usar-se, quando permitida, não conduzirá à falha do pedido. Isto ajuda a fazer “oportunistamente” a criptografia, isto é, para cifrar sempre que possível (uma chave compatível é encontrada nos metadata do par para cifrar com) mas para saltar de outra maneira a criptografia. 

Configurar o uid e user_principal à resposta de SAML

O AttributeDefinition é adicionado em “$shibboleth_home/conf/attribute-resolver.xml” para traçar o sAMAccountName e o userPrincipalName ao ao uid e user_principal na resposta de SAML.

Além, adicionar os ajustes do conector do ldap com o <DataConnector> da etiqueta.

Note: ReturnAttributes precisa de ser especificado com valor do “userPrincipalName sAMAccountName”.

Note: LDAPProperty é imperativo caso que se há uma integração com um diretório ativo (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 as mudanças em “$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'} }" />

Metadata de IdP

Os metadata de IdP estão disponíveis no dobrador “$shibboleth_home/metadata”. O arquivo idp-metadata.xml pode ser transferido arquivos pela rede aos IdS através da interface de programação de aplicativo (o API)

PÕE https://<idshost>:<idsport>/ids/v1/config/idpmetadata

onde o idsport não está uma entidade configurável e o valor são "8553"

aviso: Os metadata do Shibboleth podem conter 2 Certificados de assinatura, o certificado de assinatura geral e o backchannel. Navegue ao arquivo idp-backchannel.crt em “$shibboleth_home/credentials” para identificar o certificado do backchannel. Se o certificado do canal traseiro está disponível nos metadata, você deve remover o certificado do canal traseiro do xml dos metadata antes da transferência de arquivo pela rede aos IdS. Isto é porque a biblioteca do fedlet 12.0 que os IdS usam apoios somente um certifcate nos metadata. Se mais de um certificado de assinatura está disponível, o fedlet usa o primeiro certificado disponível. 

Configurar fornecedores dos metadata

Nós precisamos de configurar os fornecedores dos metadata com a entrada em $shibboleth_home/metadata-providers.xml.

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

onde o atributo " identificação " pode ser todo o nome exclusivo.

Esta entrada indica que um fornecedor dos metadata está registrado com a identificação dada e os metadata estão disponíveis no arquivo especificado /opt/shibboleth-idp/SP/sp.xml.

Os metadata do provedor de serviços (SP) dos IdS devem ser copiados ao metadataFile especificados na entrada.

Note: Os metadata SP dos IdS podem ser recuperados através do GET https://<idshost>:<idsport>/ids/v1/config/spmetadata, onde o idsport não é uma entidade configurável e o valor é "8553".