Pedido ao provedor
Note
Esta documentação foi traduzida utilizando tradução automática assistida por IA. As traduções são fornecidas "no estado em que se encontram", sem qualquer garantia quanto à sua precisão. A versão em inglês deste conteúdo é a fonte oficial e de referência.
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.
No Painel do administrador, na seção Integrações, clique em Autenticação.
Na página Autenticação, clique em Ordem dos provedores.
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.
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.
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.