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.
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.
- 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.
- 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.
- 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.
- 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.
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.
- Nome Principal
- Nome Distinto
- Cadeia de Certificados
- Identidade Anônima
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.
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.
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.
A asserção de identidade somente está disponível usando o protocolo CSIv2 (Common Secure Interoperability Versão 2).