Architecture In A Box - Declarações e Identidades Na Computação Na Nuvem

Infrastructure Architecture in a Box
Declarações e Identidades na Computação na Nuvem
Markus Christen
IT Architect Microsoft
blogs.technet.com/MarkusChristen
twitter.com/MarkusChristen
channel9.msdn.com/brasil

Agenda
Computação na Nuvem
“FederatedIdentity Patterns”
Perguntas & Respostas

Objetivo
Encorajar vocês a pensar sobre a mudança do paradigma com a chegada da “Computação na Nuvem “ e “ClaimBasedAuthentication”
Apresentar as principais papeis na Federação e Integração com a nuvem

Computação na Nuvem ...
“CloudComputing”
“Cloud Platform”
“Cloud Infrastructure”
“UtilityComputing”

Curta Introdução á Computação na Nuvem

Vocês se lembram: Inovação

A grande Ideia...: Evolução

Plataforma Azure da Microsoft

Desafios para a Autenticação & Autorização

Cenário Simples
Domínio de Segurança
Aplicação
Autenticação & Autorização
Usuário
Usuário e Senha +
com provedor de identidades customizado

Cenário: Múltiplas Aplicações
Domínio de Segurança
Aplicação HR
Aplicação CRM
Aplicação Autom.
Usuário
Directory Service

Cenário: Integração com a Nuvem
Recursos na Nuvem
Autenticação Autorização
Local
Directory Service

Cenário: Nuvem como uma “Bridge”
Acesso
Acesso
Empresa 1
Empresa 2

Desafios atuais
Múltiplos domínios de segurança distribuídos
Múltiplos provedores de identidades
Múltiplos padrões de desenvolvimento
Acoplamento de tecnologia

“IdentityMetasystem & ClaimBasedAuthentication”

As grandes questões !
Passaporte
Autenticação: Quem é você ?
Idade 18 ?
Autorização : O que você pode fazer ?

Hoje: Autenticação e Autorização
Integrada & Acoplada
Aplicação
Usuário
Autenticação
Autorização
Recurso
Provedor

CBA: Autenticação e Autorização
“ClaimBasedAuthentication”
Aplicação com
Autorização
Usuário
Passo 2: Autorização
Confiança
Autenticação
Independente da
Aplicação
Passo 1: Autenticação

Papeis: Exemplo da Vida Real
Declaração (Inscrição do evento)
Afirmação feita por uma identidade sobre outra identidade
Token de segurança (Crachá do evento)
Documento encapsulado que contém as declarações
Criado pelo serviço de token de segurança
STS: Serviço de token de segurança (Portaria)
A tarefa básica de um STS é autenticar os usuários e criar um token de segurança
Aplicação ciente de declarações (Segurança área VIP)
Declarações aplicadas quando usuário acessa a aplicação
Aplicação requer declarações para definir usuários
Autenticação
Autorização

Token De Segurança
Token com Declarações
Declaração : Nome Markus
Identidade
XXX
Declaração : Sobrenome Christen
Declaração : Cargo Arquiteto
Declaração : Alias Markusc
Token Signature
Autorização
Declaração Alias = Markusc
Declaração Cargo: Arquiteto
Entrega
Aplicação

Papeis no processo de “CBA”
Declarações (Declaração / Sujeito)
Declaração feita via uma entidade sobre um sujeito
Exemplo: Markus idade 38
SAML (Security AssertionMarkupLanguage)
Padrão baseado em XML para troca de dados entre o “STS” e o consumidor (Recurso)
Secure Token (Token & Declarações)
Documento XML encapsulando as declarações
Exemplo: Documento RG
Security Token Service (STS / Issuer)
Web Service com a tarefa básica de criar token de segurança com as declarações
Exemplo: Policia Federal

WS-Trust – Confiança

Confiança é a expressão entre duas partes aonde uma parte da relação acredita nas declarações da outra parte; ele é baseado em evidências – históricas, experiência, documentos, etc. – e a tolerância de risco pessoal

Especificação: WS-Trust
Secure Token Service
Criação do Token
Account
Attribute Store
Autenticação
Requisita token de segurança
Lista de STS
Resposta :Token com Declarações
WS-Trust
Confiança
“RelyingParty”
Aplicação
STS com Confiança
Verificação
das declarações
Information
Card
Acesso
Browser ou Cliente
(Token com as Declarações
Autorização

WS-Federation

Uma federação é uma coleção de domínios de segurança, que estabeleceram relações para compartilhar recursos de segurança.
O valor de estabelecer uma federação é facilitar o uso de atributos de segurança entre vários domínio de segurança para estabelecer um contexto de Federação.

WS-Federation
IP-STS
Federação
Account
Attribute Store
RP-STS
Lista de STS
Entrega Token( SAML)
Requisita token de segurança
Retorna Token (SAML)
Retorna Token (SAML)
Confiança
STS com Confiança
Verificação
das declarações
Verificação na Lista de Confiança
Autenticação
Acesso
Aplicação (RelyingParty)
(Token - SAML)
Autorização
Browser ou Cliente
Information
Card

Information Cards
Identity Providers
Browser or Client
STS
STS
STS
CardSpace “Geneva”
Information Card 1
Information Card 2
Information Card 3
Information Card 4
User

"Information Cards"
Contem:
É um arquivo XML que representa uma relação com o provedor de identidade
Ele contém o que é necessário para solicitar um token para uma identidade particular
Não contêm:
Declarações da Identidade
Tudo o que é necessário para se "autenticar" no provedor de identidade

Garantir a Interoperabilidade
Baseado em padrões abertos:
WS-Federation
WS-Trust
Protocolo: SAML 2.0

Impacto para os Profissionais de TI
Profissionais de TI podem mudar o método de autenticação sem modificação da aplicação
Profissionais de TI podem providenciar “Single Sign-On”entre aplicações que usam acesso baseado em declarações
Profissionais de TI providenciam o processo de Autenticação.

“Cenários”

Organização X
Active Directory Domain Services
IP/RP STS
5) Usar as declarações
Token
3) Obter token para a identidade selecionada
Aplicação
4) Submeter token
Token
Framework
Browser ou Cliente
1) Acessar o aplicativo e aprender os requisitos tokens
CardSpace
Confiança STS’s:

Organização Y
Organização X

2) Selecione uma identidade que corresponda a essas exigências
Usuário
Enterprise: Local IP-STS

Enterprise: Remote IP-STS
Organização X
Organização Y
Active Directory Domain Services
RP- STS
IP STS
Token
Aplicação
4) Submeter token
Token
Framework
Browser ou Cliente
CardSpace
Confiança STSs:

Organização Y
Organização X

Usuário

Enterprise: Federação (Múltiplos)
Enterprise Organização X
Organização Y
Computação na Nuvem
5) Transformação do token
Directory Domain Services
Confiança STS’s:

Organização X

Confiança
IP STS
ACS
RP- STS
Token
Token
4) Submeter token
6) Receber token
Token
Aplicação
7) Submeter token
Browser ou Cliente
Token
Framework
CardSpace
Confiança STSs:

Organização Y

Usuário

Enterprise: Federação na Nuvem
Computação na Nuvem Z
Processo de Transformação
Confiança
Confiança
Confiança
Acesso
Confiança STS’s:

Organização X & Y

ACS
RP- STS
Usar as declarações
Enterprise Organização Q
Enterprise Organização X
Enterprise Organização Y
RP STS
IP STS
IP STS
Aplicação
Confiança STS’s:

Organização Z

Framework

Microsoft IdentitySolution

Visão “Microsoft IdentitySolution”
Off-Premise
On-Premise

Conclusões
Alterar o paradigma atual não é uma assunto de curto prazo
Todas os componentes necessários para aplicar a autenticação baseada em declarações:
ADFS 2.0
CardSpace “Geneva”
Windows Identity Foundation

Referencias
Introdução “Geneva”: An Overview ofthe “Geneva” Server, CardSpace “Geneva”, andthe “Geneva” Framework
http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/GenevaBeta1_Whitepaper_Chappell.docx
Markus Christen Blog sobre “ClaimBasedAuthentication”
http://blogs.technet.com/markuschristen/archive/tags/Geneva/
Channel 9 Brasil sobre Geneva Framework
http://channel9.msdn.com/posts/Markus+Christen/ArqCast-Brasil-Windows-Identity-Framework--ADFS-20/
Keith Brown’s “Geneva” Framework White Paper for Developers
http://download.microsoft.com/download/7/d/0/7d0b5166-6a8a-418a-addd-95ee9b046994/GenevaFrameworkWhitepaperForDevelopers.pdf