Sobre Políticas de Provedor de Identidades
Sobre políticas do provedor de identidades.
Uma política do provedor de identidades permite que você defina quais provedores de identidades estão visíveis na página Acessar quando um usuário estiver acessando um aplicativo específico ou tentando acessar recursos protegidos por um domínio de identidades. As políticas do provedor de identidades também podem decidir se usuários se autenticam em um domínio por meio de provedores de identidades ou de um fator local de autenticação.
Os seguintes tipos de provedores de identidade estão disponíveis em um domínio de identidades:
-
Provedor de identidade SAML: Esse tipo de provedor de identidade suporta o padrão SAML 2.0 (Security Assertion Markup Language 2.0). Use um provedor de identidades SAML quando quiser estabelecer a confiança entre um provedor de identidades compatível por SAML, como os Serviços de Federação do Active Directory, para que usuários de uma organização possam acessar recursos protegidos pelo domínio.
Se você quiser que os usuários sejam redirecionados automaticamente a um provedor específico de identidades SAML para que possam acessar um aplicativo, certifique-se de que a política do provedor associado ao aplicativo tenha somente o provedor SAML designado a ele. Se muitos provedores de identidades forem designados à política do provedor de identidades, os usuários deverão selecionar um dos provedores de identidades na página Acessar.
-
Provedor de identidades sociais: Ao vincular uma conta do usuário do domínio de identidade às contas sociais do usuário, o usuário pode acessar um domínio de identidade usando suas credenciais sociais, como Facebook, Google, LinkedIn, Microsoft e X (anteriormente Twitter).
-
Provedor de autenticação sem senha: Permite que os usuários ignorem a autenticação padrão baseada em webform. A autenticação sem senhas permite o acesso ao recurso protegido sem a necessidade de digitar o usuário e a senha toda vez. No entanto, a primeira vez que Acessar usa o form de log-in padrão.
-
Provedor de identidades Local (IDP Local): A autenticação em um domínio de identidades ocorre localmente pelo usuário que fornece suas credenciais (nome do usuário e senha) na página Acessar.
- E-mail: Envia um código de acesso único para o endereço de email principal do usuário para uso como método de verificação a ser autenticado. O endereço de e-mail principal do usuário é definido na conta do usuário.
- Notificação de Aplicativo Móvel: Envia uma notificação push que contém uma solicitação de aprovação para permitir ou negar uma tentativa. As notificações por push são uma forma fácil e rápida de autenticação. Depois que o usuário insere seu nome do usuário e senha, uma solicitação do login é enviada ao aplicativo em seu telefone. O usuário toca em Permitir para autenticar.
- Código de Aprovação do Aplicativo Celular: Um aplicativo autenticador, como o aplicativo Oracle Mobile Authenticator (OMA), gera um único código de acesso. Esse código de acesso pode ser gerado mesmo quando o dispositivo do usuário está off-line. Depois que o usuário digita seu nome de utilizador e senha, um prompt aparece para o código de acesso. O usuário obtém um código de acesso gerado do aplicativo e, em seguida, digita o código.
- Mensagem de Texto: Depois que o usuário informa seu nome de utilizador e senha, um senha é enviado como uma mensagem de texto para o dispositivo do usuário. O usuário digita o código para concluir o acesso.
- username-Password: O usuário se autentica fornecendo suas credenciais (nome do usuário e senha) na página Acessar.
A política do provedor de identidades permite que você configure se a autenticação local será exibida na página Acessar do usuário.
Por exemplo, suponha que você tenha criado vários provedores de identidade social e provedores de identidade SAML, e queira configurar qual desses provedores de identidade aparecerá na página Fazer Sign-in quando o usuário tenta autenticar-se no domínio usando um aplicativo específico. Sem políticas de provedor de identidade, não foi possível configurar isso. Portanto, se você tivesse todos esses provedores de identidade SAML e social ativados e definidos para aparecer na página Acessar, todos eles seriam exibidos.
O domínio de identidades fornece uma política de provedor de identidades padrão que contém uma regra de provedor de identidades padrão. Esta regra tem o fator username-Password de autenticação local designado a ela. Dessa forma, no mínimo, os usuários podem se autenticar com seus nomes de usuário e senhas. No entanto, você pode desenvolver essa política padrão adicionando a ela outras regras de provedor de identidades. Adicionando essas regras, você pode impedir que alguns de seus provedores de identidade estejam disponíveis para os usuários se autenticarem no domínio de identidades. Ou você pode permitir a outros provedores de identidades estarem disponíveis somente para os usuários que acessam o domínio de identidades a partir de um endereço IP contido em um dos perímetros da rede. A console Meu perfil e a console de Administração usam as regras do provedor de identidades designadas à política do provedor de identidades padrão.
Suponha que uma empresa tenha restrições quanto a quem pode efetuar sign-in no domínio de identidades localmente (fornecendo seus nomes de usuários e senhas) e quem deve usar um provedor externo de identidades. Os funcionários da empresa devem se autenticar usando o Active Directory Federation Services (AD FS), os contratados e parceiros devem usar seus próprios provedores de identidade SAML, e todos os outros usuários (como consumidores) podem usar seus nomes de usuários e senhas ou um provedor da identidade social.
Para atingir esse objetivo, você pode criar duas regras de provedor de identidades para a política de provedor de identidades padrão. A primeira regra só é aplicável aos funcionários da empresa. Esses usuários devem acessar o AD FS, que é o provedor de identidades dos funcionários. A segunda regra se aplica somente aos usuários que têm nome de usuário que terminam com @partner1.com. Eles podem acessar o provedor de identidades SAML do parceiro 1. A terceira regra é aplicável somente aos usuários que têm nome de usuário que terminam com @partner2.com. Eles podem acessar o provedor de identidades SAML do parceiro 2. A regra final é uma regra catch-all para todos os usuários (consumidores). Esses usuários podem usar suas senhas locais ou um provedor de identidades social.
Como você pode definir diversas regras do provedor da identidade para uma política do provedor, o domínio da identidade deve saber a ordem em que as regras serão avaliadas. Para fazer isso, você pode definir a prioridade das regras. Para o exemplo anterior, você pode ter a regra de funcionário da empresa avaliada primeiro. Se um usuário atender aos critérios dessa regra (isto é, se o usuário for um funcionário), ele deverá autenticar-se com o AD FS. Os usuários que não são funcionários não atendem aos critérios dessa regra de provedor de identidades; portanto, a regra com a próxima prioridade mais alta é avaliada. Para este exemplo, esta é a regra do parceiro 1 na qual o usuário deve terminar com @partner1.com. Esses usuários devem se autenticar usando o provedor de identidades SAML do parceiro 1. Para usuários que não são funcionários ou que não têm nomes de usuários que terminam com @partner1.com, o domínio da identidade avalia a regra com o próximo número mais alto de prioridade: a regra do parceiro 2 na qual o usuário deve terminar com @partner2.com. Esses usuários devem usar o provedor de identidades SAML do parceiro 2 para autenticação. Todos os outros usuários atendem aos critérios da regra catch-all para que possam usar suas senhas locais ou um provedor de identidades social para acesso.
Além da política de provedor de identidades padrão, você pode criar políticas de provedor de identidades e associá-las a aplicativos específicos. Suponha que você tenha diversos aplicativos e queira designar diferentes provedores de identidade a cada aplicativo. Por exemplo, você poderá ter dois aplicativos e deseja que os usuários se autenticem no Facebook ou no LinkedIn. Portanto, você pode ter uma política de provedor da identidade para um aplicativo e o provedor da identidade social do Facebook, e outra política de provedor da identidade somente para o segundo aplicativo e o provedor da identidade social LinkedIn.
Um domínio de identidades exibe um máximo de quatro provedores de identidades na página Acessar. Se você designar mais de quatro provedores de identidade a uma política de provedor de identidade, será exibido um link Exibir tudo na página. Selecione o link e todos os provedores de identidade associados à política serão exibidos.