Conheça os protocolos de autenticação SAML, OpenID Connect e Oauth
Discernir as nuances entre os protocolos de segurança para autenticação pode ser um desafio. Esta perspectiva é fornecida para mostrar as diferenças entre AD FS, SAML, OpenID Connect e Oauth o que eles são e como eles são usados.
Protocolo de Autenticação dos Serviços de Federação do Active Directory (AD FS)
O Microsoft desenvolveu o AD FS para estender a identidade da empresa além do firewall. Ele fornece acesso de logon único aos servidores que estão fora do local. O AD FS usa um modelo de autorização de controle de acesso baseado em reivindicações. Este processo envolve a autenticação de usuários por meio de cookies e da Linguagem de Marcação de Afirmação de Segurança (SAML).
Isso significa que o AD FS é um tipo de Serviço de Token de Segurança, ou STS. Você pode configurar o STS para ter relacionamentos de confiança que também aceitam contas OpenID. Isso permite que as empresas ignorem a configuração de credenciais de registro e usuário separadas ao adicionar novos usuários - eles podem usar as credenciais OpenID existentes.
O AD FS é uma ferramenta valiosa, mas tem alguns Revanta:
É complicado de usar ao integrar com aplicativos móveis em nuvem ou não Microsoft
Requer recursos de TI para instalar, configurar e manter
É difícil de escalar e requer instalações de aplicação tediosas
Embora seja tecnicamente uma oferta gratuita da Microsoft, o uso do AD FS pode incorrer em custos ocultos, como tempo e esforço para a TI mantê-lo.
O que é o protocolo de autenticação SAML
O SAML é o mais antigo dos principais protocolos de identidade federados com sua última grande revisão no 2005. Existem três grandes players no SAML - o usuário, o Provedor de Identidade (ou IdP) que autentica o usuário e o Provedor de Serviços (ou SP), como um aplicativo.
SAML tem três componentes principais que são a asserção, o protocolo e a vinculação. A asserção SAML é um pacote de informações baseado em XML que contém informações específicas, como o usuário, grupo ao qual o usuário pertence ou qualquer outra informação que possa ser útil a um aplicativo. Asserções são para autenticação (identificação de um usuário), atributos (informações sobre um usuário) ou autorização (o que um usuário pode acessar e fazer).
O protocolo define como as asserções são enviadas e recebidas. Finalmente, a ligação é uma definição de como as trocas de mensagens SAML e as trocas de protocolo de acesso a objetos simples (SOAP) são mapeadas entre si.
Aqui está um caso de uso simplificado do SAML. O usuário precisa acessar muitas aplicações diferentes. O cliente do usuário diz a um aplicativo - que é o Provedor de Serviços - que eles querem acessar seus serviços. O Provedor de Serviços precisa verificar se o usuário está autenticado. Se estiver, o usuário está livre para prosseguir. Se não estiver, o cliente precisa ir ao Provedor de Identidade para autenticação.
O Provedor de Identidade autenticará o usuário contra alguma credencial neste ponto. Uma vez que o Provedor de Identidade tenha autenticado o usuário que dá acesso ao aplicativo, ele cria a afirmação SAML. O Provedor de Identidade passa a afirmação SAML para o cliente que a passa para o Provedor de Serviços. O Provedor de Identidade também pode passar a afirmação para diferentes aplicativos, conforme necessário, salvando o usuário de re-autenticação.
Diagrama de fluxo SAML 2.0
Microsoft & AD FS Terminologia
Os Serviços de Federação do Active Directory do Microsoft têm sua própria terminologia e abordagem ao SAML, por isso justifica uma breve explicação. O Microsoft AD FS é um provedor de identidade.
Relying Party é o termo que Microsoft AD FS usa para significar Provedor de Serviços.
As regras são outro termo que apenas Microsoft Regras de Reclamações são regras que você pode aplicar para alterar como ou quando invocar a autenticação. Por exemplo, um administrador pode configurar uma regra de reivindicações que só se aplica quando um usuário vem para AD FS como eles estão tentando chegar ao Dropbox. Além disso, impede que eles usem um dispositivo móvel que permita que o usuário faça login com um laptop ou dispositivo desktop, mas não com o seu Android ou iPhone. Alguns IdPs diferentes do AD FS podem criar regras semelhantes, mas o AD FS permite algumas das mais robustas e complexas criações de regras.
ImmutableID é o equivalente Microsoft Azure AD de um ObjectGUID. Não é específico para AD FS, mas vale a pena mencionar.
O WS-Fed é semelhante ao SAML e obedece a muitas das mesmas regras. É um protocolo criado especificamente pelo Microsoft e não é amplamente suportado por IdPs que não o AD FS.
Benefícios de configurar provedores de autenticação de 3rd como autenticação primária em AD FS
As organizações estão enfrentando ataques que tentam força bruta, comprometer ou bloquear contas de usuários enviando solicitações de autenticação baseadas em senha. Para ajudar a proteger as organizações contra comprometimento, o AD FS introduziu recursos como bloqueio “inteligente” de extranet e bloqueio baseado em endereço IP.
No entanto, essas mitigações são reativas. Para fornecer uma maneira proativa de reduzir a gravidade desses ataques, o AD FS tem a capacidade de solicitar fatores não-senha antes de coletar a senha. Por exemplo, o AD FS 2016 introduziu o Azure MFA como autenticação primária para que os códigos OTP do aplicativo Authenticator possam ser usados como o primeiro fator. Com base nisso, o AD FS 2019, você pode configurar provedores de autenticação externos como fatores de autenticação primários.
Cenário 1: Proteja a senha
O Microsoft desenvolveu o AD FS para estender a identidade da empresa além do firewall.
Ele fornece acesso de logon único aos servidores que estão fora do local. AD FS usa um modelo de autorização de controle de acesso baseado em reivindicações. Este processo envolve a autenticação de usuários através de cookies e Security Assertion Markup Language (SAML).
Cenário 2: Sem Senha
Você também pode eliminar completamente as senhas completando uma autenticação forte e multifator usando métodos totalmente sem senha no AD FS.
Azure MFA com aplicação Authenticator
Windows 10 Olá para Negócios
Autenticação do certificado
Prestadores de autenticação externa (o que proporciona a melhor mitigação de risco para ataques de personificação como phishing e MitM), o que requer algum tipo de integração com o Microsoft
Definição do protocolo de autenticação OpenID Connect
Enquanto OAuth 2.0 Não é muito adequado para autenticação, o OpenID Connect consegue resolver este problema. Estabelecido em 2014, OpenID Connect é uma camada de identidade construída sobre OAuth 2.0, com um grande número de implementações de empresas como Google e PayPal. O OpenID Connect permite que os aplicativos cliente recebam informações básicas valiosas sobre um usuário, como a identidade do usuário, os atributos disponíveis do usuário e outros detalhes relacionados à autenticação. Like SAML, a autenticação é feita por algum Provedor de Identidade, como o Google, que é então retransmitido de volta para a parte de retransmissão ou o serviço solicitando autenticação.
Os provedores de identidade suportados variam de grandes empresas a pequenos provedores, como um auto-emitida. O OpenID Connect foi projetado com simplicidade em mente e usa fluxos de mensagens REST / JSON. Ele suporta uma variedade de clientes, incluindo clientes baseados na web, clientes móveis e clientes JavaScript. Finalmente, o OpenID Connects extensible especificação permite recursos opcionais, como criptografia de dados de identidade, descoberta de provedores de OpenID e gerenciamento de sessão.
Diagrama de fluxo de conexão OpenID
Conclusão
O OpenId Connect é construído sobre os fluxos de processo do OAuth 2.0 e normalmente usa o formato JWT (JSON Web token) para o id-token.
O fluxo SAML é independente do OAuth 2.0 e depende da troca de mensagens para autenticação no formato XML SAML (em vez do formato JWT).
Ambos os fluxos permitem SSO (Single Sign On) e a capacidade de fazer login em um site usando suas credenciais de login de um site social (por exemplo, login no Facebook ou login do Google).
O OpenId Connect é mais novo e construído sobre o fluxo de processo OAuth 2.0. É testado e testado e normalmente usado em sites de consumo, aplicativos da Web e aplicativos móveis.
SAML é o seu primo mais velho, e normalmente usado em ambientes empresariais, por exemplo, permitindo o logon único em várias aplicações dentro de uma empresa usando o login do Active Directory.
Comparando protocolos de autenticação SAML vs. OpenID Connect
Correndo o risco de simplificação excessiva, o OpenID Connect é uma reescrita do SAML usando o OAuth 2.0. Aqui estão algumas semelhanças e diferenças.
PDP / SP vs. OP / RP
Em SAML, o usuário é redirecionado do Provedor de Serviços (SP) para o Provedor de Identidade (IDP) para entrar. No OpenID Connect, o usuário é redirecionado da Parte Confiante (RP) para o Provedor OpenID (OP) para entrar. O SAML O OpenID Connect RP é uma aplicação web ou móvel e é frequentemente chamado de “cliente” porque estende uma OAuth 2.0 Em ambos os casos, o IDP/OP controla o login para evitar expor segredos (como senhas) ao site ou aplicativo.
Assertion vs. id_token
No SAML, há uma “afirmação” - um documento XML assinado com as informações do assunto (quem autenticado), atributos (informações sobre a pessoa), o emissor (quem emitiu a afirmação) e outras informações sobre o evento de autenticação. O equivalente no OpenID Connect é o id_token. Este é um documento JSON assinado que contém o assunto, o emissor e as informações de autenticação.
Canal frontal vs. Canal de trás
Uma grande diferença entre o OpenID Connect e o SAML é o uso de um “canal frontal” e um “canal traseiro”. O canal frontal é o navegador e o canal traseiro é a comunicação diretamente entre o aplicativo e o IDP/OP.
Embora o SAML defina mecanismos de back-channel, eles raramente são usados na prática. A maneira mais comum SAML envia o XML de solicitação e XML de resposta (afirmação) é através do navegador. A maioria dos sites do SAML usa o “POST Binding” para enviar a resposta. Neste cenário, o navegador é enviado como um formulário HTML do IDP com o XML de resposta como um parâmetro de formulário. Há algum JavaScript no formulário para enviar automaticamente.
O OpenID Connect define um mecanismo semelhante (“Modo de resposta pós-resposta de formulário”), mas ao contrário do SAML, seu uso é mais a exceção do que a regra. Tanto o OpenID Connect quanto o SAML frequentemente usam algo como a “ligação de redirecionamento” para enviar o pedido. É aqui que os parâmetros de URL são usados para enviar o XML. Isso também aproveita o navegador.
O OpenID Connect normalmente usa o canal de volta - uma chamada direta do RP para o OP - para recuperar essas informações. Os atributos (ou "reivindicações do usuário" no jargão OpenID) estão disponíveis para o cliente chamando o ponto de extremidade user_info que é um JSON REST APINo entanto, porque isso é OAuth 2.0, o cliente precisa de um token para chamar isso API. De acordo com o OAuth 2.0 O token é obtido a partir do ponto final do token do OP usando o canal traseiro.
Qual protocolo de autenticação, quando?
Quando SAML deve ser usado e quando OAuth 2.0 ou OpenID Connect deve ser usado em vez disso?
Com aplicações móveis, não há dúvida - use o OpenID Connect
Se o aplicativo já suporta SAML, use SAML
Se você estiver escrevendo um novo aplicativo, use o OpenID Connect porque é aí que a tecnologia está sendo aceita
Se você precisa proteger APIs ou precisa criar um Gateway API, a resposta curta é usar o protocolo OAuth 2.0 ou o protocolo User Managed Access (“UMA”). Sim, essa resposta é uma simplificação excessiva
Como o SAML é diferente do Oauth e da Federação de Serviços da Web?
Você já deve ter ouvido falar sobre essas outras alternativas SAML de passagem, mas como elas diferem? Você deve ter uma opinião sobre qual delas é melhor? Entenda que SAML, OAuth e Web Services Federation (WS-Fed) variam tecnicamente, bem como a melhor forma de usá-las.
SAML – é mais comumente usado pelas empresas para permitir que seus usuários acessem serviços pelos quais pagam. Salesforce, Gmail, Box e Expensify são exemplos de provedores de serviços aos quais um funcionário obteria acesso após um login no SAML. SAML afirma ao provedor de serviços quem é o usuário; isso é autenticação.
WS-Fed - Web Services Federation é usado para os mesmos fins que SAML, para federar a autenticação de provedores de serviços para um provedor de identidade comum. É bem suportado com certos IdPs, como Microsoft Active Directory Federation Services (AD FS), mas não é prevalente com provedores de serviços em nuvem. O WS-Fed é indiscutivelmente mais simples do que o SAML para desenvolvedores implementar, mas seu suporte limitado entre IdPs e similares.
OAuth – é o mais comumente usado por aplicativos e serviços de consumo para que os usuários não precisem se inscrever para um novo nome de usuário e senha. “Iniciar sessão com o Google” e “Entrar com o Facebook” são exemplos de OAuth no mundo real. OAuth delega o acesso à conta do Google ou do Facebook de uma pessoa por terceiros.
Normalmente, o aplicativo no qual o usuário está entrando pode ler diretamente as informações do perfil do usuário ou tomar ações (como postar fotos ou fazer atualizações) em seu nome. Este é um exemplo de autorização. O mais importante é analisar a prevalência de cada tecnologia para cada caso de uso. SAML é onipresente no local de trabalho para aplicativos baseados em nuvem, enquanto WS-Fed não. Por outro lado, OAuth é onipresente entre os aplicativos de consumo.