Aprender a linguagem de identidade

Objetivos de aprendizagem

Após concluir este módulo, você estará apto a:

Identificar os padrões da indústria usados no gerenciamento do acesso e da identidade.
Saber a relação entre SAML e XML.
Saber a diferença entre um provedor de identidade e um provedor de serviço.

Padrões e protocolos da identidade

É difícil de acreditar que você possa manter as identidades de seus usuários protegidas quando eles não precisam fazer login em sites ou aplicativos externos? Como os produtos de muitas empresas, mesmo concorrentes, podem operar juntos?

A resposta: através de padrões e protocolos da indústria para o gerenciamento do acesso e da identidade. Isso pode parecer intimidante, mas não tem de ser. Um padrão é apenas um conjunto de práticas amplamente estabelecidas que os membros da indústria seguem. Um padrão pode incluir um protocolo que especifica como os sistemas trocam informações.

Veja três protocolos que o Salesforce e outros fornecedores de identidade seguem para implementar soluções de identidade.

SAML
OAuth 2.0
OpenID Connect

Protocolo SAML

Se quiser que os usuários se movimentem tranquilamente entre as organizações e os aplicativos do Salesforce sem a necessidade de efetuar login repetidas vezes, configure o logon único (Single sign-on, SSO). O SAML (Security Assertion Markup Language, Linguagem de marcação de asserção de segurança) é o protocolo que torna isso em realidade.

Veja alguns exemplos de SAML em ação.

Quando você está conectado ao Salesforce e clica no Iniciador de aplicativos para acessar diretamente sua caixa de entrada do Gmail, isso é SAML em ação.
Quando os usuários que já estão conectados a outro aplicativo conseguem acessar a sua organização do Salesforce sem fazer login novamente, isso também é o SAML em ação.

Declaração SAML

É assim que o SAML funciona. Um usuário tenta acessar um serviço. O provedor de serviço envia uma solicitação para o provedor de identidade basicamente perguntando: “Ei, esse usuário pode acessar meu serviço?” O provedor de identidade garante que os usuários são quem eles afirmam ser verificando o banco de dados e, em seguida, retornando uma resposta, uma declaração, dizendo: “Sim, este usuário está autorizado. Veja algumas informações sobre ele”.

Um momento. Qual é a diferença entre um provedor de identidade e um provedor de serviço? Basicamente, o provedor de identidade é aquele que autentica o usuário. O provedor de serviços solicita a identidade autenticada. Falaremos mais sobre os provedores de identidade e de serviço posteriormente nessa unidade.

A declaração é a informação que está sendo enviada. Uma declaração pode carregar informações detalhadas sobre um usuário. Ela também pode conter atributos sobre o usuário, como nome e sobrenome, informações de contato e, talvez, até o cargo.

O SAML ocorre nos bastidores. Os usuários não veem nada. Eles apenas clicam em um ícone ou link e abrem outro aplicativo sem precisar fornecer informações adicionais ou fazer login novamente. Algumas vezes, o destino já sabe algumas coisas sobre eles (os atributos destes usuários) quando eles chegam lá.

SAML e XML

SAML é um protocolo baseado em XML e isso significa que os pacotes de informações que estão sendo trocados foram gravados em XML. O XML deveria ser (quase) humanamente legível para que você possa ter alguma ideia daquilo que está acontecendo. Isso é uma boa notícia se você estiver tentando descobrir se as coisas estão funcionando corretamente.

O diagrama a seguir ilustra uma parte de uma declaração SAML. Parece algo sem sentido? Olhe novamente e veja que não parece tão ruim assim. Ele contém informações sobre o nome de usuário, o número de telefone e o primeiro nome de um usuário.

Declaração do SAML

Neste exemplo, a organização do Salesforce passa as informações do usuário para outro aplicativo. O aplicativo pode usar essas informações para dar autorização ao usuário e personalizar a experiência do usuário. Mas, o mais importante, o usuário não precisa efetuar login novamente para acessar o aplicativo.

Protocolo OAuth 2.0

O OAuth 2.0 (autorização aberta) é um protocolo aberto usado para permitir o compartilhamento seguro de dados entre aplicativos. O usuário trabalha em um aplicativo, mas vê os dados em outro. Por exemplo, você está conectado no aplicativo móvel Salesforce e vê seus dados na sua organização do Salesforce.

Nos bastidores, os aplicativos entrem em acordo e, em seguida, pedem ao usuário para autorizar esse compartilhamento de dados. Quando os desenvolvedores desejam integrar seu aplicativo com o Salesforce, eles usam APIs OAuth.

Veja alguns exemplos.

Um aplicativo móvel que retira contatos de uma organização do Salesforce usa OAuth.
Uma organização do Salesforce que obtém contatos de outro serviço também usa OAuth.

O que se segue é um exemplo de um aplicativo que solicita ao usuário permissão para acessar informações usando OAuth 2.0.

Exemplo de registro do OAuth

Protocolo OpenID Connect

O protocolo OpenID Connect adiciona uma camada de autenticação no início do OAuth 2.0 para ativar a troca segura de informações do usuário. Como o SAML, o OpenID Connect envia informações de identidade de um serviço para outro. Diferentemente do SAML, o OpenID Connect foi criado para a atual realidade das redes sociais. Você alguma vez instalou um novo aplicativo e se deparou com um prompt dizendo “Entrar com sua conta do Google”? Esse aplicativo usa o protocolo OpenID Connect. Ao entrar com o Google, você não está criando uma conta e outra senha. Apenas o Google detém essas informações.

O desenvolvedor de aplicativos usou o protocolo OpenID Connect para ativar o login com redes sociais.

Por exemplo, quando o Google verifica a identidade de um usuário em nome de outro serviço, ele está autenticando o usuário. Dessa forma, o Google é um provedor de identidade.

O Salesforce cria suporte para vários provedores de identidade social importantes, incluindo o Google, o Facebook e o LinkedIn. Se um provedor não tiver suporte pronto para usar, ainda será possível usá-lo se ele implementar o protocolo OpenID Connect, como a Amazon e o PayPal fazem, por exemplo.

A vantagem do protocolo OpenID Connect para os usuários é que eles conseguem reduzir o número de contas, nomes de usuário e senhas separados. Por outro lado, os desenvolvedores podem autenticar seus usuários em sites e aplicativos sem ter de possuir e gerenciar arquivos de senhas. Este processo faz com que seja muito mais difícil para os hackers comprometerem contas de usuários.

Provedores de serviço e provedores de identidade

No processo de autenticação de usuários, o SAML troca informações de identidade entre o detentor da informação, chamado de provedor de identidade (identity provider, IdP), e o serviço desejado, chamado de provedor de serviço.

No caso em que um usuário faz login no Salesforce e depois acessa o Gmail, o Salesforce é o provedor de identidade e o Google é o provedor de serviço. O Salesforce pode ser um provedor de serviço e um provedor de identidade.

O Salesforce como provedor de serviço

Os usuários autenticados podem passar de um provedor de identidade externo para o Salesforce. Nesse caso, o Salesforce é um provedor de serviço. Os usuários querem ter acesso a esse serviço e seu provedor de identidade permite que eles façam isso. Esta configuração do Salesforce é comum porque, muitas vezes, sua empresa já usa um provedor de identidade. O provedor de identidade pode ser um dos vários disponíveis no mercado, como os Serviços de Federação do Active Directory (Active Directory Federation Services, ADFS) da Microsoft, o PingFederate da Ping Identity, o Shibboleth de código aberto ou o OpenAM da ForgeRock.

Os usuários efetuam login através de um provedor de identidade e, em seguida, são redirecionados para o Salesforce (o provedor de serviço). Em outro módulo, você configurará o SSO com o Salesforce como um provedor de serviço e um aplicativo de terceiros como o provedor de identidade externo.

O Salesforce como provedor de identidade

Os usuários autenticados também podem passar do Salesforce para outras nuvens e aplicativos. Nesse caso, o Salesforce atua como um provedor de identidade e fornece SSO para os usuários se conectarem a diferentes provedores de serviço.

Fluxo do SAML para SSO

Para os curiosos, o diagrama a seguir mostra como a comunicação do SAML flui durante o processo de SSO. Isso é o que está acontecendo nos bastidores. Não se preocupe se você não estiver interessado em espiar. Não faz parte do teste.

Todo o processo de SSO acontece à velocidade da luz, mas envolve algumas etapas.

Um usuário tenta acessar o Salesforce.
O Salesforce reconhece a solicitação SSO e gera uma solicitação SAML.
O Salesforce redireciona a solicitação SAML para o navegador.
O navegador redireciona a solicitação SAML para o provedor de identidade externo.
O provedor de identidade verifica a identidade do usuário e empacota a declaração SAML que contém a autenticação do usuário.
O provedor de identidade envia a declaração SAML para o navegador.
O navegador redireciona a declaração para o Salesforce.
O Salesforce verifica a declaração.
O usuário já está conectado e pode acessar o Salesforce.

Fluxo de solicitação SAML para SSO

Cheat sheet da terminologia da identidade

Como isso funciona em um curso intensivo sobre o tema de protocolos de identidade? Quando as palavras parecem semelhantes e as diferenças têm nuances, pode ser difícil defini-las bem. Para facilitar, veja uma cheat sheet. Espero que isso ajude!

Um termo	que é facilmente confundido com esse termo
Autenticação significa quem uma pessoa é. Atualmente, a palavra “autenticação” é frequentemente usada como abreviatura para “autorização e autenticação”.	Autorização significa o que uma pessoa pode fazer.
Protocolo especifica o conjunto de regras que habilita os sistemas a trocarem informações. Geralmente, os termos “protocolo” e “padrão” são usados de forma intercambiável.	Padrão é uma especificação, um conjunto de práticas da indústria para os quais os fornecedores concordam em oferecer suporte. Muitas vezes, um padrão contém um protocolo para especificar a forma como as empresas implementam o padrão.
Nome de usuário e senha são aquilo que o usuário fornece para efetuar login em um sistema.	Credenciais são basicamente a mesma coisa.
Login único (Single sign-on, SSO) permite que uma pessoa faça login uma vez e acesse outros aplicativos e serviços sem ter de fazer login novamente.	Login com redes sociais permite que uma pessoa faça login em um aplicativo usando as credenciais estabelecidas com uma conta social, como o Google. Esse aplicativo aceita as credenciais do Google e o usuário não precisa criar outra conta nem outra senha.
Provedor de identidade é um serviço confiável que permite aos usuários acessar outros sites e serviços sem ter de fazer login novamente.	Provedor de serviço é um site ou serviço que hospeda aplicativos e aceita a identidade de um provedor de identidade.

O que vem a seguir?

Você fez um tour rápido pelos padrões da indústria para conhecer o acesso e o gerenciamento da identidade. Não se preocupe se for difícil lembrar de tudo. Por enquanto, basta lembrar que o Salesforce Identity usa protocolos para implementar seus recursos.

Agora, é só aproveitar! Está cansado de conceitos e definições? Vamos colocar em prática um pouco daquilo que você aprendeu. Mais adiante nesta trilha, você configurará recursos de segurança em sua organização de Desenvolvimento do Salesforce.

Procurando ajuda?

Descubra mais