Esses certificados são as âncoras de confiança. Eles permitem que você verifique as assinaturas e, portanto, estabeleça confiança nas mensagens que foram trocadas. (Isso é muito semelhante aos certificados de CA confiáveis que estão configurados no seu navegador para autenticar certificados de sites HTTPS.)
As solicitações e respostas de SAML devem ser assinadas (as respostas no mínimo). Você encontrará elementos como <ds:DigestMethod /> , <ds:DigestValue /> e <ds:SignatureValue /> (embora isso possa ser simplificado se você estiver usando a ligação de redirecionamento HTTP).
Quando o SP obtém uma resposta SAML do IdP através do navegador, ele deve verificar se a assinatura obtida vem de um IdP que ele conhece e o que assinou usando a chave privada do IdP; essa assinatura pode ser verificada em relação à chave pública do IdP no certificado configurado nos metadados.
Para um SP, deixar de fazer isso torna todo o processo sem valor, e ser capaz de aceitar qualquer afirmação sem verificar a autenticidade da mensagem do IdP sugere um erro de configuração.
No lado do IdP, é menos importante até certo ponto. É necessário apenas se o IdP desejar verificar se a solicitação realmente vem de um SP em que confia. É particularmente útil se o SP solicitar que determinados atributos confidenciais sejam divulgados (que nem todos os SPs devem ver) e, possivelmente, criptografar esses atributos na resposta, de modo que somente esse SP possa lê-lo.
Dito isto, o Shibboleth pode liberar esses atributos através de um canal de retorno (o serviço de atributos), onde uma conexão entre o SP e o IdP é feita diretamente (sem troca de mensagens com o navegador). A autenticação entre o SP e o IdP ainda deve ocorrer neste evento, mas acho que pode funcionar no nível do transporte (por exemplo, autenticação client-cert) em vez do nível da mensagem (por meio de assinaturas SAML), não tenho certeza. De qualquer forma, você também precisa configurar âncoras de confiança para isso.