Integração de aplicativo (provedor de serviço)

casso127figsbrbr
HID_application-integration
A caixa de diálogo Integração de aplicativo permite configurar a maneira como o sistema de federação lida com as seguintes tarefas:
  • Como direcionar usuários para o aplicativo de destino no provedor de serviço.
  • Como mapear atributos de assertion para atributos usados pelo aplicativo de destino.
  • Como um aplicativo de provisionamento de terceiros estabelece contas de usuário.
  • Como os usuários são redirecionados quando ocorre uma falha na autenticação.
Configuração do aplicativo de destino (SAML, WSFED)
Na seção Aplicativo de destino, é possível especificar o aplicativo de destino e a maneira como os usuários são direcionados para o aplicativo de destino.
  • Modo de redirecionamento
    Especifica o método usado pelo provedor de serviço para redirecionar o usuário para o recurso de destino.
    Padrão:
    sem dados
    As opções para esse campo são as seguintes:
    • Sem dados (padrão)
      O usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados.
    • Dados de cookie
      O usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302. Este redirecionamento inclui um cookie da sessão e dados de cookie adicionais que estão configurados na autoridade de confirmação.
      Para o SAML 1.1 e 2.0, ativar essa opção exibe o seguinte campo adicional:
      Dados do cookie do atributo de codificação de URL
      Indica que o atributo enviado no cookie é codificado em URL. O atributo é codificado por URL, pois os caracteres no URL atendem a uma finalidade exclusiva que não é o padrão para um URL. Essa configuração é válida apenas com o modo de redirecionamento Dados de cookie.
      Se você especificar qualquer caractere especial na tabela de atributos do aplicativo, selecione essa opção. Por exemplo, analise essa configuração para todos os atributos com caracteres do idioma japonês. Caracteres especiais podem ser adicionados a partir da lista suspensa ou inseridos manualmente. Além disso, o aplicativo de destino deve decodificar o nome e o valor do atributo do aplicativo recebido.
       
    • Cookie de formato aberto
      O usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de formato aberto, mas sem outros dados. O aplicativo do destinatário descriptografa o cookie criptografado para obter as informações do usuário.
      Se o provedor de serviço receber um assertion com vários valores de atributo, ele transmitirá todos os valores para o aplicativo de destino.
    • Postagem de cookie de formato aberto
      O usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de formato aberto, mas os dados são enviados em uma solicitação HTTP-POST. Se você estiver preocupado que dados podem se perder devido à limitação de tamanho de dados de cookie, selecione essa opção.
      Se você selecionar a opção de cookie de formato aberto ou a de postagem de cookie de formato aberto, a interface exibirá os seguintes campos adicionais:
      • Nome do cookie de formato aberto
        Especifica o nome do cookie de formato aberto.
      • Transformação de criptografia
        Indica o algoritmo de criptografia que criptografa o cookie de formato aberto.
        Se selecionar um dos algoritmos compatíveis com FIPS (algoritmos AES), o sistema de destino deverá usar um SDK do
        CA SiteMinder® Federation
        para utilizar o cookie. O SDK deve estar no mesmo servidor que o aplicativo de destino.
        Se você estiver usando o SDK do .NET para utilizar o cookie, use o algoritmo de criptografia AES128/CBC/PKCS5Padding.
      • Senha de criptografia
        Indica a senha usada para criptografar o cookie. Os campos Senha de criptografia e Confirmar senha são obrigatórios para o cookie de formato aberto, mas a senha é opcional para o cookie herdado.
        Importante:
        se fornecer uma senha para o cookie legado, defina o mesmo valor para o SDK do Java do
        CA SiteMinder® Federation
        . A senha permite que o SDK descriptografe o cookie. Os valores são compartilhados em uma comunicação fora de banda.
      • Confirmar senha
        Confirma a entrada de senha de criptografia.
      • Ativar HMAC
        Indica que um HMAC (Hash Message Authentication Code - Código de Autenticação de Mensagem de Hash) é gerado usando a senha de criptografia fornecida nessa caixa de diálogo.
        Os MACs (Message Authentication Codes - Códigos de Autenticação de Mensagem) podem verificar a integridade das informações enviadas entre duas partes. As duas partes compartilham uma chave secreta para o cálculo e a verificação dos valores de autenticação da mensagem. Um HMAC é um mecanismo de MAC que se baseia em funções de hash criptográfico. Os HMACs têm uma entrada de mensagem e uma chave secreta que são conhecidas apenas pelo originador da mensagem e pelo receptor pretendido.
        Se você marcar a caixa de seleção Ativar HMAC, o sistema gerará um valor de HMAC para seu cookie de formato aberto. O valor de HMAC é precedido ao valor do cookie de formato aberto e, em seguida, criptografa toda a sequência de caracteres. O sistema coloca a sequência de caracteres criptografada no cookie de formato aberto que, em seguida, é transmitido para o aplicativo de destino.
      • Ativar cookie entre aspas
        Especifica que o valor do cookie de formato aberto está entre aspas duplas. Essa especificação permite o processamento do cookie em casos em que caracteres sem suporte são incluídos no valor do cookie.
    • Cabeçalhos HTTP (apenas para SAML 1.1 e 2.0)
      O usuário é redirecionado para o aplicativo de destino com cabeçalhos HTTP, mas sem outros dados. O Servidor de políticas pode fornecer vários valores de atributo em um único cabeçalho separando cada valor com uma vírgula.
    • Persistir atributos
      O usuário é redirecionado por meio de um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados. Esse modo também instrui o servidor de políticas a armazenar os atributos extraídos de um assertion no repositório de sessões. O
      CA Single Sign-on
      pode fornecer os atributos como variáveis de cabeçalho HTTP.
      para ver essa opção, ative o repositório de sessões usando o Console de gerenciamento do servidor de políticas.
       Se você selecionar Persistir atributos, e a asserção tiver atributos em branco, um valor NULL será gravado no repositório de sessões. Esse valor funciona como um espaço reservado para o atributo vazio e é transmitido para qualquer aplicativo que esteja usando o atributo.
    • casso127figsbrbr
      Redirecionamento de servidor
      Instrui o sistema de federação a transmitir os atributos de cabeçalho e cookie recebidos no assertion para o aplicativo de destino. O serviço que utiliza os assertions coleta as credenciais do usuário e, em seguida, transfere o usuário para o URL do aplicativo de destino usando um redirecionamento do lado do servidor Java.
      Para usar esse modo, siga estes requisitos:
      • Todos os arquivos de aplicativo de destino devem estar no diretório raiz do aplicativo. Esse diretório é:
        • Web Agent:
           web_agent_home
          \webagent\affwebservices
        • SPS federation gateway:
           sps_home
          \secure-proxy\Tomcat\webapps\affwebservices
           
      • O URL de destino especificado deve ser
        relativo
        ao contexto do servlet que está utilizando o assertion. O contexto é
        /affwebservices/public/
        e a raiz do contexto é
        /affwebservices/
        , que é a raiz do aplicativo Federation Web Services. Não inclua o contexto no URL. Por exemplo, o URL de destino pode ser
        /applications/doc1.html
        .
      • Defina realms, regras e diretivas para proteger os recursos de destino. Os realms devem conter, ao menos, o valor /affwebservices/ no filtro do recurso.
      • Instale um aplicativo Java ou JSP personalizado no servidor que está atendendo o aplicativo Federation Web Services. O Web Agent Option Pack ou o SPS federation gateway instala o Federation Web Services.
        A tecnologia de servlet Java permite que os aplicativos transmitam informações entre solicitações de dois recursos usando o método setAttribute da interface ServletRequest.
        O serviço que utiliza os assertions envia os atributos de usuário para o aplicativo de destino antes de redirecionar o usuário para o destino. O serviço envia os atributos criando um objeto java.util.HashMap. O atributo que contém os atributos HashMap de SAML é “Netegrity.AttributeInfo”.
        O serviço que utiliza os assertions transmite outros dois atributos Java.lang.String para o aplicativo personalizado:
        • O atributo Netegrity.smSessionID representa a ID da sessão.
        • O atributo Netegrity.userDN representa o DN de usuário.
      O aplicativo de destino lê esses objetos da solicitação HTTP e usa os dados encontrados nos objetos hashmap.
  • Destino
    Especifica o URL do aplicativo de destino no provedor de serviço. O valor inserido aqui se torna o recurso de destino padrão. Esse URL deve conter um nome de domínio totalmente qualificado, a menos que você selecione Redirecionamento para o servidor como o modo de redirecionamento. Para Redirecionamento para o servidor, o URL de destino deve ser
    relativo
    ao contexto do servlet que está consumindo a asserção. O contexto é 
    /affwebservices/public/
    . Não inclua o contexto no URL. Por exemplo, o URL de destino pode ser
     /applications/doc1.html
    .
    Se um proxy estiver situado em frente do servidor com o recurso de destino, insira o URL para o host de proxy. O proxy lida com todas as solicitações de federação localmente. O host de proxy pode ser qualquer sistema situado na frente do servidor de destino. O host de proxy também pode ser o próprio
    Single Sign-On
    , contanto que ele esteja sendo acessado diretamente da internet. Por fim, ao operar com um proxy, o URL especificado como o destino deve passar pelo
    Single Sign-On
    . Por exemplo, se o URL base for fed.demo.com e o recurso de servidor de back-end for mytarget/target.jsp, o valor desse campo será http://fed.demo.com:5555/mytarget/target.jsp.
    Para o SAML 2.0, você poderá deixar esse campo em branco se substituí-lo pelo parâmetro de consulta RelayState. O parâmetro de consulta RelayState pode fazer parte do URL que dispara o logon único. Para permitir essa substituição, marque a caixa de seleção O estado de retransmissão substitui o destino.
  • Tempo limite ocioso
    Determina a quantidade de tempo que uma sessão de usuário autorizada pode ficar inativa antes que o agente a encerre. Se você estiver preocupado com os usuários que deixam suas estações de trabalho depois de acessar um recurso protegido, defina o tempo limite de ociosidade como um período mais curto. Se o tempo limite da sessão expirar, os usuários deverão se autenticar novamente antes de acessar os recursos.
    Essa configuração é ativada por padrão. Para especificar nenhum limite de tempo de ociosidade de sessão, desmarque a caixa de seleção. O tempo limite de ociosidade de sessão padrão é uma hora.
    Observação
    a sessão realmente expira dentro de um determinado período de manutenção após o valor de tempo limite de ociosidade especificado. O número de segundos especificado na chave do Registro a seguir determina o período de tempo:
    HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\
    CA Single Sign-on
    \CurrentVersion\SessionServer\MaintenancePeriod
    Por exemplo, você define o tempo limite de ociosidade como 10 minutos. Também define o Registro para MaintenancePeriod como o valor padrão. O período mais longo antes do tempo limite de uma sessão ser tingido devido à inatividade é 11 minutos (tempo limite + período de manutenção).
    Para usar esse recurso com o esquema de autenticação Básico, o agente web deve ser configurado para exigir cookies.
    Considere as seguintes questões:
    • Para sessões persistentes, ative a opção Tempo limite ocioso e defina-a com um valor maior do que o de Período de validação.
    • É possível ignorar essa configuração usando o atributo de resposta WebAgent-OnAuthAccept-Session-Idle-Timeout. Um valor igual a zero indica que a sessão não será encerrada devido à inatividade.
    Padrão
    : 60 segundos
    Horas
    Especifica o número de horas para o período de tempo limite de ociosidade.
    Minutos
    Especifica o número de minutos para o período de tempo limite de ociosidade.
    Tempo limite máximo
    Determina a quantidade máxima de tempo que uma sessão de usuário pode ficar ativa antes que o agente solicite ao usuário para se autenticar novamente.
    Essa configuração é ativada por padrão. Para especificar nenhum período máximo de sessão, desmarque a caixa de seleção. O período máximo de sessão padrão é duas horas.
    • Horas
      Especifica o número de horas para o período máximo de sessão.
    • Minutos
      Especifica o número de minutos para o período máximo de sessão.
    Para usar esse recurso com o esquema de autenticação Básico, configure o agente web para exigir cookies.
    Observação:
    é possível ignorar essa configuração usando o atributo de resposta WebAgent-OnAuthAccept-Session-Max-Timeout.
  • O estado de retransmissão substitui o destino (apenas para SAML 2.0)
    (Opcional) Substitui o valor do campo de destino pelo valor do parâmetro de consulta de estado de retransmissão na solicitação que iniciar o logon único. Ao selecionar esta opção, você terá maior controle sobre o destino, pois o uso do parâmetro de consulta de estado de retransmissão permite definir o destino dinamicamente.
  • Validar domínio do URL de destino
    (Apenas para SAML 2.0) Instrui o Servidor de políticas a comparar o valor do campo Destino ou o destino especificado no parâmetro de consulta RelayState com o parâmetro ValidFedTargetDomain no Objeto de configuração do agente. Essa configuração ajuda a garantir que o provedor de serviço permite o acesso ao domínio de destino solicitado.
  • Persistir variáveis da sessão de autenticação
    Permite que as informações de um assertion sejam armazenadas no repositório de sessões e gravadas no contexto da sessão. O armazenamento de informações de assertion no repositório de sessões permite que você use essas informações para funções, como respostas ativas e expressões de diretivas. Se você marcar essa caixa de seleção, as informações de assertion armazenadas incluirão os valores de NameID, NameIDFormat, ProviderID e AuthnContext.
    Essa configuração é diferente da opção Persistir atributos do modo de redirecionamento para o aplicativo de destino. Ao manter variáveis de sessão de autenticação, as informações são disponibilizadas para uso como mais do que apenas cabeçalhos HTTP.
    Importante:
    para ver essa caixa de seleção, ative o repositório da sessões usando o Console de gerenciamento do servidor de políticas. Além disso, marque a caixa de seleção Usar sessão persistente nas configurações de SSO das configurações de parceria.
  • O parâmetro da consulta substitui o destino padrão (apenas para SAML 1.1)
    (Opcional) Substitui o valor do campo Destino pelo valor do parâmetro de consulta Destino na solicitação que inicia o logon único. Ao selecionar esta opção, você terá maior controle sobre o destino, pois o uso do parâmetro de consulta permite definir o destino dinamicamente.
  • Período de validade do cookie
    Indica o período de tempo pelo qual o cookie de formato aberto é válido. O período de validade é colocado no cookie de forma que o aplicativo de destino possa verificar se o cookie é válido antes de ele utilizar os dados. Você pode definir esse valor para o cookie de formato aberto e para modos de redirecionamento de cabeçalhos HTTP (os cabeçalhos HTTP usam o cookie de formato aberto). Para o cookie de formato aberto, o aplicativo determina o que deve ser feito quando o cookie expirar. Para os cabeçalhos HTTP, o
    CA Single Sign-on
    interrompe o envio do cookie expirado.
    Insira um horário em horas, minutos e segundos. O valor 00:00:00 indica que o cookie nunca expira.
Configuração do aplicativo de destino (OAuth)
Na seção Aplicativo de destino, é possível especificar o aplicativo de destino e a maneira como os usuários são direcionados para o aplicativo de destino.
  • Modo de redirecionamento
    Especifica o método usado pelo provedor de serviço para redirecionar o usuário para o recurso de destino. Estes são os possíveis valores:
    • Sem dados
      Especifica que o usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados.
    • Dados de cookie
      Especifica que o usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de sessão e dados de cookie adicionais configurados no serviço de confirmação. Se você selecionar esta opção, a seguinte opção estará disponível:
      • Dados do cookie do atributo de codificação de URL
        Indica que o atributo enviado no cookie é codificado em URL. A designação de codificação por URL é necessária porque os caracteres no URL atendem a uma finalidade exclusiva que não é o padrão para um URL. Essa configuração é válida apenas com o modo de redirecionamento Dados de cookie. Se os dados do cookie contiverem declarações de vários valores, será necessário selecionar esta opção.
        Se você especificar qualquer caractere especial na tabela de atributos do aplicativo, selecione essa opção. Por exemplo, selecione essa opção configuração para todos os atributos com caracteres do idioma japonês. Caracteres especiais podem ser adicionados a partir da lista suspensa ou inseridos manualmente. Além disso, o aplicativo de destino deve decodificar o nome e o valor do atributo do aplicativo recebido.
    • Cookie de formato aberto
      Especifica que o usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de formato aberto, mas sem outros dados. O aplicativo do destinatário descriptografa o cookie criptografado para obter as informações do usuário.
      Se o provedor de serviço receber uma declaração com vários valores de atributo, ele passará todos os valores ao aplicativo de destino.
    • Postagem de cookie de formato aberto
      O usuário é redirecionado para o aplicativo de destino por um redirecionamento HTTP 302 com um cookie de formato aberto, mas os dados são enviados em uma solicitação HTTP-POST. Se você estiver preocupado que dados podem se perder devido à limitação de tamanho de dados de cookie, selecione essa opção.
    Se você selecionar a opção de cookie de formato aberto, a UI exibirá os seguintes campos adicionais:
  • Nome do cookie de formato aberto
    Especifica o nome do cookie de formato aberto.
  • Transformação de criptografia
    Indica o algoritmo de criptografia a ser usado para criptografar o cookie de formato aberto.
    Se você selecionar um dos algoritmos compatíveis com FIPS (algoritmos AES), o sistema de destino deverá usar um SDK do sistema para utilizar o cookie. O SDK deve estar no mesmo servidor que o aplicativo de destino.
    Se você estiver usando o SDK do .NET para utilizar o cookie, use o algoritmo de criptografia AES128/CBC/PKCS5Padding.
  • Senha de criptografia
    Indica a senha usada para criptografar o cookie.
  • Confirmar senha
    Confirma a entrada de senha de criptografia.
  • Ativar HMAC
    Indica que um HMAC (Hash Message Authentication Code - Código de Autenticação de Mensagem de Hash) é gerado usando a senha de criptografia fornecida nessa caixa de diálogo.
    Os MACs (Message Authentication Codes - Códigos de Autenticação de Mensagem) podem verificar a integridade das informações enviadas entre duas partes. As duas partes compartilham uma chave secreta para o cálculo e a verificação de valores de autenticação de mensagem. Um HMAC é um mecanismo de MAC que se baseia em funções de hash criptográfico. Os HMACs têm uma entrada de mensagem e uma chave secreta que são conhecidas apenas pelo originador da mensagem e pelo receptor pretendido.
    Se você marcar a caixa de seleção Ativar HMAC, o sistema gerará um valor de HMAC para seu cookie de formato aberto. O valor de HMAC é precedido ao valor do cookie de formato aberto e, em seguida, criptografa toda a sequência de caracteres. O sistema coloca a sequência de caracteres criptografada no cookie de formato aberto que, em seguida, é transmitido para o aplicativo de destino.
  • Ativar cookie entre aspas
    Especifica que o valor do cookie de formato aberto está entre aspas duplas. Essa especificação permite o processamento do cookie em casos em que caracteres sem suporte são incluídos no valor do cookie.
  • Período de validade do cookie
    Indica o período de tempo pelo qual o cookie de formato aberto é válido. O período de validade é colocado no cookie de forma que o aplicativo de destino possa verificar se o cookie é válido antes de ele utilizar os dados. O aplicativo determina o que fazer quando o cookie expira.
    Insira um horário em horas, minutos e segundos.
  • Cabeçalhos HTTP (apenas para modo de proxy)
    O usuário é redirecionado para o aplicativo de destino com cabeçalhos HTTP, mas sem outros dados.
  • Persistir com as declarações para o armazenamento de sessão
    O usuário é redirecionado por meio de um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados. Esse modo também instrui o servidor de políticas a armazenar os atributos extraídos de um assertion no repositório de sessões. Em seguida, o sistema pode fornecer os atributos de variáveis do cabeçalho HTTP.
    Observação:
    você pode selecionar PersistClaims e o os atributos contém do assertion são deixados em branco. Nesse caso, um valor NULL é gravado no repositório de sessões. Esse valor funciona como um espaço reservado para o atributo vazio e é transmitido para qualquer aplicativo que esteja usando o atributo.
  • Destino
    Especifica o URL do aplicativo de destino no provedor de serviço. O valor inserido aqui se torna o recurso de destino padrão. O URL deve conter um nome de domínio totalmente qualificado.
    Se um proxy estiver situado em frente do servidor com o recurso de destino, insira o URL para o host de proxy. O proxy lida com todas as solicitações de federação localmente. O host de proxy pode ser qualquer sistema situado na frente do servidor de destino. O host do proxy também pode ser o próprio sistema, contanto que esse sistema esteja sendo acessado diretamente da internet. Por fim, ao operar com um proxy, o URL especificado como o destino deve passar pelo sistema de federação. Por exemplo, se o URL base for fed.demo.com e o recurso de servidor de back-end for mytarget/target.jsp, o valor desse campo será http://fed.demo.com:5555/mytarget/target.jsp.
    Deixe esse campo em branco se o substituir pelo parâmetro de consulta RelayState. O parâmetro de consulta RelayState pode fazer parte do URL que dispara o logon único. Para permitir essa substituição, marque a caixa de seleção O estado de retransmissão substitui o destino.
  • Tempo limite ocioso
    Determina a quantidade de tempo que uma sessão de usuário autorizada pode ficar inativa antes que o sistema de federação a encerre. Se você estiver preocupado com os usuários que deixam suas estações de trabalho depois de acessar um recurso protegido, defina o tempo limite de ociosidade como um período mais curto. Se o tempo limite da sessão expirar, os usuários deverão se autenticar novamente antes de acessar os recursos.
    Essa configuração é ativada por padrão. Para especificar nenhum limite de tempo de ociosidade de sessão, desmarque a caixa de seleção. O tempo limite de ociosidade de sessão padrão é uma hora.
    Observação:
    para sessões persistentes, ative a opção Tempo limite de ociosidade e defina-a com um valor maior do que o de Período de validação.
    Padrão
    : 1 hora
    Horas
    Especifica o número de horas para o período de tempo limite de ociosidade.
    Minutos
    Especifica o número de minutos para o período de tempo limite de ociosidade.
    Tempo limite máximo
    Determina a quantidade máxima de tempo que uma sessão de usuário pode ficar ativa antes que o sistema de federação solicite ao usuário para se autenticar novamente.
    Essa configuração é ativada por padrão. Para especificar nenhum período máximo de sessão, desmarque a caixa de seleção.
    Padrão
    : 2 horas
    • Horas
      Especifica o número de horas para o período máximo de sessão.
    • Minutos
      Especifica o número de minutos para o período máximo de sessão.
  • O estado de retransmissão substitui o destino
    (Opcional) Substitui o valor do campo de destino pelo valor do parâmetro de consulta de estado de retransmissão na solicitação que iniciar o logon único. Ao selecionar esta opção, você terá maior controle sobre o destino, pois o uso do parâmetro de consulta de estado de retransmissão permite definir o destino dinamicamente.
  • Validar domínio do URL de destino
    Instrui o sistema de federação a comparar o valor do campo Destino ou o destino especificado no parâmetro de consulta RelayState com o parâmetro ValidFedTargetDomain no objeto de configuração do agente. Essa configuração ajuda a garantir que o provedor de serviço permite o acesso ao domínio de destino solicitado.
Mapear para atributos do aplicativo (SAML, WSFED)
A seção Mapear para atributos do aplicativo determina como mapear atributos do assertion para atributos usados pelo aplicativo de destino.
  • Mapa para atributos de aplicativo
    Indica que o mapeamento de atributo está ativado. Se você marcar a caixa de seleção Ativar atributos do aplicativo, a tabela de definição de atributos do aplicativo será exibida. Essa tabela permite especificar como os atributos do aplicativo são mapeados para os atributos do assertion.
    As seguintes colunas na tabela exigem entradas:
    Atributo do aplicativo
    Lista o atributo usado pelo aplicativo de destino. Por padrão, o nome do atributo do aplicativo é igual ao nome do atributo do assertion. Você pode alterar o nome de atributo do aplicativo para qualquer nome exigido pelo aplicativo.
    Atributos do assertion
    Especifica os atributos do assertion que você deseja usar como base para o mapeamento de um atributo de aplicativo.
    Se você selecionar o botão <<, um campo Anexar será exibido. Na lista suspensa Anexar, selecione os atributos de assertion e os caracteres especiais disponíveis para incluir na regra de mapeamento.
Mapear para atributos do aplicativo (OAuth)
A seção Mapear para atributos do aplicativo determina como mapear atributos de declaração para atributos usados pelo aplicativo de destino.
  • Mapa para atributos de aplicativo
    Indica que o mapeamento de atributo está ativado. Se você selecionar a caixa de seleção Ativar mapeamento de atributo, a tabela de definições de atributo do aplicativo será exibida. Essa tabela permite especificar como os atributos do aplicativo são mapeados para os atributos do assertion.
    As seguintes colunas na tabela exigem entradas:
    Atributo do aplicativo
    Lista o atributo usado pelo aplicativo de destino. Por padrão, o nome do atributo do aplicativo é igual ao nome do atributo do assertion. Você pode alterar o nome de atributo do aplicativo para qualquer nome exigido pelo aplicativo.
    Atributos de declaração
    Especifica os atributos das reivindicações que você deseja usar como base para o mapeamento de um atributo de aplicativo.
    Se você selecionar o botão <<, um campo Anexar será exibido. Na lista suspensa Anexar, é possível selecionar caracteres especiais para incluir na regra de mapeamento.
Provisionamento de usuários (SAML, WSFED)
A seção Provisionamento de usuário permite determinar como um aplicativo de provisionamento de terceiros estabelece contas de usuário.
  • Provisionamento de usuários
    Essa seção permite determinar como funciona o provisionamento de usuários.
  • Tipo de provisionamento
    Indica se um aplicativo de provisionamento remoto estabelece contas de usuário. Se o servidor de políticas estiver trabalhando com um aplicativo de provisionamento, selecione Remoto.
    Padrão:
    Nenhum
    Opções
    : Nenhum, Remoto
    Observação
    é possível selecionar Remoto como o tipo de provisionamento. Nesse caso, configure uma opção de entrega que transmita os dados do assertion para o aplicativo de provisionamento.
  • Opção de entrega
    (Apenas para provisionamento remoto) Define como o navegador é redirecionado com os dados do assertion para o aplicativo de provisionamento. Os dados do assertion podem passar um cookie ou cabeçalhos HTTP.
    Opções:
    • Cookie de formato aberto
      Fornece informações de assertion do SAML em um cookie de formato aberto. Se um cookie de formato aberto for usado, o aplicativo de provisionamento poderá ler o cookie sem usar um SDK. Se o aplicativo de provisionamento usar .NET, SDK do .NET poderá ser instalado no servidor de provisionamento e usado para ler o cookie de formato aberto.
    • Postagem de cookie de formato aberto
      Fornece as informações de assertion em um cookie de formato aberto, mas os dados são enviados em uma solicitação HTTP-POST. Se você estiver preocupado que dados podem se perder devido à limitação de tamanho de dados de cookie, selecione essa opção.
    • Cabeçalhos HTTP
      O servidor de políticas envia dados do assertion em cabeçalhos HTTP.
  • URL do servidor de provisionamento
    Identifica o URL do servidor de terceiros que hospeda o aplicativo de provisionamento.
    Valor:
    um URL válido
Se você selecionar a opção de cookie de formato aberto, preencha os seguintes campos adicionais:
Nome do cookie de formato aberto
Especifica o nome do cookie de formato aberto.
  • Transformação de criptografia
    Indica o algoritmo de criptografia que criptografa o cookie de formato aberto.
  • Senha de criptografia
    Indica a senha usada para criptografar o cookie. Os campos Senha de criptografia e Confirmar senha são obrigatórios para o cookie de formato aberto, mas os parâmetros são opcionais para o cookie herdado.
    Importante: se fornecer uma senha para o cookie legado, use o mesmo valor para o SDK do Java do
    CA SiteMinder® Federation
    . O SDK necessita da senha para descriptografar o cookie. Os valores são compartilhados em uma comunicação fora de banda.
  • Confirmar senha
    Confirma a entrada de senha de criptografia.
  • Ativar HMAC
    Indica que o sistema gera um HMAC (Hash Message Authentication Code – Código de Autenticação de Mensagem de Hash) usando a senha de criptografia nessa caixa de diálogo.
    Os MACs (Message Authentication Codes - Códigos de Autenticação de Mensagem) podem verificar a integridade das informações enviadas entre duas partes. As duas partes compartilham uma chave secreta para o cálculo e a verificação dos valores de autenticação da mensagem. Um HMAC é um mecanismo de MAC que se baseia em funções de hash criptográfico. Os HMACs têm uma entrada de mensagem e uma chave secreta que são conhecidas apenas pelo originador da mensagem e pelo receptor pretendido.
    Se você marcar a caixa de seleção Ativar HMAC, o sistema gerará um valor de HMAC para seu cookie de formato aberto. O valor de HMAC é precedido ao valor do cookie de formato aberto e, em seguida, criptografa toda a sequência de caracteres. O
    CA Single Sign-on
    coloca a sequência de caracteres criptografada no cookie de formato aberto que, em seguida, é transmitido para o aplicativo de destino.
  • Ativar cookie entre aspas
    Especifica que o valor do cookie de formato aberto está entre aspas duplas. Essa especificação permite o processamento do cookie em casos em que caracteres sem suporte são incluídos no valor do cookie.
Período de validade do cookie
Indica o período de tempo pelo qual o cookie de formato aberto é válido. O período de validade é colocado no cookie de forma que o aplicativo de destino possa verificar se o cookie é válido antes de ele utilizar os dados. Você pode definir esse valor para o cookie de formato aberto e para modos de redirecionamento de cabeçalhos HTTP (os cabeçalhos HTTP usam o cookie de formato aberto). Para o cookie de formato aberto, o aplicativo determina o que deve ser feito quando o cookie expirar. Para os cabeçalhos HTTP, o agente interromperá o envio do cookie expirado.
Insira um horário em horas, minutos e segundos.
Provisionamento de usuários (OAuth)
A seção Provisionamento de usuário permite determinar como um aplicativo de provisionamento de terceiros estabelece contas de usuário.
    • Tipo de provisionamento
      Indica se um aplicativo de provisionamento remoto estabelece contas de usuário.
    • Opção de entrega
      Define como um navegador com dados de usuário é redirecionado para o aplicativo de provisionamento. O sistema de federação pode transmitir os dados do usuário usando um cookie ou cabeçalhos HTTP. Estas são as possíveis opções:
      • Cookie de formato aberto
        Fornece informações de usuário do OAuth em um cookie de formato aberto. Se um cookie de formato aberto for usado, o aplicativo de provisionamento poderá ler o cookie sem usar um SDK. Se o aplicativo de provisionamento usar .NET, instale o SDK do .NET no servidor de provisionamento para que seja usado para ler o cookie de formato aberto.
      • Postagem de cookie de formato aberto
        Fornece as informações do usuário do OAuth em um cookie de formato aberto, mas os dados são enviados em uma solicitação HTTP-POST. Se você estiver preocupado que dados podem se perder devido à limitação de tamanho de dados de cookie, selecione essa opção.
      Se você selecionar a opção de cookie de formato aberto, preencha os seguintes campos adicionais:
    • Nome do cookie de formato aberto
      Especifica o nome do cookie de formato aberto.
    • Transformação de criptografia
      Indica o algoritmo de criptografia a ser usado para criptografar o cookie de formato aberto.
    • Senha de criptografia e Confirmar senha
      Indica a senha usada para criptografar o cookie. Os campos Senha de criptografia e Confirmar senha são necessários para o cookie de formato aberto.
    • Ativar HMAC
      Indica que um HMAC (Hash Message Authentication Code - Código de Autenticação de Mensagem de Hash) é gerado usando a senha de criptografia fornecida nessa caixa de diálogo.
      Os MACs (Message Authentication Codes - Códigos de Autenticação de Mensagem) podem verificar a integridade das informações enviadas entre duas partes. As duas partes compartilham uma chave secreta para o cálculo e a verificação de valores de autenticação de mensagem. Um HMAC é um mecanismo de MAC que se baseia em funções de hash criptográfico. Os HMACs têm uma entrada de mensagem e uma chave secreta que são conhecidas apenas pelo originador da mensagem e pelo receptor pretendido.
      Se você marcar a caixa de seleção Ativar HMAC, o sistema gerará um valor de HMAC para seu cookie de formato aberto. O valor de HMAC é precedido ao valor do cookie de formato aberto e, em seguida, criptografa toda a sequência de caracteres. O sistema de federação coloca a sequência de caracteres criptografada no cookie de formato aberto que, em seguida, é transmitido para o aplicativo de destino.
    • Ativar cookie entre aspas
      Especifica que o valor do cookie de formato aberto está entre aspas duplas. Essa especificação permite o processamento do cookie em casos em que caracteres sem suporte são incluídos no valor do cookie.
Cabeçalhos HTTP (apenas para modo de proxy)
  • Se o sistema estiver operando no modo de proxy, passará os dados de assertion em cabeçalhos HTTP.
  • URL do servidor de provisionamento
    Identifica o URL do servidor de terceiros que hospeda o aplicativo de provisionamento.
  • Período de validade do cookie
    Indica o período de tempo pelo qual o cookie de formato aberto é válido. O período de validade é colocado no cookie de forma que o aplicativo de destino possa verificar se o cookie é válido antes de ele utilizar os dados. É possível configurar esse valor para os modos de redirecionamento de cookie de formato aberto e de cabeçalhos HTTP. Cabeçalhos HTTP usam o cookie de formato aberto. Para o cookie de formato aberto, o aplicativo determina o que deve ser feito quando o cookie expirar. Para os cabeçalhos HTTP, o sistema interromperá o envio do cookie expirado.
URLs de redirecionamento de status (SAML, WSFED)
A seção URL de redirecionamento de status permite determinar como o
CA Single Sign-on
redireciona um usuário quando a autenticação falha.
A autenticação com base em assertion pode falhar no site que utiliza os assertions. Se a autenticação falhar, o sistema de federação fornecerá a funcionalidade para direcionar o usuário a diferentes aplicativos (URLs) para processamento adicional. Por exemplo, quando ocorre uma falha na desambiguação de usuários, você pode configurar o
CA Single Sign-on
para enviar o usuário para um sistema de provisionamento. O sistema de provisionamento pode criar uma conta de usuário que se baseie nas informações encontradas no assertion do SAML.
Você pode configurar uma ou mais dessas opções. Se ocorrer a condição que causou a falha, o
CA Single Sign-on
redirecionará o usuário para o URL configurado.
Observação:
o redirecionamento de erros ocorre somente quando o sistema pode analisar a solicitação com êxito e obter as informações necessárias para identificar a autoridade de confirmação e o provedor de serviço.
As configurações são:
  • Usuário não encontrado
    Identifica o URL para o qual o sistema redireciona o usuário de acordo com uma das seguintes condições:
    • A mensagem de logon único não possui uma ID de logon.
    • O diretório de usuários não contém a ID de logon com a sequência de caracteres de pesquisa definida.
  • Mensagem de SSO inválida
    Identifica o URL para o qual o
    CA Single Sign-on
    redireciona o usuário de acordo com uma das seguintes condições:
    • A mensagem de logon único é inválida, com base nas regras especificadas nos esquemas de SAML.
    • O destinatário exige um assertion criptografado, mas a mensagem de logon único não contém um assertion criptografado.
  • Credencial de usuário (mensagem SSO) não aceita
    Identifica o URL para o qual o
    CA Single Sign-on
    redireciona o usuário na maioria das condições de erro. As condições de erro consideradas exceções são quando um usuário não é encontrado ou a mensagem de logon único é inválida. A asserção pode ser válida, mas o
    CA Single Sign-on
    não aceita a mensagem devido a vários motivos, como:
    • Falha na validação da assinatura digital de XML
    • (SAML 2.0) Falha na operação de descriptografia de XML
    • Falha na validação de XML de condições, como uma mensagem expirada ou uma incompatibilidade de público.
    • Nenhum dos assertions na mensagem de SSO contém uma instrução de autenticação.
  • 302 Sem dados (padrão)
    Redireciona o usuário por meio de um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados.
  • HTTP Post
    Redireciona o usuário usando o protocolo HTTP POST.
URLs de redirecionamento do SAML 2.0 adicionais
Para o provedor de serviços do SAML 2.0, você também pode especificar URLs de redirecionamento para os erros HTTP 500, 400 e 405. Selecione as opções de redirecionamento que você deseja ativar e insira um URL associado. Estas opções são:
  • Ativar redirecionamento de erro do servidor
    URL de erro do servidor:
    especifica o URL para o qual o usuário é redirecionado quando ocorre um erro de servidor HTTP 500. Um usuário pode receber um erro 500 devido a uma condição inesperada que impede o servidor web de atender à solicitação do cliente. Se esse tipo de erro ocorrer, o usuário será enviado para o URL especificado para processamento adicional.
    Exemplo: http://www.redirectmachine.com/error_pages/server_error.html
  • Ativar redirecionamento de solicitação inválida
    URL de solicitação inválida:
    especifica o URL para o qual o usuário é redirecionado quando ocorre um erro do tipo HTTP 400 - Solicitação incorreta ou 405 - Método não permitido. Um usuário pode receber um erro 400 devido a uma solicitação malformada. O usuário também pode receber um erro 405 porque o servidor web não permite a execução de um método ou uma ação específica. Se esses tipos de erros ocorrerem, o usuário será enviado para o URL especificado para processamento adicional.
    Exemplo: http://www.redirectmachine.com/error_pages/invalidreq_error.html
  • Ativar redirecionamento de acesso não autorizado
    URL de acesso não autorizado
    : especifica o URL para o qual o usuário é redirecionado quando ocorre um erro de proibição HTTP 403. Um erro 403 pode ocorrer devido ao URL em uma solicitação apontar para o destino incorreto, como um diretório, em vez de um arquivo. Se esse erro ocorrer, o usuário será enviado para o URL especificado para processamento adicional.
    Exemplo: http://www.redirectmachine.com/error_pages/unauthorized_error.html
URLs de redirecionamento de status (OAuth)
A seção URL de redirecionamento de status permite determinar como o
CA Single Sign-on
redireciona um usuário quando a autenticação falha.
A autenticação com base em assertion pode falhar no site que utiliza os assertions. Se a autenticação falhar, o Federation Manager fornecerá a funcionalidade para direcionar o usuário para diferentes aplicativos (URLs) para processamento adicional. Por exemplo, quando ocorre uma falha na desambiguação de usuários, você pode configurar o
CA Single Sign-on
para enviar o usuário para um sistema de provisionamento. O sistema de provisionamento pode criar uma conta de usuário que se baseie nas informações encontradas no assertion do SAML.
Você pode configurar uma ou mais dessas opções. Se ocorrer a condição que causou a falha, o
CA Single Sign-on
redirecionará o usuário para o URL configurado.
As configurações são:
  • Remote Server Failure
    • OAuth 2.0
      Identifica o URL para o qual o sistema direciona o usuário sob os seguintes erros especificados pelo OAuth 2.0:
      • O servidor de autorização encontrou uma condição inesperada que o impede de atender à solicitação do usuário.
      • O servidor de autorização do usuário não pode processar a solicitação do usuário devido a uma sobrecarga temporária ou à manutenção do servidor.
    • OAuth 1.0a
      Identifica o URL para o qual o sistema direciona o usuário quando o servidor de autorização envia um erro HTTP 500.
  • Mensagem de solicitação inválida
    • OAuth 2.0
      Identifica o URL para o qual o sistema direciona o usuário sob os seguintes erros especificados pelo OAuth 2.0:
      • A solicitação do usuário está com a sintaxe errada.
      • O escopo solicitado pelo usuário é inválido, desconhecido ou malformado.
      • O servidor de autorização não oferece suporte à obtenção de um código de autorização no método especificado.
    • OAuth 1.0a
      Identifica o URL para o qual o sistema direciona o usuário quando o servidor de autorização envia um erro HTTP 400 ou 404.
  • Credencial de usuário não aceita
    • OAuth 2.0
      Identifica o URL para o qual o CA
      CA Single Sign-on
      Federation Standalone direciona o usuário se ocorrerem os seguintes erros especificados pelo OAuth 2.0:
      • O cliente não está autorizado a solicitar um código de autorização usando o método especificado.
      • O servidor de autorização recusou a solicitação.
    • OAuth 1.0a
      Identifica o URL para o qual o sistema direciona o usuário quando o servidor de autorização envia um erro HTTP 401 ou 403.
  • 302 Sem dados (padrão)
    Redireciona o usuário por meio de um redirecionamento HTTP 302 com um cookie de sessão, mas sem outros dados.
  • HTTP Post
    Redireciona o usuário usando o protocolo HTTP POST.