Skip to main content

Pedido ao provedor

Você pode configurar os provedores em uma ordem de preferência que permita uma cascata de autenticação em que cada provedor é consultado em sequência até que o usuário esteja conectado ou a autenticação falhe. Você deseja definir a ordem do provedor a usar para failover se uma das origens do provedor estiver com problemas. Por exemplo, se você tiver três provedores LDAP e o provedor padrão estiver Ativo, a estrutura de autenticação consulta o primeiro provedor e, se o usuário não for encontrado, consulta cada provedor até que o usuário seja encontrado e a autenticação seja bem-sucedida ou falhe. Se o usuário não for encontrado em nenhum provedor, a autenticação falhará.

Defina a ordem dos provedores

Use as etapas a seguir para definir a Ordem dos provedores.

  1. No Painel do administrador, na seção Integrações, clique em Autenticação.

  2. Na página Autenticação, clique em Ordem dos provedores.

  3. Usando a função arrastar e soltar, pressione e arraste os provedores em ordem descendente, do primeiro ao último, ou use a Ferramenta de reordenação acessível do teclado para fazer ajustes na ordem.

  4. Outra opção é definir Continuar em caso de erro como Sim. O padrão é Não. Essa opção indica se os provedores subsequentes devem ser processados se um anterior falhar devido a um erro. Essa opção é global para a cadeia de provedores.

    Nota

    Continuar em caso de erro só é aplicável se houver mais de um provedor Ativo na lista.

  5. Você pode basear os Provedores de Autenticação em dois tipos de Modo de Autenticação: REDIRECT e USER_PASS.

    • Provedores do tipo REDIRECT, como o CAS, distribuem a autenticação para a fonte de autenticação remota. Esses provedores não estão relacionados na Ordem dos provedores uma vez que são considerados a fonte autorizada para autenticação e gerenciam suas próprias falhas de autenticação.

    • Provedores do tipo USER_PASS, como o padrão do Learn e LDAP, consultam a fonte de autenticação que retorna um dos quatros estados. Isso permite o encadeamento do provedor.

      • Acesso bem-sucedido.

      • Usuário não encontrado (a estrutura tenta o próximo provedor).

      • Usuário encontrado, mas senha inválida (a estrutura anula o acesso).

      • Algo falhou (a estrutura só continua se Continuar em caso de erro estiver definido).

O que é Continuar em caso de erro?

Ao encadear provedores de autenticação em conjunto, é possível definir se a falha de um provedor anterior em autenticar um usuário deve forçar a tentativa de autenticação no próximo provedor de autenticação. Uma compreensão das possíveis condições de erro e resultados decorrentes é útil para uma fazer triagem dos problemas de acesso.

Nota

Não é possível fornecer uma lista abrangente de possíveis causas de falha em uma arquitetura de autenticação, mas elas podem ser classificadas em três grupos – 1) Disponibilidade do serviço: falhas que são o resultado da indisponibilidade do serviço designado pelo provedor de autenticação; 2) Serviço de autenticação: o usuário não ser encontrado no serviço designado pelo provedor de autenticação ou uma senha de usuário incorreta; 3) Falta de conta no Blackboard.

Exemplos de Continuar em caso de erro que invocarão o próximo provedor de autenticação ativo:

  • Disponibilidade do serviço e usuário não encontrados no diretório de nomes do provedor designado.

  • Erro de conexão no provedor de autenticação falha. Por exemplo: a Blackboard pode não conseguir entrar em contato com o servidor LDAP configurado.

  • Nome de usuário não encontrado no diretório de nomes do provedor de autenticação. Por exemplo: o usuário não é encontrado no diretório LDAP configurado.

Exemplos de Falha de autenticação de Continuar em caso de erro que não invocarão o próximo provedor de autenticação ativo:

  • Provedor de autenticação detecta o usuário, mas a senha fornecida é inválida.

  • A conexão com o provedor de autenticação e a autenticação do usuário é bem-sucedida, mas o nome de usuário não foi encontrado no Blackboard. Por exemplo: o usuário foi autenticado com êxito via LDAP, mas não tem uma conta de usuário do Blackboard.

  • A conexão com o provedor de autenticação é bem-sucedida e o usuário é encontrado, mas foi fornecida uma senha incorreta ao provedor de autenticação, resultando na não autenticação do usuário. O usuário pode ou não ter uma conta de usuário da Blackboard. Por exemplo: o usuário insere um nome de usuário correto, mas uma senha inválida para sua conta LDAP – o LDAP encontra o usuário, mas não pode autenticar.