Asserção de Identidade para o Servidor de Recebimento de Dados

Quando um cliente é autenticado em um servidor, a credencial recebida é definida. Quando o mecanismo de autorização verifica a credencial para determinar se o acesso é permitido, ele também configura a credencial de chamada. A asserção de identidade é a credencial de chamada que é assegurada ao servidor de recebimento de dados.

Quando um cliente é autenticado em um servidor, a credencial recebida é definida. Quando o mecanismo de autorização verifica a credencial para determinar se o acesso é permitido, ele também configura a credencial de chamada, de modo que caso o método Enterprise JavaBeans (EJB) chame outro método EJB que esteja em outros servidores, a credencial de chamada possa ser a identidade usada para iniciar o método de recebimento. Dependendo do modo Executar Como para enterprise beans, a credencial de chamada é definida como a identidade do cliente de origem, a identidade do servidor ou uma identidade diferente especificada. Independente da identidade definida, quando a asserção de identidade está ativada, ela é a credencial de chamada que é assegurada ao servidor downstream.

[AIX Solaris HP-UX Linux Windows][IBM i]A identidade da credencial de chamada é enviada ao servidor downstream em um token de identidade. Além disso, a identidade do servidor de envio, incluindo senha ou token, é enviada no token de autenticação do cliente quando a autenticação básica é ativada. A identidade do servidor de envio é enviada através de uma autenticação de certificação do cliente SSL (Secure Sockets Layer) quando a autenticação de certificado do cliente é ativada. A autenticação básica tem precedência sobre a autenticação do certificado do cliente.

Ambos os tokens de identidade são necessários para que o servidor de recebimento aceite a identidade declarada. O servidor de recebimento conclui as seguintes ações para aceitar a identidade assegurada:
  • A identidade do servidor de envio enviada ao servidor de recebimento é um token GSSUP (ID do usuário e senha) ou um certificado de cliente SSL. No z/OS, o ID da tarefa iniciada do MVS é enviado em vez do token GSSUP quando o registro do usuário ativo é o S.O. local e a autorização SAF está ativada.
  • A confiança é estabelecida entre o servidor de envio e o de recebimento, dependendo de qual identidade está sendo enviada.
    1. Quando um token GGSUP é enviado, a confiança é estabelecida verificando se a identidade do servidor de envio está na lista principal confiável do servidor de recebimento.
    2. Quando o ID da tarefa iniciada do MVS é enviado, a confiança é estabelecida verificando se esse ID possui a autoridade UPDATE para o perfil CB.BIND.<servername> no banco de dados SAF.
    3. Quando um certificado de cliente SSL é enviado, no z/OS esse certificado é mapeado para um ID do usuário do Service Access Facility (SAF). A confiança é estabelecida verificando se esse ID do usuário tem a autoridade UPDATE para o perfil CB.BIND.<servername>.
  • Quando for determinado que o servidor de envio está na lista confiável, o servidor autentica o servidor de envio para verificar sua identidade.
  • O servidor é autenticado pela comparação do ID do usuário e senha do servidor de envio com os do servidor de recebimento. Se as credenciais do servidor de envio forem autenticadas e confiáveis, então, o servidor prossegue para avaliar o token de identidade.
  • O servidor de recebimento verifica no seu registro de usuário definido a presença do ID do usuário declarado para reunir mais informações de credenciais para propósitos de autorização (por exemplo, associações ao grupo). Assim, o registro do usuário do servidor de recebimento deve conter todos os IDs de usuários indicados. Caso contrário, a asserção de identidade não será possível. Em um servidor com estado, essa ação ocorre uma vez para o par de servidor de envio e de recebimento onde os tokens de identidade são os mesmos. Pedidos subsequentes são feitos por meio de um ID de sessão.
    Nota: Quando o servidor de recebimento de dados não tiver um registro de usuários com acesso aos IDs de usuários declarados em seu repositório, não utilize asserção de identidade porque as verificações de autorização falharão. Ao desativar a asserção de identidade, as verificações de autorização no servidor de recebimento não são necessárias.

[z/OS]O servidor de destino valida a autoridade do servidor de envio para afirmar uma identidade pelo certificado do cliente. O certificado de cliente é mapeado para um ID do usuário do Service Access Facility (SAF), usando os filtros RACDCERT MAP ou os filtros RACMAP definidos no banco de dados SAF. O ID de usuário SAF deve ter autoridade UPDATE para o perfil CB.BIND.<optionSAFProfilePrefix>.cluster_short_name na classe CBIND. Se um certificado de cliente não for enviado, a verificação CBIND será realizada no ID da tarefa iniciada do servidor de envio.

A avaliação do token de identidade consiste nos seguintes quatro formatos de identidade existentes em um token de identidade
  • Nome Principal
  • Nome Distinto
  • Cadeia de Certificados
  • Identidade Anônima
Os servidores do produto que recebem informações de autenticação geralmente suportam todos os quatro tipos de identidade. O servidor de envio decide o escolhido com base em como o cliente original foi autenticado. O tipo existente depende de como o cliente foi originalmente autenticado no servidor de envio. Por exemplo, se o cliente utilizar a autenticação de cliente SSL (Secure Sockets Layer) para autenticação no servidor de envio, então, o token de identidade enviado ao servidor downstream irá conter a cadeia de certificados. Com essas informações, o servidor de recebimento pode executar seu próprio mapeamento de canal de certificado e a interoperabilidade é aumentada com outros fornecedores e plataformas.

Quando o formato da identidade é entendido e analisado, a identidade é mapeada para uma credencial. Para um token de identidade ITTPrincipal, essa identidade é mapeada uma a uma com os campos de ID do usuário.

[AIX Solaris HP-UX Linux Windows][IBM i]Para um token de identidade ITTDistinguishedName, o mapeamento depende do registro do usuário. Para o LDAP (Lightweight Directory Access Protocol), o filtro de pesquisa configurado determina como o mapeamento ocorre. Para LocalOS, o primeiro atributo do DN (nome distinto), que é geralmente o mesmo que o nome comum, é mapeado para o ID do usuário do registro.

[z/OS]Tokens de identidade ITTDistinguishedName e ITTCertChain são mapeados da mesma forma. Ambos os tipos de tokens de identidade usam um certificado que é mapeado para um ID do usuário SAF usando o RACDCERT ou funções de mapeamento equivalentes, como filtros RACMAP. O mapeamento pode ser baseado no Nome do Subject ou Nome dos Emissores.

[AIX Solaris HP-UX Linux Windows][IBM i]A asserção de identidade somente está disponível usando o protocolo CSIv2 (Common Secure Interoperability Versão 2).

Nota: Existe uma restrição para o uso da asserção de identidade com o token KRB para recebimento de dados. Se você usar a asserção de identidade com Kerberos ativado, a asserção de identidade não tem o token de autenticação Kerberos (KRBAuthnToken) quando se encaminha para os servidores de recebimento de dados. Em vez disso, ela usará LTPA para a autenticação.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_csiv2ida
Nome do arquivo: csec_csiv2ida.html