A pouco tempo atrás eu fui questionado sobre qual a diferença entre esses dois padrões utilizados em autenticação e autorização de acesso. Quando usar o SAML e quando usar o OAuth, que pergunta não? Eu já havia conhecia, mas não sabia como definir quais diferenças cada um possui e em que situações usar um ou outro. Para reforçar o meu aprendizado e também compartilhar com a comunidade vou iniciar uma sequencia de artigos sobre esses e outros protocolos.
De modo resumido o SAML (Security Assertion Mark-up Language) é um padrão relacionado a federação, gerenciamento de identidade e logon único (SSO). Já o OAuth (Open Authorization) é um padrão para autorização de recursos.
O OAuth não é um protocolo de autenticação, mas é usado dentro de protocolos de autenticação. Falarei dele em um próximo blog post
SAML – Security Assertion Markup Language
Hoje temos acesso a diversas aplicações na cloud, e é muito complicado ter uma identidade para cada aplicação, cada uma com uma senha (Geralmente os usuários criam uma unica senha para tudo) e os problemas nessas autenticações é que a senhas podem ser fraca, roubada e ainda quando esquecida os usuários ficam bem frustrados.
Com o SAML é possivel criar um sistema de Single Sign On com essas aplicações.
SAML significa “Linguagem de Marcação de Asserção de Segurança”. É um padrão baseado em XML para comunicação de informações de identidade entre organizações e a nuvem. Ele é usado para permitir a transmissão segura de tokens de autenticação e outros atributos.
Para entender melhor como funciona o processo do SAML é necessário entender 3 entidades:
- Usuário(Principal) – O individuo que precisa acessar recursos
- Identity Provider (Idp) – O provedor de identidade mantem um diretório de usuários e mecanismos de autenticação.
- Service Provider/Relying party – A organização que irá prover o serviço ou a aplicação.
Quando o usuário logar na rede da corporação com suas credenciais da corporação, quando ele clica em um link para acessar uma aplicação ou algum controle de segurança fornecido pelo Service Provider o Indentity Provider gera um token SAML e através desse token é garantido o acesso a aplicação.
Exemplos de Identity Provider (IdP)
- LDAP – Clientes empresariais que lidam com banco de dados de funcionários usando o protocolo LDAP.
- Active Directory e Azure Active Directory – Empresas que lidam com usuários usando o Diretório do Windows ADDS.
- Um web site que armazena senha e e-mail do usuário em um banco de dados SQL.
- Até mesmo Facebook outras empresas de midias sociais podem prover identidade.
Exemplos de Service Provider
- SalesForce
- Cisco Webex
- SAP
- Google Docs
- BOX
- Skype
- Concur
Componentes SAML
Assumptions – Define como os atributos SAML, autenticação e mensagens de protocolo de solicitação-resposta de autorização podem ser trocadas entre sistemas usando estruturas e protocolos de comunicação subjacentes comuns.
Bindings – Define como as declarações SAML e as trocas de mensagens de protocolo são conduzidas com pares de resposta / solicitação
Protocolos – Define quais protocolos são usados, que incluem SOAP e HTTP
Profiles– Define conjuntos específicos de regras para um caso de uso de atributos, ligações e protocolos para uma sessão SAML
No próximo artigo vamos discutir sobre o o Oauth.
Seja o primeiro a comentar