O guia do desenvolvedor .NET para identificação

Keith Brown

Publicado em: 4 de outubro de 2006

Este é um guia para desenvolvedores e arquitetos quem queiram aprender a construir aplicações que possuam um esquema de identificação de qualidade, na plataforma Microsoft® Windows®. De autenticação e autorização até identificação federada, você descobrirá técnicas que podem ser usadas hoje, e no futuro, para alavancar uma estrutura de identificação, como o Active Directory®. Isto reduz a necessidade de construir sua própria estrutura de identificação, que apenas fragmenta o processo de identificação e leva os custos mais elevados. No decorrer deste guia, você achará links para outros recursos que fornecem mais detalhes sobre o assunto.

Nesta página

Introdução
Autenticação
Autorização
Desenvolvendo Aplicações .NET orientadas a identificaçãoIdentity-Aware
Identificação federada
Segurança no Windows Communication Foundation (WCF)
Estratégias de autorização

Introdução

Quando a Microsoft me pediu pela primeira vez para escrever um artigo (um white paper), para os desenvolvedores, sobre a construção de aplicações com processos de identificação, eu hesitei, pois estava preocupado com o fato de não ter liberdade para contar a história da maneira que eu quisesse. E, com toda certeza, eu precisava contar essa história: Eu estive aperfeiçoando-a nos últimos 6 anos! Mas, agora que este artigo foi escrito e eu finalmente escrevi esta introdução, posso dizer a você que esta é, de fato, a minha história - e não um monte de besteiras marketeiras. Este é um artigo real e prático, que guiará você através da “terra da identificação” na plataforma. NET e o ajudará a planejar e construir aplicações com processos de identificação de qualidade. Se eu obtiver sucesso, esta história o ajudará a juntar as muitas peças deste quebra-cabeça, cuja ajuda na documentação do SDK oferece, apenas, dicas. E você também vislumbrará o que ainda está por vir no futuro – e, desde já, poderá se preparar para ele.

E, a propósito, o que é uma aplicação com identificação? Eu tenho em mente que, primeiramente, é uma aplicação que conta com os detalhes de identificação de seus clientes, ajustando seus comportamentos de acordo com esses detalhes. É por essa razão que a primeira parte deste artigo é focada em autenticação. Outra etapa desse processo identificatório é fazer parte do Active Directory. Não estou aqui para lhe dizer que abandone o SQL Server em prol do Active Directory, mas sim para lhe dizer que há muito a se ganhar quando se baseia no AD. Talvez você se surpreenda com quão poucas linhas de código consegue-se pesquisar um telefone ou um endereço de e-mail de determinado usuário - e talvez isto seja o suficiente para fornecer uma vantagem competitiva a um ISV. Se você procura por serviços do Active Directory que possam ser embutidos em sua aplicação, então o ADAM (Active Directory Application Mode) foi feito para você! Posteriormente, eu lhe mostrarei onde obter mais informações.

Outra funcionalidade contida em aplicações providas com identificação é a de autorizar seus membros à realizarem determinadas operações. Esta é a segunda parte deste artigo, onde enfatizo a utilidade da criação de uma política de autenticação separada do código da aplicação - de modo que essa política possa ser facilmente administrada. Também levarei em consideração o seu conhecimento sobre grupos e, para que você entenda mais sobre o assunto, explicarei (com base nesse conhecimento) tópicos como autenticação “role-based” e “claim-based” - que representam o futuro dessa plataforma. Eu também lhe ajudarei na escolha entre o modelo “trusted subsystem” versus “impersonation”, que representam uma decisão crítica de criação quando na construção de sistemas multicamadas. Será importante saber escolher a melhor maneira.

As primeiras duas seções abordam apenas os conceitos, mas a seção seguinte é toda focada na parte de programação. Apesar de nossos objetivos (a escrita de menos código e a utilização de mais recursos de segurança da plataforma), haverá momentos em que você terá de escrever algumas linhas de código. Aqui eu mostrarei a facilidade de se utilizar a segurança “role-based” do .NET Framework; como a sua infra-estrutura se comunica com a sua aplicação via Thread.CurrentPrincipal . Também mostrarei umas cinco - ou menos - linhas de código para a busca de informações no Active Directory quando necessário (viu, eu disse a você que era fácil). Então eu lhe mostrarei o mínimo de código necessário para começar a usar o Authorization Manager (AzMan) – um excelente recurso, pouco divulgado, que pode ajudá-lo no desenvolvimento de uma política de autorização para sua aplicação.

Então eu, novamente, voltarei a ser conceitual e falarei sobre a identificação federada, que irá prepará-lo para o que ainda está por vir, bem como introduzi-lo ao Active Directory Federation Services, que vem com o Windows Server 2003 R2. Aqui você aprenderá o que é uma declaração, e o que faz uma autorização baseada nessas declarações, bem como a transformação destas e de como o STS (Security Token Services) pode ser um poderoso recurso para agregar e trazer companhias através da internet. Uma vez que você entenda esses pontos-principais da identificação federada, eu falarei sobre o meta sistema de identificação e mostrarei como o Cardspace toma parte nesse esquema, provendo a fundação para uma camada de identificação na internet.

Pelo fato do Windows Communication Foundation (WCF) ser o futuro da comunicação para o Windows (e grande parte dele lidar com a construção de aplicações com identificação), falarei sobre a criação e programação de procedimentos de identificação com o WCF na última seção. Também falarei sobre as ligações típicas e sobre os lembretes que podem ser criados para o suporte à infra-estrutura de identificação da qual você necessitará. E, desde que o WCF é uma das principais maneiras para se criar processos de identificação federada, mostrarão a você como acessar declarações do contexto de segurança do WCF.

Este artigo tem o intuito de ser um guia ao invés de um passo-a-passo para construção de uma aplicação com identificação. Sempre que houver necessidade de se explorar alguma informação de maneira mais detalhada, fornecerei links com documentos complementares. Mas não pense que este artigo é apenas um apontador para outros documentos. Ele foi feito para designers e desenvolvedores de software; e seu objetivo é fornecer informações sobre a facilidade em se implementar procedimentos de identificação através dessa plataforma. Aproveite!

Autenticação

Autenticação é um tópico fascinante, mas, tradicionalmente, é relegado apenas ao processo de prover a resposta para a pergunta; “Quem é você?”. Existem muitas maneiras de se responder a essa questão, e todas envolvem um desafio para que o usuário forneça algum tipo de evidência: “O que você sabe?” é outra questão comumente utilizada (às vezes, exageradamente) na computação. Aqui é onde o usuário fornece algum segredo para o compartilhamento com o sistema de segurança, que então assume a forma de uma senha ou um código PIN. “O que você tem?” é outra questão comum, que você encontrará sempre que se utilizar de um cartão bancário para sacar dinheiro ou comprar algo. Neste caso também será requisitada uma senha / código PIN, então você terá dois fatores de autenticação: duas evidências (recursos) devem ser fornecidas pelo usuário para que este possa prosseguir. Um cartão inteligente com um código PIN assemelha-se a isso, porém, é uma solução muito mais robusta, e atualmente está sendo desenvolvida por muitas companhias, dentre elas, a Microsoft. A biometria é o terceiro recurso, algumas vezes utilizada em sistemas de alta segurança. Qualquer coisa a ela relacionada, de uma impressão digital a um scanner de retina, representa o desafio de saber “do que você é feito?”

No passado, pensávamos na autenticação como uma maneira de descobrir o nome do cliente, assim, “Quem é você?” era uma questão apropriada. Mas no futuro, como você verá mais tarde neste artigo, a noção de identificação não será necessariamente ligada ao nome do usuário. Talvez você nem se importe com QUEM seja o usuário, mas sim com quem é autorizado a executar a ação requisitada. Então, um estilo mais correto para essa questão seria; “O que eu sei sobre o remetente dessa mensagem?”.

Escolher como autenticar usuários é o primeiro passo em direção à construção de aplicações com procedimentos de identificação. Mas, como você verá, o grande problema é que raramente compensa construir sua própria solução de identificação.

Autenticação é um Grande Problema

Imagine que você tem uma aplicação que aguarda algum retorno de um socket. Ao receber alguma informação desse socket, você tem acesso à alguma informação do remetente? Surpreendentemente, essa é uma questão difícil de responder! Você provavelmente já deve saber que não pode contar com o endereço IP contido no cabeçalho da mensagem, porque isso é relativamente fácil de se falsificar. Você precisa  planejar a construção de uma solução mais segura.

Você pode começar por incluir um nome de usuário na mensagem. Esse é o primeiro passo rumo à autenticação do usuário (este precisa ter uma maneira de lhe dizer quem é), e a isso se dá o nome de identificação. Se você acredita que todos os usuários de seu sistema se identificarão corretamente, você pode parar de ler este artigo agora mesmo. Uma das coisas que tentamos fazer na segurança de sistemas é reduzir essa necessidade de confiança - porque, inevitavelmente, alguém pode quebrar essas regras.

Para resolver esse problema, digamos que você acrescente uma senha para cada usuário e faça com que cada um deles a inclua juntamente com seus nomes, em cada uma de suas mensagens. Ao utilizar essa senha, o usuário estará fornecendo uma evidência de sua identidade. Como de costume, num processo de trapaça, o atacante precisará descobrir a senha do usuário que ele pretende personificar. E isso não é difícil, desde que a senha desse usuário seja enviada de uma maneira simples. Redes ethernet, mesmo aquelas com switches, são suscetíveis a ataques de sniffing. Se você já utilizou uma ferramenta como o Netmon ou o Ethereal, você sabe como é fácil espionar o tráfego de rede de seus vizinhos.

Então, ao invés de enviar a senha na mensagem, você decide utilizar a senha para gerar uma chave criptografada (já existem, até mesmo, padrões para se fazer isso: veja em http://www.faqs.org/rfcs/rfc2898.html). O cliente pode então utilizar essa chave para assinar a mensagem, e o receptor pode, posteriormente, verificar a assinatura da mensagem recebida. Isso recebe o nome de proof of possession (algo como evidência de posse). A Criptografia fornece muitas maneiras de provar conhecimento sobre um determinado segredo sem ter de revelá-lo. Suas soluções começam a ficar mais complicadas agora, mas você provavelmente está se sentindo um pouco melhor sobre essa questão.

Infelizmente, esta contramedida não deterá um ataque determinado. Uma senha é uma fonte ruim para uma chave, porque os usuários podem não se lembrar de senhas longas e complicadas, e podem deixá-las bastante fáceis de adivinhar.  palavras chaves não são muito melhor. Um hacker habilidoso começará adivinhando senhas ou palavras chaves usando dicionários e permutações dessas palavras. Ele sabe quando obteve sucesso quando uma assinatura é verificada com sucesso, ou quando o texto cifrado se decifra para algo compreensível. Este ataque pode ser automatizado e pode ocorrer no tempo em que o hacker está offline, e onde ele pode dedicar todos os recursos de computação que ele possui ao problema. Considere que a maioria dos hackers possui uma grande quantidade de equipamentos; reze para que nenhum deles escolha residir em sua casa ou escritório!

Até mesmo o protocolo Kerberos está sujeito a estes tipos de ataques com senhas fracas, porém utilizadas, e é por isso que companhias estão mudando para smartcards onde chaves mais fortes podem ser usadas. E se você estiver utilizando Windows, sua plataforma suporta isto.

Eu espero tê-lo convencido que autenticação seja um problema realmente grande! Este não é um trabalho que você quer se assumir. Uma forma muito melhor é confiar em especialistas de criptografia para construir este tipo de infra-estrutura para você. O Windows tem já tem esta infra-estrutura que você precisa: tudo você tem que fazer é escolher e usá-lo.

Deixe a Plataforma realizar o Levantamento Pesado: Single Sign On

O Windows apresenta vários protocolos de autenticação forte embutidos. Construindo uma aplicação que simplesmente confia no sistema operacional para prover autenticação, você evita ter que projetar seus próprios protocolos de autenticação. Eu não conheço nenhum programador que gosta de construir bancos de dados de senhas; isso é uma posição muito incômoda para eles! Além disso, quem precisa de outro banco de dados para guardar identificações? Os usuários já têm muitas credenciais para administrar, e o custo desta administração está ultrapassando a linha de negócios. Oferecendo aplicações de autenticação de plataforma, você vai ganhar muitos defensores para sua causa: Os administradores de sistemas do IT.

Pense em o que acontece quando um usuário novo se junta à companhia. Se sua aplicação confia em autenticação de plataforma, não há com que se preocupar! Utilizando grupos, os administradores poderão conceder o acesso de usuário novo a qualquer recurso que ela precisa, sem a necessidade de mudar a aplicação. Mas se você programou seu próprio esquema de autenticação, um administrador precisará configurar uma conta de usuário nova em sua aplicação. Este processo é conhecido como user provisioning, e é um ponto de gargalo principal para IT em qualquer empresa.

Uma outra situação. O que acontece quando um usuário deixa a empresa? Se o administrador esquecer de apagar a conta dele da sua aplicação, você adquiriu um usuário com credenciais que poderiam continuar acessando recursos ao qual ele não deveria ter mais!

Eu espero que você possa ver que tendo um único jogo de credenciais para acessar recursos de companhia internos seja um enorme ganho para os funcionários e o pessoal de IT. Mas eu tenho nem mesmo tocado no benefício realmente mágico que o usuário final vê. Single Sign On (SSO) é sobre o que eu estou falando. SSO é uma das melhores maneiras que você pode contribuir para a transparência de segurança. Através da autenticação já existente na plataforma, qualquer usuário que logou na estação de trabalho usando uma conta de domínio pode acessar sua aplicação imediatamente sem a necessidade de se logar novamente. Ela pode mover-se nas redes rapidamente, enquanto trabalha, sem encontrar impedimentos do sistema de segurança.

Há companhias que gastam fortunas tentando implementar SSO em suas aplicações que foram adquiridas durante os anos. O que eu estou dizendo é que você pode adquirir esta característica sem custo; tudo que você a fazer é concordar em escrever menos código e confiar na plataforma para fazer a segurança.

Protocolos de Autenticação suportados pelo Windows

Há muitos protocolos de identificação feitos para o Windows, mas os mais robustos são Kerberos e SSL/TLS. Já que você encontrará estes dois mais frequentemente, uma breve descrição dele está a seguir. E para um entendimento do Login Smartcard SSL/TLS, são necessários conhecimentos prévios em certificados e PKI.

Entender os fundamentos de como estes protocolos funcionam pode ajudá-lo quando -sevocê estiver projetando novos sistemas ou depurando erros (debug/revisão) em problemas em sistemas existentesJá que os chamados sistemas futuros base do futurosão baseados nas mesmas idéias nas quais esses protocolos foram fundamentados. Um exemplo são as proof keys), você entenderá mais facilmente como o Infocard, por exemplo, trabalha em sob um segundo plano. Além do mais, eles são protocolos muito interessantes

Kerberos

Kerberos v5 é um protocolo de autenticação usado em domínios Windows por padrão. Tecnicamente o Windows usa um protocolo de negociação chamado Simple Protected Negotiation (SPNEGO) para negociar entre o Kerberos e o Windows NT 4 challenge-response protocol (NTLM), mas o Kerberos é o protocolo preferido.

O nome Kerberos vem da mitologia Grega: é o cão de três cabeças que guarda a entrada de Hades (o engraçado é que o necessário deveria ser guardar a saída). As três cabeças representam as três partes envolvidas na transação: cliente, serviço, e o KDC - key distribution center, ou centro de distribuição de chaves. O KDC é o mantenedor dos segredos, e no Windows isto significa o controlador de domínio.

Cada usuário e computador em um domínio tem uma chave mestra, conhecida como master key. Para os usuários, esta chave é derivada de sua senha, através de um processo de encriptação conhecido como hashing. O KDC tem uma cópia desta master key de cada usuário e computador do domínio, e pode então atestar a sua identidade. De fato, é onde o KDC obtém o nome: seu trabalho é compartilhar a master keycom todos os usuários do domínio para que um usuário (por exemplo, Alice, possa usar para autenticar com um serviço que precisa ser configurado com credenciais de domínio válidas. Para dar um exemplo mais concreto, vamos dizer que o serviço neste caso seja uma aplicação web hospedada no IIS, onde o pool de aplicações seja configurado para executar sob uma conta chamada Bob.

Figura 1. Exemplo de um protocolo de autenticação Kerberos.

Quando Alice efetua o logon em sua estação de trabalho pela manhã, ela entra com sua senha. Sua estação de trabalho faz um hashing da senha para determinar a sua master key, que é usada para solicitar um ticket (ou bilhete) ao KDC. Este ticket inicial é chamado de Ticket Granting Ticket (TGT), e é usado por Alice até o fim do dia quando ela necessitar autenticar os outros serviços na rede. Os tickets de Kerberos contêm muitas informações, mas o mais importante é o nome do cliente (neste caso de Alice) em a proof key. Cada ticket é cifrado com a master key do serviço destino, e no exemplo de um TGT, o serviço destino é o próprio KDC.

Pense sobre isso por um momento. O KDC produz uma chave aleatória e põe-na junto com o nome de Alice em um bilhete, que seja cifrado de forma que Alice não possa ler. Como Alice descobre sempre a proof key? Bem, quando o KDC emite o TGT para a Alice, ele emite uma cópia da proof key para Alice para uso. Esta cópia é cifrada com master key de Alice. Você pode ver o KDC fazer seu trabalho aqui; ele está distribuindo uma proof key para que Alice use mais tarde! A estação de trabalho decifra a master key de Alice usando proof key e caches ao ticket junto com a proof key na sessão de logon da Alice. Enquanto Alice estiver logada na estação de trabalho, este ticket e a proof key permanecem em cache no Kernel para ela. Não há necessidade de Alice entrar com a sua senha novamente; ela negocia eficazmente sua senha através de um ticket do Kerberos.

Mais tarde quando Alice necessitar autenticar um serviço na rede (Bob neste caso), irá ao KDC e pedirá um ticket para esse serviço. A fim de provar ao KDC que é realmente Alice, ela apresenta o TGT o que recebeu anteriormente chamando o autenticador. Este é simplesmente o nome de Alice junto com um timestamp, cifrado com a proof key. Você pode ver a cadeia da evidência aqui: o autenticador age como a prova da posse da chave o KDC emitido a Alice com seu TGT. Devido ao fato desta proof key ter sido emitida originalmente cifrada com a master key de Alice, se Alice puder provar sobre sua proof key, o KDC tem a evidência que mostra que este é certamente alguém que sabe a senha de Alice.

Nota     Se você quiser os detalhes de como o KDC decifra o TGT, retire o nome de Alice e a proof key, e use este último para decifrar o autenticador. Se o nome no autenticador combinar o nome no TGT, isto mostra que a encriptação foi bem sucedida. O timestamp no autenticador é verificado contra um cache de replay, que grava uma janela dos autenticadores vistos recentemente (dentro dos últimos cinco minutos) para se assegurar de que alguém não repita simplesmente um autenticador antigo. Se os relógios estiverem, fora do programado, este autenticador será rejeitado junto com a observação do tempo atual de modo que o cliente possa repetir (o tempo não é um segredo, lembre-se, mas o Windows mantém os tempos de disparo sincronizados dentro do domínio por padrão a fim de otimizar este protocolo).

Assegurado uma vez da identidade de Alice, o KDC gera uma proof key aleatória para que Alice e Bob estabeleçam um ticket novo com nome de Alice, exatamente como antes. O KDC cifra o ticket com a master key do serviço (uma mistura da senha de Bob) e emite o bilhete de volta para Alice, junto com uma cópia da nova proof key que pode decifrar.

O cache da estação de trabalho, agora tem um segundo ticket junto com sua proof key na sessão de logon de Alice. Alice pode usar esta autenticação com o Bob durante todo o dia (todos os tickets do Kerberos têm tempos de expiração dentro deles; são projetados e duram por um único dia de trabalho).

Para provar sua identidade a Bob, Alice cria uma autenticação, cifra com a proof key no ticket de Bob, e emite isto junto com o ticket dele. Bob decifra o ticket e valida o autenticador exatamente como o KDC havia feito, cifra o timestamp no autenticador com a proof key, e emite de voltar para Alice como a prova que também conhece a chave. Se você pensar um pouco sobre isso, você poderá se convencer que Alice e Bob terminaram uma autenticação mútua. Bob tem a prova que seu par é Alice, e Alice tem a prova que seu par é Bob.

Nota     Se isto não estiver claro, recorde que Bob apenas provou a Alice que soube o valor da chave no ticket que emitiu. Lembre-se que o ticket esteve cifrado com a master key de Bob, assim que este diz a Alice que seu par sabe a master key de Bob. Isto ajuda impedir que um ataque do tipo spoofing sobre serviço de Bob.

Os tickets do Kerberos são usados também para saber a informação da autorização dos controladores do domínio aos serviços. Controladores do domínio Windows não somente mantém o nome do usuário no ticket do serviço, mas também a lista completa dos grupos do domínio em que o usuário é membro. Assim quando Bob recebe um ticket de Alice, está recebendo eficazmente um conjunto assinado das reivindicações do controlador do domínio. Uma daquelas reivindicações é a identidade de Alice, e o conjunto de reivindicações do grupo.

No espírito da legibilidade e da brevidade, eu falei sobre Alice e Bob como se faziam o trabalho aqui. Mas para que a plataforma forneça este código empacotado acima em um SSP - security service provider (fornecedor de serviço da segurança), uma DLL que ambos os servidores e clientes rodam. Quando você escreve um cliente ou um serviço, esta DLL estará automaticamente carregada enquanto você configurar seu código para usar o autenticador da plataforma. Eu estou certo que muitos de vocês permitiram o autenticador integrado Windows em IIS, e vocês nunca tiveram que se preocupar em decifrar tickets do Kerberos!

Kerberos, Senhas, e Smartcards.

O Kerberos tradicional confia em master key simétricas, e na maioria de sistemas “kerberizados” incluindo Windows, estas chaves são derivadas das senhas. Mas como eu mencionei anteriormente neste documento, as senhas são uma fonte realmente ruim para a geração de chaves criptografadas. A maioria dos seres humanos simplesmente não pode recordar que uma senha que seja forte bastante para sobreviver de ataques de força bruta ou dicionários offline. Dado que os tickets do serviço estão cifrados usando a master key do serviço, é imperativo que as senhas do cliente do serviço sejam  grandes, e geradas aleatoriamente. Uma vez que nenhum ser humano precisa se recordar destas senhas, não há nenhuma desculpa para não usá-la. Eu recomendo usar senhas geradas aleatoriamente , usando 20 caracteres, para cada conta de serviço que você criar. Isto lhe dará aproximadamente 128 bits da entropia.

Nota     O termo “simétrica” significa que a mesma chave será utilizada para cifragem e decifragem. Isto é diferente da criptografia de chave pública, onde chaves assimétricas são usadas. No último caso, as chaves do encriptação e decriptação são diferentes.

Mas não há nenhuma maneira que um ser humano recordará uma senha aleatória de 20 caracteres. Para tratar do lado humano das coisas, o Kerberos suporta uma extensão chamada PKINIT (public key cryptography for initial authentication). Isto permite que um cliente apresente um certificado ao KDC e prove o conhecimento de sua chave confidencial a fim de receber um TGT. Quando você loga através de uma sessão do smartcard no Windows, este é o processo que está sendo executado.

Um smartcard contém seus certificados e chave confidencial, junto com o código executável que pode executar a encriptação e utilizar direitos no cartão, assim suas necessidades confidenciais da chave nunca precisam ser carregadas na memória da estação de trabalho. E porque um PIN é requerido, se você perder o cartão, um hacker terá somente algumas poucas tentativas de adivinhações antes que o cartão se auto-destrua. Os smartcards não são 100% a prova de ataques. São somente paliativos resistentes, mas em termos práticos, eles auxiliam no retardo do ataque do atacante. Custa bastante tempo para revogar o certificado perdido até que o controlador do domínio não mais aceitá-lo Não há a menor comparação: O logon através de um smartcard é muito mais seguro do que usar uma senha simples. Mas é também mais complexo de administrar e implementar.

Mas como um desenvolvedor de aplicação que confia no autenticador da plataforma, você não precisa se importar. Pelo tempo que o ticket do Kerberos inicia seu serviço, não é necessário se preocupar com a autenticação de uma senha ou um smartcard. Somente se atente que você receberá um conjunto de assinado das reivindicações de uma autoridade confiada (um controlador do domínio) que pode usar e realizar decisões da autorização.

Isto é exatamente como deveria ser. Você pode deixar decisões de política de segurança para o IT onde sua aplicação é implementada. Um site poderia decidir que senhas são aceitáveis. Outro poderia querer login de smartcard. Sua aplicação normalmente funcionará em qualquer caso, se você confiar simplesmente  na autenticação de plataforma.

Certificados e Public Key Infrastructure (PKI)

A criptografia de chave pública é relativamente nova. Descoberto na década de 70, este sistema de criptografia (que usa intensivamente a matemática) permite usar uma chave para encriptação e uma chave completamente diferente para a decriptação. Isto simplifica troca de chaves porque a chave pública não é um segredo. Só é necessário manter as chaves privadas oculta aos olhares alheios.

Digamos que Bob gere um par de chaves RSA público/privado (RSA é o algoritmo público mais famoso, seu nome vem das iniciais dos seus três inventores). Contanto que ele mantenha a sua chave privada guardada consigo mesmo, ele pode publicar a chave pública dele em sua home page para que todos vejam. Na realidade, muitas pessoas usam uma ferramenta chamada Pretty Good Privacy (PGP) que faz exatamente isso. Se a Alice quiser enviar para o Bob uma mensagem secreta, ela pode adquirir uma cópia da chave pública dele e pode codificar uma mensagem, e agora a chave privada correspondente deve ser usada para decifrar aquela mensagem.

Nota Tecnicamente Alice geraria uma chave simétrica randômica para codificar a mensagem porque é simplesmente dispendioso demais codificar dados grandes com uma chave pública.Ela então codificaria esta chave simétrica com a chave pública de Bob, e enviaria a chave codificada junto com a mensagem codificada. Bob pode então ver a mensagem, decifrando a chave simétrica usando-a para decifrar a mensagem. Isto é determinado em qualquer sistema de chave pública, mas você ouvirá freqüentemente as pessoas que falam sobre codificar dados com uma chave pública, quando eles estão insinuando de fato o uso de uma chave simétrica subjacente.

Também é possível o Bob usar uma chave privada para encriptação para criar o que é chamado de assinatura digital (digital signature). Obtendo uma mensagem ele quer enviar para o mundo, e codificando aquele com a chave privada dele, qualquer um com a chave pública de Bob pode verificar a assinatura de Bob na mensagem.

Nota A função do ponto de criptografia é como uma checagem: ela pega uma mensagem de comprimento variável e computa um ponto de comprimento fixo daquela mensagem, tipicamente algo entre 20 e 32 bytes. Para mais informações em funções de ponto em criptografia, veja http://en.wikipedia.org/wiki/Cryptographic_hash_function.

Se a Alice receber uma mensagem assinada de Bob, ela pode decifrar a assinatura com a chave pública de Bob e obter o hash que o Bob calculou. Ela vê a mensagem recebida e compara o hash dela com o da assinatura de Bob e pode assim decidir se esta realmente foi a mensagem que a chave de Bob foi usada para assinar.

Ainda que as chaves públicas não sejam segredo, elas necessitam de alguma proteção. Imagine se um hacker, por exemplo, Mallory, tiver habilidade para invadir o Web Site de Bob e substituir a chave pública que ele está exibindo com a sua chave pública. Agora qualquer mensagem secreta que Alice enviar a Bob será encriptada com a chave de Mallory e assim ele pode ler as mensagens! E qualquer mensagem que Bob assinar pode ser alterada e assinada por Mallory, e a Alice não perceberá que está sendo enganada. O problema é que a chave pública de Alice a liga a Mallory, e ela acredita erradamente que é Bob.

Isto é onde o PKI entra. Pense em um certificado como uma pequena estrutura de dados que contém um nome e uma chave pública. Esta estrutura de dados inteira é assinada então por um terceiro, ligando o nome e a chave juntos. Usando PKI, o Bob apresentaria a chave pública dele a Verisign ou outra autoridade de certificado (CA - Certificate Authority). A Verisign executa os procedimetos corretos para verificar a identidade de Bob, e então constrói um certificado que contém o nome de Bob e chave pública, com a assinatura de Verisign que liga todos.

Quando a Alice vai para o Web Site de Bob e carrega o certificado dele, ela pode conferir a assinatura de Verisign (Verisign e muitos outro CAs têm chaves públicas famosas que são transportadas com a maioria dos sistemas operacionais). Se a assinatura de Verisign confirmar, ela confere com Verisign para ver se o Bob revogou a chave dele. Se tudo se confirmar e o certificado ainda não tiver expirado (a maioria dos certificados são válidos durante um a cinco anos), ela pode usar a confiança dela com a Verisign e acreditar que ela tem realmente a chave de pública de Bob.

Nota Em geral, o PKI permite cadeias de certificado onde uma raiz do CA emite para certificados para CAs intermediários que então assina certificados como Bob. Estas cadeias podem ser arbitrárias, com a idéia que é que você caminha sobre a cadeia até achar uma autoridade na qual confia. Contanto que a Alice confie pelo menos um CA na cadeia, ela pode usar o certificado de Bob com um grau de confiança.

Outro modo para pensar em um certificado é que uma declaração assinada por terceiros que diz, “Esta é a chave pública de Bob”. Ou até melhor, você pode pensar nisto como um conjunto assinado de reivindicações, muito como um tickets de Kerberos!

SSL e TLS

Secure Sockets Layer (SSL) e Transport Layer Security (TLS) (que é realmente a versão IETF-unificada de SSL), são protocolos de autenticação como Kerberos. A diferença é que eles dependem de criptografia de chave pública, certificados, e PKI.

SSL permite a Bob essencialmente provar a identidade dele a Alice apresentando o certificado e provando que ele sabe a chave privada correspondente. Isto deve ser bem familiar se você leu a seção sobre o Kerberos; a chave privada neste caso está sendo usada como um proof key. Se autenticação mútua é requerida, a Alice pode provar a identidade dela a Bob apresentando um certificado provando que ela conhece a sua chave privada. Isso é a mesma coisa que acontece com o Kerberos, sendo que o SSL faz o trabalho.

Em cenários business to business (B2B), é comum para ambas as partes usarem um certificado para autenticar. Mas certificados são de difícil controle para humanos administrarem. A menos que sejam armazenados em um smartcard, eles devem ser instalados na máquina do usuário, onde perdem muita mobilidade. Um certificado instalado em sua máquina no trabalho não será muito útil a você quando você precisa se autenticar de casa, enquanto que um smartcard pode ser levado com você para onde for necessário.

Assim, na maioria dos cenários de business-to-customer (B2C), enquanto o SSL pode ser usado para autenticar o serviço para os clientes através de um certificado, os clientes freqüentementes não terão um certificado deles próprios. Assim para alcançar autenticação mútua, o serviço solicitará para o usuário uma senha ou outra credencial. Neste caso, é essencial que o canal sobre o qual estas credenciais são enviadas seja codificado.

Canal de Integridade e Confidenciabilidade.

SSL/TLS e Kerberos não só provêem serviços de autenticação, mas também integridade e confidenciabilidade para a troca de informações. Uma vez que o “aperto de mão” de autenticação inicial tenha sido realizado, ambas as partes terminam com uma chave simétrica (freqüentemente chamada de chave de sessão) isso pode ser usado para derivar chaves para encriptação e proteção de integridade. Isto significa que sobre SSL/TLS e Kerberos, você pode (e deve) configurar sua comunicação examinando assinatura e codificação de todos os dados que passam entre você e o destino. O Windows Communication Framework (WCF) é configurado para fazer isto por padrão.

No cenário de B2C mencionado anteriormente, isto habilita o cenário comum onde uma aplicação Web usa um formulário para autenticar o cliente. Qualquer credencial enviada pelo cliente (tipicamente um nome de usuário e senha), e suas credenciais (e qualquer cookie emitido em resposta) pode ser protegido por SSL/TLS.

Criando Autenticação no Windows

Agora que você aprendeu os fundamentos de Kerberos e SSL/TLS, você pode estar desejando saber como os utilizar! Na maioria dos casos, pode configurar simplesmente a aplicação a qual está escrevendo para usar a opção seja qual for o sentido. Por exemplo, no IIS, você pode configurar um diretório virtual para requerer SSL uma vez que você montou um certificado de SSL para seu Web Site. Uma vez realizado, você pode configurar então se quer ou não requerer um certificado de seus clientes.

Se você estiver usando WCF, você pode configurar seu serviço com um certificado e usar SSL para se comunicar. Você tem a escolha de utilizar credenciais de cliente que você aceitará então, de uma senha simples para um certificado ou algo mais “exótico” como credenciais de Cardspace. Muitas outras tecnologias da Microsoft suportam SSL/TLS, como o SQL Server.

O Kerberos é suportado em todo o Windows. Esta é a autenticação embutida que você tem em RPC e no COM+. O WCF também suporta Kerberos.

Na versão 2.0 do .NET Framework, foram adicionadas classes de stream seguras que acrescentam SSL/TLS ou Kerberos para qualquer socket aberto. Se você estiver interessado, consulte as classes de System.Net.Security.AuthenticatedStream e seus derivados.

Onde Nós Estamos?

Kerberos e SSL/TLS são pilares de autenticação na plataforma de Windows. Estes protocolos são padrões de indústria e como tal, constantemente estão sujeitos à análise por criptógrafos ao redor do mundo. Você beneficia em muitas formas de usar estes protocolos:

· Sua infra-estrutura usa algoritmos e padrões de criptografias bem-analisados.

· Você não está criando um banco de identidade novo.

· Você adquire single sign on livre.

· Sua aplicação é mais fácil de implementar e manter.

· Sua aplicação será muito mais desejável pelo pessoal de IT.

Eu recomendo fortemente que você resista ao desejo para rodar seu próprio sistema de autenticação para aplicações que você constrói. Escreva menos código. Esteja mais seguro. Confie na autenticação de plataforma.

Recursos

Logon and Authentication Technologies

Authentication in ASP.NET: .NET Security Guidance

Autorização

Autenticando, o usuário responde a pergunta “Quem é você?”. A próxima pergunta é, “O que você pode fazer?” Isto é chamado autorização, e enquanto houver muitos modos de se chegar a isto, as melhores soluções sempre envolveram alguma forma de política (policy). Encapsulando sua estratégia de autorização em uma política que um administrador pode mudar junto as mudanças empresariais (ao invés de codificação diretamente isto em sua lógica empresarial) você está projetando uma solução mais ágil.

Uma política de autorização pode ser tão simples quanto um conjunto de grupos, ou tão sofisticado quanto uma política de Authorization Manager gravada no Active Directory que contém logon scripts empresariais que executam quando uma decisão de autorização não pode ser tomada baseada em regras estáticas simples. Como são muitas decisões de segurança, o mais simples sua política será, e mais fácil de administrar sem enganos de qualquer furo de segurança ou negar acesso a usuários legítimos.

Esta discussão assume que você está usando autenticação de plataforma como indicado na seção anterior. Isto lhe dá o conjunto mais rico de opções para autorização atuais, e tudo começa com grupos de Windows.

Grupos

Toda conta de usuário no Windows é membro de pelo menos um grupo. Um Grupo é o lugar mais natural para começar uma estratégia de autorização, porque o conceito básico de um grupo já é compreendido pelos administradores e desenvolvedores. Grupos agem como uma forma embutida de segurança: geralmente quantos mais grupos você pertença, maior acesso você terá.

Como um exemplo concreto, imagine você estar construindo uma aplicação para ajudar administrar um loja de animais. A aplicação tem que autorizar os usuários para executar várias tarefas, de administrar decisões de folha de pagamento a alimentar os animais. Um set de três grupos poderia ser tudo que você precisa:

· Gerentes

· Funcionários

· Clientes

Quando um usuário quer comprar um animal, a aplicação verifica o usuário é um membro do grupo Clientes. Quando um usuário quiser alimentar os animais, a aplicação confere se ele pertence ao grupo de Funcionários. Só o grupo Gerente pode dar aumentos, e assim por diante. O programa de instalação da loja de animais pode adicionar estes grupos automaticamente, e o arquivo de ajuda conta para o administrador o que estes grupos significam, assim ele pode acrescentar os usuários a estes grupos baseado no conhecimento desta loja de animais em particular.

Este é um uso simples de grupos na aplicação da Loja de Animais no seu desenvolvimento. Quando Bob estava empregado na Loja de Animais do Bob, ele era o único membro do grupo dos Gerentes. Mas quando for empregado na Loja de Animais do Shopping, haverá provavelmente vários Gerentes. Entretanto, os desenvolvedores do sistema não tiveram que preocupar com isto, porque tudo com o que eles se preocupam é se os usuários são ou não membros do grupo Gerentes. A identidade do usuário individual só entra em jogo quando a aplicação examinar as ações do usuário.

Usar grupos reduz o código para a loja de animais. O desenvolvedores não tiveram que escrever uma aplicação por administrar política de autorização, desde o sistema operacional provê ferramentas para administrar grupos. Outro benefício é que o administrador de sistema já sabe administrar grupos, assim nenhum treinamento é necessário.

Em um cenário corporativo, é provável que um administrador não nomeie os usuários diretamente aos grupos de uma aplicação, mas ele tirará proveito de grupo residentes no Active Directory para mapear grupos na aplicação da loja de animais. Esta técnica às vezes está referenciando a usar grupos de conta e grupos de recursos. Gerentes, Funcionários e Clientes são considerados os Grupos de Recursos, porque eles estavam definidos pela aplicação da Loja de Animais, um recurso que os usuários acessarão. Por outro lado, na Loja de Animais do Shopping, os administradores já designaram um conjunto de grupos por administrar os funcionários: os Empregados e Temporários. O administrador insere os usuários nestes grupos quando ele cria as contas para ajudar categorizar as contas na organização.

Figura 2. Grupos de Autorização.

Papéis

O exemplo de Loja de Animais é um caso especial de controle de acesso baseado em regras (RBAC role-based access control), onde a aplicação  usará grupos de Windows para suas “regras”. Gerentes, Pessoal e clientes foram às três regras lógicas que a Loja de Animais confiou.

Um das formas anteriores de RBAC na plataforma Windows foi introduzido através de Microsoft Transaction Server e depois incorporada no COM+. Este estilo de controle de acesso ficou muito popular com o passar do tempo, e a idéia de uma solução de RBAC generalizada foi percebida eventualmente em uma característica chamada Authorization Manager, ou AzMan. AzMan provê uma interface de usuário que permite um administrador gerenciar sua política de autorização, e um runtime que lhe permite executar acesso conferido à aquela política.

Nota O runtime do AzMan é instalado automaticamente com Windows Server 2003 e Windows XP. A interface de usuário para administrar políticas de AzMan deve ser instalada separadamente no Windows XP, via Windows Server 2003 Administration Tools Pack.

O AzMan resolve muito os problemas de soluções de RBAC prévias. Por exemplo, desde que grupos de Windows estão globalmente definidos, não por aplicação, você precisa assegurar que seus nomes de grupo não coincidam com os grupos de outra aplicação. O AzMan lhe permite criar um conjunto de política no Active Directory, ADAM, ou até mesmo em um arquivo de XML para prototipação rápida. Um armazenamento de AzMan pode ter uma ou mais políticas de aplicação específicas onde você define regras que fazem sentido para sua aplicação. Podem ser definidas regras de AzMan recursivas em termos de outras regras, assim eles são muito mais flexíveis as de COM+, e AzMan não é amarrado ao COM+ ou qualquer outra estrutura de comunicação. Você pode usar AzMan em qualquer aplicação.

Com o AzMan, o desenvolvedor concentra nas definições de operações que são a base para todos os controles de acesso executados pela aplicação em tempo de execução. Regras estão sendo definidas em termos de operações. Enquanto o desenvolvedor puder definir um conjunto de regras primeiramente, um administrador pode mais tarde adiocionar novas regras, ou definir regras para atender as necessidades de negócios. Podem ser unidas regras AzMan com os grupos do Windows, adquirindo assim maior flexibilidade para a solução baseada em grupo apresentada anteriormente, com a agilidade de uma política de AzMan. É o melhor de ambos mundos!

Figura 3. Regras de Autorização.

Na figura acima, são apresentadas três operações que a loja de animais precisa executar: Alimentação, Apresentação, e Venda de animais. Qualquer sócio pode executar estas operações. Para este desenvolvimento em particular, os grupos de funcionários e temporários são mapeados em uma regra de Staff. Esses mapeamentos também fazem parte da política de AzMan.

Existe mais conteúdo sobre Authorization Manager que pode ser encontrado em: Role-Based Access Control for Multi-tier Applications using Authorization Manager.

Discretionary Access Control

O controle de acesso baseados em regras na maioria das vezes é suficiente como uma solução de autorização para aplicações de linhas de negócio. Para outros sistemas mais genéricos, como o Gerenciador de Arquivos do Windows, registro, ou AD, é requerida uma solução mais genérica. Aí é que o Discretionary Access Control entra. Sobre esta estratégia de autorização, cada objeto individual tem uma lista de controle de acesso de discretionary (DACL - Discretionary Access Control List) isso define as permissões de usuários e grupos que podem executar operações nos objetos.

Nós usamos o termo discretionary porque cada objeto também tem um dono (owner). Se a Alice criar um arquivo, ela é a dona daquele arquivo. O dono tem o direito inalienável para ler e escrever no DACL dos arquivos e ela pode conceder a outros usuários e grupos quaisquer permissões que julgar apropriado. São concedidos os usuários permissões para o objeto à discrição do dono. Este não é o método mais apropriado para a maioria das aplicações de linhas de negócio, onde é melhor o administrador controlar (por política) quais usuários e grupos pode executar certas ações.

Se você estiver escrevendo uma aplicação que necessita de controle do DACL, o Windows suporta o Private Security Descriptor, que permite nomear um dono e DACL a cada objeto criado, embora esta seja uma técnica de programação muito mais avançada do que simplesmente usar AzMan!

Modelos de confiança

Ao construir sistemas conectados, você terá freqüentemente uma escolha de onde a autorização será executada. Uma opção, a personificação e modelo de delegação (impersonation and delegation model), onde o primeiro sistema simplesmente passa a identidade do usuário para um segundo sistema que executa uma checagem de acesso antes de executar a solicitação. A outra opção é o primeiro sistema executar a checagem de acesso que somente chamará o segundo sistema se o cheque de acesso tiver sucesso. Uma terceira opção é combinar estes modelos.

A escolha do modelo é importante. Pode impactar quão depressa e profundamente um ataque pode penetrar suas defesas. Também impacta no desempenho e escalabilidade. Fazer esta discussão concreta apresentará um típico data-drive em uma aplicação Web e apliquemos estes modelos de autorização. Os intercâmbios ficarão claros depressa.

Modelo de Subsistema confiado

Em um modelo de subsistema confiado, a aplicação de Web executa uma verificação de acesso para qualquer operação sensível. Se a verificação tiver sucesso, a aplicação usa sua própria identidade para se comunicar com o banco de dados. O banco de dados não tem nenhuma idéia de qual o usuário que está realizando a solicitação; o que todo o banco de dados vê é a solicitação que vem da aplicação, e que neste exemplo executa através de uma conta de usuário chamado WebApp. Enquanto o banco de dados pode executar um bit de uma autorização genérica, por exemplo, prevenindo tabelas antes de serem excluídas, a autorização realmente interessante tem que acontecer na aplicação Web onde a identidade do usuário é conhecida (Alice).

In the trusted subsystem model, the Web application performs an access check for any sensitive operation. If the check succeeds, the app uses its own identity to communicate with the database. The database has no idea who the actual user is; all the database sees is a request coming from the application, which in this example runs under a user account called WebApp. While the database can perform a bit of generic authorization, for example, preventing tables from being dropped, the really interesting authorization must happen in the Web application, where the user's identity is known (Alice).

Figura 4. Modelo de subsistema confiado.

Este modelo tem algumas características de desempenho. Por causa da aplicação só utilizar uma única identidade para conectar ao Servidor de SQL, a conexão se torna mais rápida. Porém, o Servidor de SQL tem que confiar na aplicação Web para autorizar o usuário, a aplicação e o banco de dados devem ter uma única unidade de confiança. Imagine que o SQL esteja vulnerável ou o buffer da aplicação esteja infectado todo o processo estará comprometido. (Para mais informação sobre como a vulnerabilidade do SQL, buffer infectado, entre outras, veja Writing Secure Code, Second Edition.) O hacker pode usar qualquer credencial imediatamente a aplicação de Web segura para montar um ataque no banco de dados.

Nota     O Banco de Dados não é o único lugar onde o agrupamento de conexão é útil; também no Active Directory através de System.Directory Services.

As unidades de confiança são como doce quebra queixo. Eles tem uma camada exterior dura, mas uma vez que isso é partido, o interior revela-se macio e delicioso!

Personificação e Modelo de Delegação

Neste modelo, a aplicação Web personifica o usuário original antes de comunicar com o banco de dados. Deste modo o banco de dados realmente pode ver que o usuário (Alice) pode fazer autorização muito mais efetiva. Neste caso, a própria aplicação Web não necessita ter qualquer permissão para usar o banco de dados! Se a aplicação Web chegou a um acordo, o hacker pode personificar os clientes para atacar o banco de dados, mas presumivelmente o nível de privilégio da maioria dos clientes será mais baixo reduzindo as probabilidades de ataque.

Outro benefício (o qual em muitos casos é uma exigência com as regulamentações de governo) é o Servidor de SQL poder examinar as ações do usuário original. Isto só funciona porque o servidor de SQL pode ver a identidade do usuário original.

Figura 5. Personificação e Modelo de Delegação.

Este modelo também tem suas desvantagens. Você pode ver como a Alice poderia falar diretamente com o banco de dados, sem passar pela aplicação Web? A permissão dela seria limitada e baseada na política de autorização do Servidor de SQL, mas esta pode ser uma preocupação em alguns casos. O agrupamento de conexão (Connection Pooling) não é muito efetivo se cada solicitação para o banco de dados vier de um usuário diferente. Isto impacta no desempenho. E finalmente, a menos que a Constrained Delegation seja utilizada, se a aplicação Web chegou a um acordo, as credenciais de Alice poderiam ser usadas por um hacker para perseguir outros sistemas na rede, não só o servidor de SQL!

Nota     Constrained Delegation é uma característica introduzida em Windows Servidor 2003 isso limita onde as credenciais podem ser usadas. Para mais informação sobre esta característica, veja The .NET Developer's Guide to Windows Security.

Modelo híbrido

Nada diz que você tem que escolher um destes modelos. Você pode usar uma combinação de dois! Para privilégios mais baixos, transações de alto volume, você pode decidir usar a identidade da aplicação Web para acessar o banco de dados, como no modelo de subsistema confiado. Você terá o benefício de agrupamento de conexão onde mais necessita. Mas para alto privilégio, transações de baixo volume façam o Servidor SQL requerer a identidade do solicitante original. A aplicação Web somente personificar o solicitante antes de fazer um pedido de alto-privilégio.

Pense em com que freqüência você administra uma aplicação Web. Se um administrador efetuar o logon apenas uma vez por semana na aplicação de Web, a necessidade de personificar aquele administrador é ínfima comparada ao benefício de não permitir a aplicação Web usar sua própria identidade para executar as mesmas operações de alto-privilégio!

Onde Nós Estamos?

O Windows tem um suporte rico para autorização, assim não há necessidade para montar sua própria infra-estrutura de autorização. Se você confia em grupos ou usa o Authorization Manager, você deveria focar em separar a política de autorização do código de sua aplicação. Isto lhe dá maior agilidade; um administrador pode reconfigurar a autorização a qualquer hora para ajustar às necessidades de negócio.

Considere os modelos de autorização diferentes discutidos aqui. Há cuidados de segurança e desempenho com cada modelo que devem ser considerados, e eu realcei estes pontos, assim você terá um trabalho mais fácil que toma uma decisão em um determinado cenário.

Recursos

Role-Based Access Control for Multi-tier Applications using Authorization Manager

Trust Technologies

Authorization and Access Control Technologies

Desenvolvendo Aplicações .NET orientadas a identificaçãoIdentity-Aware

O .NET Framework disponibiliza muitos recursos para construir aplicações identity-aware e directory-enabled de forma mais fácil. A maioria das pessoas com quem falo, ficam surpresas com as poucas linhas de código que são necessárias para montar este tipo de aplicação.

Nesta seção, eu explicarei o “Zen” de identificação no .NET Framework. Então eu mostrarei como conectar a um Active Directory e visualizar dados sobre seus usuários (e-mail, números de telefone, e assim por diante) que você pode usar em sua aplicação. Finalmente, eu aprofundarei no AzMan e apresentarei como executar acesso baseado em política de AzMan.

Abstrações de identidade em .NET

O .NET Framework define duas interfaces muito simples para representar identidade. São elas:

  namespace System.Security.Principal
{
    public interface IIdentity
    {
        bool   IsAuthenticated    { get; }
        string Name               { get; }
        string AuthenticationType { get; }
    }
    public interface IPrincipal
    {
        IIdentity Identity { get; }
        bool IsInRole(string role);
    }
}

  

A divisão da identidade em duas interfaces mostra ser uma decisão inteligente. Pense deste modo: IIdentity representa os resultados de autenticação, enquanto responde a pergunta “Quem é você?”, enquanto que IPrincipal representa os resultados de autorização, respondendo a pergunta, “O que você pode fazer ?”. Em alguns casos você não acaba respondendo ambas as perguntas usando a mesma infra-estrutura. Um exemplo onde isso é verdade, está na autenticação utilizada ASP.NET. Neste caso, a identidade do usuário é fornecida por um membership provider, enquanto as regras são fornecidas por um role provider.

A implementação mais simples destas interfaces é através das classes GenericIdentity e GenericPrincipal. Se você estiver executando sua própria autenticação e infra-estrutura de autorização, pode usar estas classes para representar identidades e regras, mas como você aprendeu esperançosamente neste artigo, é muito melhor confiar em autenticação de plataforma sempre que for possível.

Na seção anterior sobre autorização, eu introduzi o conceito de regras. Chamar IPrincipal.IsInRole é o modo mais direto para testar se o usuário é um membro de uma regra. Neste nível de abstração, sua aplicação não precisa realmente se preocupar se a regra é implementada por um grupo do Windows, uma regra AzMan, ou qualquer outro modo. Isto lhe permite escrever código que requer autorização sem preocupar qual o mecanismo de autorização utilizado.

WindowsIdentity e WindowsPrincipal

Se você estiver usando autenticação de plataforma, estas são as classes que representarão os usuários com contas Windows. O WindowsIdentity se encapsula sobre um token do Windows, que é recebido ao estabelecer um logon por autenticação de plataforma. Dentro do token está o nome do usuário, um identificador de segurança (SID – Security Identifier), junto com os SIDs de cada grupo no qual o usuário é um membro. O WindowsPrincipal simplesmente permite que você teste se o usuário é um membro de um grupo. Neste caso, quando você chamar IsInRole, você especificará um nome de grupo completamente qualificado (fully qualifield), como " MyDomain\MyGroup ".

A primeira vez se realiza uma chamada IsInRole para chamar um domínio ou nome de máquina em seu código, você sentirá um pouco inseguro. Nesse caso, isso é um instinto bom: você não deveria ter estes detalhes de desenvolvimento de código em suas aplicações. Há vários modos que você pode fatorar estes detalhes de desenvolvimento. Por exemplo, você poderia usar AzMan para definir regras lógicas que o administrador pode mapear sobre grupos a tempo de implementação, e então definir uma classe AzManPrincipal que implementa IsInRole para conferir regras AzMan. Então, depois de autenticar o usuário, através do Windows Principal você adquire e substitui uma instância de sua classe de AzManPrincipal. Este é um grande exemplo de como é útil ter IIdentity e IPrincipal como interfaces distintas!

Thread.CurrentPrincipal e PrincipalPermission

Os desenvolvedores do .NET Framework sabiam que você confiaria em deixar a plataforma para fazer o trabalho pesado de autenticação ao usuário e obter os atributos de autorização tais como grupos ou regras. Assim eles embutiram um mecanismo como ASP.NET e WCF para identificar e autorizar o usuário no código de aplicação.

O Thread class expõe uma propriedade estática (Thread.CurrentPrincipal), que  examina a sua autenticação na aplicação para ser utilizada posteriormente.. Ela fornece a representação do usuário no IPrincipal, o qual você pode obter o IIdentity correspondente, determinando se o usuário é autenticado, adquirindo o seu nome, configurando funções, etc. Ele trabalha até mesmo em ambientes de multi-threaded; onde cada thread de execução terá seu próprio dono.

Se preferir programação declarativa, você pode usar o atributo PrincipalPermission para executar estas checagens. Isto lhe permite simplesmente declarar as necessidades de autorização de qualquer método, e a cada tempo JIT (JIT Time), o compilador emitirá cheques sobre o Thread.CurrentPrincipal, assegurando no começo do método que suas demandas são conhecidas. Se o usuário não satisfizer os critérios de sua demanda, uma exceção será lançada e o método não será executado. Aqui está um exemplo:

  using System.Security.Permissions;
 
class InvoiceManager {
    [PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
    void Submit(Invoice invoice)  { ... }
    [PrincipalPermission(SecurityAction.Demand, Role="Manager")]
    void Approve(Invoice invoice) { ... }
    [PrincipalPermission(SecurityAction.Demand, Role="Accounting")]
    void Pay(Invoice invoice) { ... }
}

  

Neste caso, qualquer autenticação de usuário pode submeter uma fatura, mas ela necessitará do Gerente para aprovar faturas, e a Contabilidade para pagar. Este é um modo para auto-documentar os requerimentos de autorização de uma classe, porque estes atributos podem ser depois extraídos com ferramentas como PERMVIEW.EXE, ou através de desenvolvimento pela interface de meta data do CLR.

Programando para Serviços de Diretório

Uma vez você tem um WindowsIdentity para um usuário, usar as classes no namespace de System.DirectoryServices fazer um lookup da conta do usuário Active Directory e descobrir todos os tipos de informação sobre ele:

· Qual é o número de telefone dele ou endereço de e-mail?

· Em que escritório ele trabalha?

· Quem é o gerente dele?

· A quem ele se reporta diretamente?

· Qual o ID Funcional dele?

Você poderia esperar que código para fazer isto é  realmente complicado, mas é surpreendentemente fácil:

 public string LookupEmail(WindowsIdentity id) {
    using (DirectoryEntry user = LookupUser(id)) {
        return (string)user.Properties["mail"].Value;
    }
}
DirectoryEntry LookupUser(WindowsIdentity id) {
    string path = string.Format("LDAP://<SID={0}>", id.User);
    return new DirectoryEntry(path, null, null, SECURE_BINDING);
}
AuthenticationTypes SECURE_BINDING =
    AuthenticationTypes.Secure  | // use platform authentication
    AuthenticationTypes.Signing | // use integrity protection
    AuthenticationTypes.Sealing;  // use encryption
 

 
  

O truque é usar uma técnica chamada SID blinding, onde você adquire o identificador de segurança do usuário (SID) da propriedade de WindowsIdentity.User que foi introduzida em versão 2.0 do .NET Framework. Então você tem um valor fora do Active Directory um objeto de DirectoryEntry que representa a conta do usuário. Este exemplo observa o endereço de e-mail do usuário, mas seria da mesma forma adquirir as outras propriedades listadas acima.

Caso você aprenda mais sobre programar serviços de diretórios, você também deveria gastar algum tempo se familiarizando com o schema que Active Directory provê por padrão. Há uma tonelada de informações aqui que você pode utilizar em suas aplicações, e o administrador de sistema estará muito contente que você esteja confiando em uma única fonte de verdade para dados de usuário em vez de ainda criar outro banco de identidade para armazenar estes tipos de detalhes! O schema é documentado no MSDN.

Por que vendedores de software independentes constroem aplicações que serão implementadas em muitas empresas diferentes? Nem todas essas companhias têm Active Directory, você deve estar pensando. Mas este é o ponto: A maioria das empresas atualmente tem o Active Directory, e as que não tem, a grande maioria das companhias armazena as contas de usuários em um serviço de diretório acessível por LDAP. É uma idéia muito boa para construir soluções que atendam estas características ao invés de construir seu próprio banco de identidade. Se encontrar em uma situação onde não há nenhum serviço de diretório, considere implementar o ADAM para armazenar as contas de usuários que lhe permite usar System.DirectoryServices com o mesmo schema esperado no Active Directory. A técnica utilizada será diferente neste caso, mas o modelo de programação é o mesmo.

ADAM é um tópico interessante por si só. Ele é um serviço de diretório LDAP completo desenvolvido baseado na base de código de Active Directory, mas sem todo o sistema operacional de Rede (NOS – Network Operating System) infra-estrutura com a que você provavelmente não se preocupará se você precisa somente do LDAP ou diretório de aplicação. Tem a mesma característica de replicação do Active Directory e executa em qualquer máquina (não só controlador de domínio). Eu estou executando enquanto eu escrevo este documento em meu Windows XP, o qual facilita a programação com System.DirectoryServices sem ter um controlador de domínio ao redor! É fácil instalar, como você pode ver neste documento.

Para maiores informações, de programação com System.DirectoryServices, veja  The .NET Developer's Guide to Directory Services Programming.

Programando para o Authorization Manager (AzMan)

O AzMan expõe um modelo de programação rico, que lhe permite realizar qualquer tarefa que o GUI pode fazer. Você pode definir aplicações inteiras, inclusive regras, operações, e assim por diante, através de programação. Mas na grande maioria das aplicações, você não deverá se preocupar sobre tudo disso, pois o snap-in para AzMan do Console de Administração Microsoft (MMC - Microsoft Management Console) disponibiliza uma interface de fácil utilização para realização destas tarefas.

Como um desenvolvedor, há um objeto de AzMan com o que você realmente se preocupará, que é o objeto de contexto de cliente. Este objeto implementa IAzClientContext, que retorna para AzMan sobre seu cliente assim AzMan pode determinar que regras e operações estão inseridas para serem executadas. Para adquirir um destes objetos, você precisará conectar primeiro para uma política (policy) armazenada no AzMan e abrir sua aplicação dentro desta política. Aplicações nas políticas do AzMan lhe permitem definir regras e operações específicas a sua aplicação.

Quando apresentei a autorização e regras, mostrei um quadro de como grupos Windows podem mapear sobre as regras de AzMan que então mapeiam sobre as operações com que seu programa deve se preocupar. Naquele exemplo, mostrei como Alice que é um membro do grupo Empregados, é mapeado pelo AzMan sobre a regra de Funcionários dentro da loja de Animais. Em virtude de estar no papel de Funcionários, é concedido o acesso a Alice a várias operações: Alimentação, Apresentação, e Venda de animais. IAzClientContext é como se sua aplicação deixa AzMan saber em que grupos que Alice pertence, e também é como AzMan apresenta quais operações Alice pode executar.

Há vários modos para criar um AzMan de objeto de contexto de cliente. O mais simples é quando você usa a autenticação de plataforma e tem um WindowsIdentity para seu cliente. Lembre-se que WindowsIdentity é realmente só um invólucro ao redor de um token Windows de acesso. É aquele token que mantém o SID de usuário e grupo, e isso é o que AzMan necessita para construir um objeto de contexto de cliente.

A seguir um exemplo de classe que conecta para uma armazenamento de AzMan e cria contexto de cliente para uma aplicação baseada em objetos de WindowsIdentity. Usando uma classe de invólucro, ajuda a reduzir a área de superfície de AzMan para expor só as características de suas necessidades.

  using System.Security.Principal;
using Microsoft.Interop.Security.AzRoles;
 
public class AzManApplication {
    IAzAuthorizationStore store = new AzAuthorizationStoreClass();
    IAzApplication app;
    public AzManApplication(string connectionString, string appName) {
        store.Initialize(0, connectionString, null);
        app = store.OpenApplication(appName, null);
    }
    public AzManClientContext CreateClientContext(WindowsIdentity user) { 
        IAzClientContext ctx =
            app.InitializeClientContextFromToken(
                (ulong)user.Token.ToInt64(), null);
        return new AzManClientContext(ctx);
    }
}

  

A string para uma política AzMan é armazenada de duas formas, dependendo de onde está armazenada sua política: em um arquivo de XML (ótimo para protótipos) ou em um AD/ADAM (melhor para sistemas de produção):

Exemplo de Strings de conexão XML: msxml://c:\temp\mystore.xml

Exemplo de string de conexão com AD: msldap://cn=MyStore,cn=Program Data,dc=Fabrikam,dc=com

Exemplo de string de conexão ADAM: msldap://servername:port/cn=MyStore, cn=Program Data,dc=Fabrikam,dc=com

Uma vez aberta uma aplicação de AzMan, você está pronto para autorizar os clientes, e realizar o que precisa de um objeto de contexto de cliente no AzMan. A classe de invólucro abaixo mostra como construir um objeto de contexto de cliente AzMan em um WindowsIdentity. Note que é o token de acesso do Windows que é usado pelo AzMan para descobrir os grupos do usuário, que então mapeiam para as regras e operações do AzMan.

Uma vez você tem um objeto de contexto de cliente para o usuário, é necessário configurar quais as permissões que o usuário tem para executar qualquer operação solicitada. Você faz isto chamando AccessCheck no contexto de cliente, como mostrado pela classe abaixo. Esta função é um pouco complicada de chamar,  sendo que o melhor é ter uma classe auxiliar como a apresentada aqui.

  public class AzManClientContext {
    IAzClientContext ctx;
    public AzManClientContext(IAzClientContext ctx) {
        this.ctx = ctx;
    }
    public void DemandOperation(int opNum) {
        object[] operations = { opNum };
        object[] results = (object[])ctx.AccessCheck("",
            null, operations, null, null, null, null, null);
        int result = (int)results[0];
        if (0 != result) {
            throw new Exception("Access Denied");
        }
    }
}

  

Tanto ASP.NET e WCF suportam a arquitetura AzMan de role provider que foi introduzida em ASP.NET 2.0. Esta arquitetura só realiza regras entretanto; não usa o regra-para-operação apresentado neste documento. Mas o seu uso é simples e não lhe exige que se realize chamadas constantes do AzMan. Essencialmente o modo de trabalho é que um módulo de autorização do ASP.NET é executado para toda a solicitação, mapeando o em um contexto de cliente do AzMan, que lê as regras daquele objeto e incrementa um IPrincipal que a aplicação pode usar para encontrar as regras de AzMan. O benefício aqui é que você não tem que confiar diretamente em quais grupos pertencia, um ponto discutido na seção de autorização deste documento. Para aprender mais sobre este recurso, leia How To: Use Authorization Manager (AzMan) with ASP.NET 2.0 de  Patterns & Practices group.

Eu realmente só tenho apresentado superficialmente as capacidades de AzMan neste documento, mas a maioria das aplicações não precisam muito mais que as características que eu demonstrei aqui! Simplesmente dividir as decisões de autorização em um armazenamento de política do AzMan fará a sua aplicação mais fácil de manter durante os anos.

Onde Nós Estamos?

O.NET Framework sabiamente abstraiu a identificação em duas interfaces genéricas. IIdentity representa os resultados de autenticação, e várias IPrincipal representam um conjunto de atributos genéricos de autorização chamado regras. Se você confiar em autenticação de plataforma, você terminará com implementações destas interfaces baseado em tokens de acesso do Windows, e as regras estarão em grupos destes tokens.

Thread.CurrentPrincipal é um modo utilizado para comunicar identificações nas aplicações. PrincipalPermission é um modo para implementar esta característica e construir uma auto-documentação de código. E se você tiver um WindowsIdentity para seu usuário, você pode chamar facilmente no Active Directory para adquirir mais informações sobre ele, como o endereço de e-mail ou número de telefone.

Enquanto é possível programar checagens de acesso baseadas diretamente em regras dos grupos do Windows, você pode ter problemas porque nomes de grupo incluem domínio ou nomes de máquinas, e é uma má idéia escrevê-los diretamente no código. Utilizando o AzMan para mapear grupos em cima de regras, e regras em cima de operações, lhe dá muito mais flexibilidade a um custo baixo, e é o melhor modo de administrar sua política de autorização. Considere a construção de algumas classes de invólucro apresentadas para simplificar sua comunicação com o AzMan. Você deveria considerar seriamente armazenar também sua política de AzMan em um Active Directory ou ADAM quando você publicar sua aplicação.

Recursos

Active Directory Schema

How To: Use Authorization Manager (AzMan) with ASP.NET 2.0

Bundling ADAM with your applications

Identificação federada

No início deste documento eu encorajei que você evitasse criar bancos de identidade. Cada aplicação que tem seu próprio grupo de usuários privados simplesmente acrescenta ao fardo para as áreas de IT e suporte, além do que os usuários precisam se lembrar de outro conjunto de credenciais. Se orientar a autenticação integrada do Windows é um excelente modo de evitar criar outro banco de usuários. Mas ainda, há outro passo para redução de custos na aplicação: Suporte a Identificação Federada.

O Problema

Considere duas organizações que são parceiras entre si. Talvez esta seja uma cadeia de valor (supply chain) entre parceiros, onde os empregados de uma companhia industrial precisam acessar aplicações Web e serviços disponibilizados por um fornecedor. Como o fornecedir deveria autenticar os empregados da companhia industrial? Eles não compartilham um domínio Windows, e não está na mesma floresta do Active Directory. Além disso, um parceiro pode estar usando Active Directory enquanto o outro pode estar usando uma plataforma completamente diferente!

No passado, a solução era emitir credenciais aos empregados da companhia industrial que precisava acessar os recursos do fornecedor. Mas isto resultava um outro conjunto de credenciais para o empregado administrar, e outra conta de usuário para a pessoa do IT administrar. Estas contas tipicamente vem com um certificado, no qual o fornecedor precisa manter uma infra-estrutura de Chaves Públicas e de publicação de certificados.

Figura 6. Exemplo de Autenticação Limitada

A Autorização também se torna problemática. Quando um empregado na companhia industrial é promovido, ela pode precisar de um nível diferente de privilégio quando acessar o Web Site do fornecedor. Isto significa que alguém tem que se lembrar de chamar o IT e o fornecedor para fazer estas mudanças de política. Será que não há meios mais fáceis que a empresa possa executar tudo isso?

Introdução à Identificação Federada

No exemplo, eu mostrei há pouco, que existe um nível de confiança presente entre o fornecedor e o fabricante. O fornecedor tem que confiar no fabricante para dizer quais empregados deveriam ser permitidos usar as aplicações Web e serviços do fornecedor, e que nível de privilégio cada empregado deveria ser concedido. A identidade federada automatiza esta confiança usando uma suíte de protocolos do WS - *. Quando estas duas organizações decidirem federar, haverá mais necessidades do fornecedor para criar contas de usuário para os empregados do fabricante. Ao invés disso, as aplicações Web e serviços do fornecedor comunicarão usando WS-Federetion automaticamente, enquanto permite ao fabricante autenticar seus próprios empregados.

Figura 7. Exemplo de Identidade Federada.

Identidade federada também simplifica a autorização. Como você verá brevemente, o mesmo token de segurança que leva a identidade do usuário também pode levar reivindicações de autorização. Realmente, um token pode não ter nenhuma reivindicação de identidade, servindo somente para indicar que o usuário é autorizado para alguma ação sem identificar quem é aquele usuário. Com uma solução de federação integrada como Serviços de Federação de Diretório Ativos (ADFS - Active Directory Federation Services), assim que um empregado seja promovido, sua conta no Active Directory é atualizada refletindo estas mudanças, as reivindicações enviarão imediatamente aos parceiros da organização a mudança que reflete o novo status. O fornecedor poderá então autorizar que ele acesse recursos que fazem sentido ao novo trabalho, sem ter que mudar sua política de segurança.

A identidade federada está em toda parte a fim de automatizar relações de confiança existentes e reduzir custos. Comecemos explorando este conceito mais adiante, olhando para uma implementação concreta de WS-Federation chamado Active Directory Federation Services (ADFS).

Serviços de Federação de Diretório Ativos (ADFS)

ADFS foi liberado em dezembro de 2005 com o Windows Server 2003 R2. Este é um produto fácil para organizações que usam o Active Directory para federar com parceiros de organização que têm implementações compatíveis da WS-Federation com perfil passivo. Se o parceiro de organização estiver executando o Active Directory, eles também podem instalar ADFS para apoiar identidade federada. Caso contrário, o parceiro tem que estar usando um produto compatível como Tivoli Federated Identity Manager from IBM.

Nota     WS-Federation especifica ambos os perfis ativos e passivos. A diferença entre os dois é simplesmente o tipo de software cliente. Perfil passivo é onde o cliente usa um Web Browser para acessar recursos onde nós não podemos fazer muitas suposições: nós assumimos que o browser que suporta cookies e SSL, mas não muito mais que isso. O perfil ativo assume uma aplicação de cliente muito mais inteligente, que pode executar operações de criptografia e assim pode melhorar a eficiência do sistema consideravelmente.

Para esta discussão, imagine que o fabricante e fornecedor do meu exemplo estão usando Active Directory com ADFS. Em terminologia de ADFS, o fabricante é chamado de parceiro de conta (account partner), porque nesta relação em particular, é onde os usuários e suas contas residem. O provedor é chamado de parceiro de recurso (resource partner), porque é onde as aplicações de Web (os recursos) estão hospedadas.

Nota Qualquer organização que usa ADFS pode fazer ambos os papéis simultaneamente; talvez o fabricante aja como um parceiro de recurso para seus concessionários, por exemplo.

Como qualquer bom projeto de serviço de segurança, o ADFS se esforça para ser tão transparente quanto possível. Uma vez que, ambas as organizações acrescentaram as relações de confiança correspondentes no ADFS, os empregados do fabricante podem navegar entre as aplicações Web pelo provedor sem ter que prover um segundo conjunto de credenciais. Pode haver pequenos “flashes” na primeira vez que o browser do empregado é redirecionado entre o local que hospeda a aplicação de Web e os recursos, e os servidores de federação de conta, mas o resultado final é um single sing on do usuário.

Figura 8. Active Directory Federation Services (ADFS)

Eis o que acontece no cenário:

1. O empregado do Fabricante aponta no browser para uma aplicação Web do Provedor. O agente single sign on de ADFS na aplicação Web notifica que o pedido chegou sem um cookie de ADFS, e assim redireciona o browser do cliente ao servidor de federação do Provedor.

Nota O agenteADFS SSO é um HttpModule que você instala em aplicações que precisam  suportar a identificação federada por ADFS.

2. O servidor de federação do Provedor determina de qual conta de parceiro é a requisitante deste pedido (há só um parceiro neste caso, mas este passo pode requerer uma sugestão do usuário, talvez questionando qual a organização ele pertence). Ele redireciona o browser do cliente ao servidor de federação do fabricante.

3. O servidor de federação do Fabricante desafia o cliente para provar a identidade dela a partir de uma autenticação de Windows integrada.

Nota           Há alternativas para autenticar o cliente (baseada em formulários de logon ou em um certificado de cliente, por exemplo), mas a autenticação integrada é recomendada pelos motivos que eu tenho falado durante este documento.

4. O usuário é autenticado utilizando a conta de domínio do Active Directory.

5. Se o usuário é autenticado com sucesso, o servidor de federação emite um token de SAML que contém um conjunto de reivindicações que a organização consegue entender. Eu falarei mais sobre estas reivindicações neste documento. O Token é serializado na URL no o browser do cliente é redirecionado atrás ao servidor de federação do provedor.

Nota SAML = Security Assertion Markup Language.Um token consiste em um XML que inclui um conjunto de reinvindicações assinadas pelo emissor do token.

6. O servidor de federação do servidor lê o token de SAML, verifica que foi assinado por um parceiro válido, e emite um cookie contendo um token de SAML assinado pelo servidor de federação. Este token conterá um subconjunto das reivindicações recebido do servidor de federação do Fabricante. O browser do cliente é redirecionado agora para a aplicação Web original que ela estava tentando acessar primeiramente.

7. O Agente single sign on da Web lê o cookie, a assinatura é verificada no token de SAML do servidor de federação do Provedor, e faz as reivindicações disponíveis para a aplicação de Web por uma classe chamada SingleSignOnIdentity (esta classe implementa Identity e está disponibiliza as propriedades HttpContext.User e Thread.CurrentPrincipal).

Virtualmente todo o trabalho que eu descrevi nestes passos é controlado exclusivamente pelo ADFS e o Active Directory o que significa que como um desenvolvedor de uma aplicação Web, seu trabalho principal é tomar decisões de autorização simplesmente baseado nas reivindicações fornecidas com a requisição. Isto pode ser tão fácil quanto fazer chamadas a IPrincipal.IsInRole, e talvez examinando o valor da propriedade de IIdentity.Name, ou pode ser tão robusto quanto as regras existentes em um contexto de segurança AzMan baseado em reivindicações de grupo providos pelo objeto SingleSignOnIdentity.

Reivindicações, Transformações, e Security Token Services

Neste momento você poderia estar desejando saber o que é uma reivindicação e de onde vem. O ADFS, originalmente veio do Active Directory. Por exemplo, o nome principal, alice@fabrikam.com, é uma reivindicação de identidade que identifica o usuário e pode ser usada para examinar as ações dele. O ADFS também suporta reivindicações de grupo, e pode ser configurado para emitir uma reivindicação para um usuário se ele for um membro de um grupo de Active Directory específico. E finalmente, ADFS apóia reivindicações customizadas que simplesmente são pares de nome-valor. Estas reivindicações são enviadas para as propriedades do usuário de um Active Directory. Você pode configurar ADFS para extrair diretamente das propriedades de usuário do Active Directory; por exemplo, o número de telefone do usuário poderia ser exposto como uma reivindicação. Outros sistemas além de ADFS poderiam suportar outros tipos de reivindicações, mas cada reivindicação é identificada por um URI que ajuda todo o mundo para concordar sobre qual reivindicação utilizar.

Imagine que a companhia industrial do meu exemplo tem um grupo chamado InventoryManagers, e os membros daquele grupo precisam ser autorizados para usar um formulário de ordem de compra que faz parte da aplicação de Fornecedores na Web. Os fornecedores não necessariamente precisam ter um grupo com aquele mesmo nome. Isto é onde as reivindicações entram: nós precisamos converter as quais reivindicações daquele sistema sabem aproximadamente sobre um parceiro federado. Talvez na aplicação de fornecedores da Web os usuários que são autorizados para acessar as partes da ordem de compra têm que apresentar uma reivindicação de grupo nomeada OrderClerks. Neste caso, nós necessitamos que o servidor de federação do ADFS possa emitir uma reivindicação de grupo OrderClerks para qualquer um no grupo de InventoryManagers. Isto é o tipo de mapeamento que você pode configurar em ADFS quando você federar com um membro parceiro. E se este tipo de mapeamento estático não for suficiente, você sempre pode compilar e registrar um módulo de transformação de reivindicações, como o que o .NET Assembly que contém uma classe que implementa IClaimTransform. Isto lhe permite inspecionar as reivindicações providas por ADFS e adiciona ou remove reivindicações conforme necessário.

Como você provavelmente pode imaginar, transformações de reivindicações são realmente importantes na federação. Toda companhia tem sua própria “linguagem” para representar identidade e informação de autorização como as de grupos. Permitindo o parceiro de conta prover estas reivindicações diretamente, o parceiro de recurso está adquirindo sempre a informação mais atual. Se um empregado é adicionado ou removido de um grupo, da próxima vez que ele logar, todos os parceiros de recurso que ela acessa há versão da mudança.

Na Transformação de reivindicações é importante que haja um nome de fato para um serviço executar estas transformações: é chamado um Serviço de Token de Segurança, (STS - Security Token Service). Um STS leva um conjunto assinado de reivindicações como contribuição e produz um conjunto assinado de reivindicações como produção. O servidor de federação que faz parte de ADFS (apresentado anteriormente no diagrama de ADFS) é um exemplo de um STS. O servidor de federação da companhia industrial (STS) leva como contribuição um ticket de Kerberos do browser do usuário e converte isso em um token de SAML que o provedor possa entender. Isso é realmente só um exemplo de uma transformação de reivindicação. O ticket de Kerberos é um conjunto de reivindicações assinado pelo Active Directory, enquanto o token de SAML é um conjunto de reivindicações assinado pelo servidor de federação. Na realidade, generalizando esta idéia de reivindicações através de tecnologias de tokens de segurança conduz a um conceito muito poderoso, o metasystem de identidade.

O Meta Sistema de Identidades

Tickets Kerberos, certificados X.509, e tokens de SAML, oh meu! Estas tecnologias (e muitas outras) são usadas para comunicar a identidade de informação entre sistemas, muito parecido com Ethernet, Token Ring, e outras redes físicas que levam sinais entre computadores. Mas não era até que o mundo concordasse que TCP/IP que a Internet como nós conhecemos isto hoje pôde florescer. Existem alguns encapsulamentos de protocolo que nos permitiram atravessar a ponte entre sua rede de Token Ring e meu Ethernet antes da transmissão dos dados.

Você pode imaginar um futuro onde autenticar um usuário seria tão fácil quanto conectar a um servidor Web? Oh, a inovação que seria possível em todo o mundo! Claro que nós temos que moderar nossa excitação lembrando que para toda grande característica projetada por nós, há um sujeito ruim que tenta entender um modo para explorar isto lá fora. Ao contrário com TCP/IP, nós estamos considerando o mais recente para depois considerar o tardar.

Para promover um sistema que respeita o direito do indivíduo a privacidade, um conjunto de leis foi proposto por Kim Cameron. Estas sete leis de identidade (http://www.identityblog.com/?page_id=354) emergiu depois de muita consideração por uma coalizão larga de pensadores de identidade principais que levaram parte na discussão no blog de Kim a www.identityblog.com. A maioria vasta destas pessoas não são empregados da Microsoft, qualquer um (leve Doc Searls por exemplo, o editor sênior de Jornal de Linux). A opinião emergente é que um sistema de identidade não pode ser estável, isto é, ele falhará ou simplesmente será inaceitável se quebrar quaisquer destas leis.

De forma bastante interessante, um destes estados de leis que não há identidade tecnológica ou operador que satisfará todas as necessidades em todos os contextos utilizados por que nós, e é por isso que precisamos de um meta sistema (metasystem). Um meta sistema de identidade é uma estrutura no qual nós podemos ligar tecnologias de identidade como tickets de Kerberos, certificados X.509, tokens de SAML, e quaisquer outras representações de identidade que você pode descrever com uns (1) e zeros (0). Contanto que seja uma tecnologia que faça sentido por ambos o usuário como também aplicações de Internet que servem esses usuários, haverá um modo para ligar isto neste meta sistema. É interessante notar que o Passaport de Microsoft não satisfaz as sete leis por si só (ele é um grande trabalho, com propriedades de Microsoft como MSN e Hotmail, mas não é algo que eu quero usar quando eu falar com meu banco!). Porém, o Passport seria uma adição perfeitamente natural a uma pasta de identidades debaixo deste mesta sistema. Neste mundo, Passaporte se torna um de muitos provedores de identidade; simplesmente não pode haver um provedor de identidade para regê-los tudo!

Antes que a Internet realmente pudesse decolar, os participantes tiveram que concordar em alguns protocolos básicos: TCP/IP para transmitir pacotes, DNS para descobrir hosts de TCP/IP, e assim por diante. O mesmo vai pelo meta sistemas de identidade. São necessários alguns protocolos básicos que todos nós concordamos para fazer a realidade dos meta sistemas. A proposta de Microsoft está baseada no WS - * Conjunto de especificações de serviços de web. Por exemplo, é usada WS-Security para definir representações de XML de tokens de segurança e garantir o transporte deles entre hosts de Web, enquanto WS-Trust é usado para transformação de reivindicações. WS-MetadataExchange e WS-Policy são usados para descoberta, enquanto auxiliam negociar o tipo de token e reivindicações requerer pelas partes que precisam autenticar entre si.

No meta sistema de identidade, há três parâmetros: assuntos (entidades como usuários ou até mesmo dispositivos que precisam acessar hosts de Internet), provedores de identidade (como Verisign, muitos de quem provêem serviços de identidade para Web), e partes confiáveis (hosts de Internet que necessitam autenticar assuntos ou caso contrário consumir informação de identidade). Mas para completar a história de como estes três interagem, eu preciso introduzir o último pedaço do quebra-cabeça, uma parte do meta sistema de identidade atualmente com o codenome Cardspace.

Cardspace

Duas das leis de transação de identidade com os humanos interagem com o meta sistema. Uma delas, a pessoa declara quais as necessidades serão partes integrantes do protocolo de segurança que é claramente necessário determinado plethora of phishing e outra a engenharias sociais que comumente atacam no tempo da escrita. A outra lei que eu estou pensando que a interface humana para o meta sistema deveria ser consistente e real não importando qual tecnologia subjacente está sendo usada para representar informação de identidade.

Cardspace é o codinome atual para um sistema que a Microsoft está usando para mostrar o meta sistema a humanos, e projetou para satisfazer estas (e outras) leis de identidade. A parte mais visível de Cardspace é o seletor de identidade que ajuda um usuário organizar identidades digitais como cartões plásticos (do tipo cartões de crédito).  Usuários de computador já estão familiarizados com cartões de crédito, cartões de biblioteca, carteiras de motorista, e assim por diante, modelando uma identidade digital assim como um cartão é um grande modo para fazer mais para o conceito bastante abstrato de identidade concreto.

Cada cartão tem uma estrutura de dados que contém todos os meta dados necessários para ajudar o usuário a escolher um cartão em um contexto particular. Por exemplo, se o usuário navegar para um local de Web que aceita token SAML emitido por Verisign, Thawte, ou GE, o seletor de identidade se aparecerá e dará para o usuário uma chance para escolher o cartão correto. Mas só cartões que estão baseado em tokens SAML emitidos por Verisign, Thawte, ou GE serão aceitos quando o seletor de identidade se aparecer neste contexto. Depois que o usuário selecionar um cartão, o seletor de identidade vai "diferenciar” o cartão, contatando o provedor de identidade e obtendo as reivindicações atuais que o cartão representa (o qual o usuário consegue aprovar, a propósito, antes de enviar para o local de Web). Em resumo, cartões contêm bastante informação para ajudar o usuário a fazer uma escolha, mas o provedor de identidade é de fato quem retém a informação pessoal do usuário que é representada pelo cartão. O provedor de identidade age como um STS, emitindo tokens de segurança que contêm as reivindicações desejadas. Note que há um provedor de identidade local entregue com o Cardspace, permitindo criar cartões auto-emitidos, embora as informações pessoais nestes cartões são muito limitadas comparados com o  que será armazenado em seu disco rígido.

De modo que Cardspace avança na história de integração humana ele está fazendo uso de uma característica de certificados X.509 chamado logotipos (RFC 3709). Isto permite representar o assunto do certificado e emissor não só por um nome, mas também por uma imagem que pode ser apresentada ao usuário. Isto ajudará encorajar que os usuários verifiquem a identidade dos locais eles estão visitando antes de submeter suas informações pessoais!

Cardspace e a identidade de metasystem inseriram usuário como ponto central. Nada me pára de criar cartões que têm falsa informação para dar em locais nos que eu realmente não confio (mas exige que forneça informação pessoal para adquirir o serviço que eu preciso). Eu posso ter tantos cartões quanto eu quiser: Não há nenhuma necessidade para tentar ter um único cartão que trabalha em todos os lugares.

O quadro abaixo mostra como o metasystem reúne assuntos, provedores de identidade, e partes confiadas.

Figura 9. Identidade de metasystem

Programando um Web Service para aceitar tokens do metasystem de identidade (em outras palavras, criar as regras de uma parte confiada) é fácil quando se usa WCF para construir seu serviço de Web, como veremos depois.

O seletor de identidade é instalado no sistema operacional como um serviço privilegiado. Transportará inicialmente com o Windows Vista, mas também poderá ser instalado automaticamente onde quer que WinFX seja instalado. WinFX pode ser instalado em Windows XP e Windows 2003 Server, assim estas plataformas também terão acesso a um seletor de identidade. A Microsoft também oferece para terceiros a construção de seletores semelhantes em sistemas operacionais concorrentes, porque o metasystem de identidade só terá sucesso se houver grande adoção.

Onde Nós Estamos?

Identidade federada ajuda eliminar outra camada de identidade automatizando relações de confiança existentes entre parceiros. Isto pode reduzir o custo de implementação e manter a aplicação utilizável por organizações parceiras. Suportar identidade federada significa construir identidades e reivindicações sobre aplicações, que são ADFS usando bem fácil (ou WCF como você verá brevemente).

O metasystem de identidade e Cardspace estão para mostrar a noção de federação e identidade de reivindicação baseada como um todo à Internet. Permitindo o usuário escolher suas próprias tecnologias de identidade e provedores, e inserindo-o ao centro, o metasystem de identidade segue amplamente as sete leis de identidade e com uma boa chance de se tornar a camada de identidade da Internet.

Recursos

Aprender mais sobre Cardspace e o metasystem de identidade da perspectiva de um desenvolvedor, leia os seguintes artigos:

· Security Briefs: A First Look at Cardspace

· Microsoft's Vision for an Identity Metasystem

· Design Rationale behind the Identity Metasystem

Segurança no Windows Communication Foundation (WCF)

WCF é uma moderna pilha de comunicação para a plataforma Windows, e foi projetado com base no crescimento de segurança. Esta seção lhe ajudará a entender as características de segurança esperadas de WCF e suas responsabilidades para que você desenvolva os clientes seguros e serviços usando WCF.

Metas de segurança

WCF tem muitos modelos para lhe ajudar a construir sistemas conectados seguros. Aqui são algumas das metas de segurança mais importantes que WCF o auxilia:

Confidencialidade

WCF usa criptografia moderna como AES, padronizando tamanhos de chaves recomendadas pelos criptógrafos conservadores como Ferguson e Schneier em seu livro Practical Cryptography. Mais importante, as trocas de chaves de encryption usa algoritmos de autenticação modernos como Kerberos e SSL/TLS. Encriptação de mensagem é chaveada para um padrão de ligações exceto no perfil básico.

Integridade

Mensagens de WCF são assinadas por padrão. Juntado com a detecção de reprise, isto ajuda assegurar que a mensagem recebida atualmente veio de fato do cliente que você pensa que fez. Se a mensagem foi falsificada, você não a verá porque a segurança WCF segurança rejeitará isto antes de vir para você. Conteúdos e a maioria dos cabeçalhos são assinados através de padrões de ligações exceto no perfil básico.

Autenticação

Não há muito ponto trocando mensagens assinadas e codificadas se você não souber que está no outro fim do arame! WCF executa autenticação mútua através da falta com todas as ligações standards exclua o perfil básico. WCF prefere usar protocolos de autenticação maduros como Kerberos e SSL/TLS onde quer que possível.

Autorização

Enquanto WCF não prover muita infra-estrutura para implementar autorização de fato, ele provê os pontos necessários até seu meio de autorização favorito, como provedores de regras AzMan ou ASP.NET.

Auditoria

WCF examina muitas operações sensíveis de segurança e você pode habilitar auditoria usando o ServiceSecurityAudit. Produção de auditoria vai para o log de eventos, e você pode direcionar os logs para os eventos de segurança ou eventos de aplicação.

Segurança e Ligações

Uma ligação em WCF determina a ligação entre a internet e seu código em um serviço de WCF ou cliente. Tem havido muito sangue, suor, e lágrimas postos nestas ligações de forma que tudo que você precisa fazer é contar para WCF quais as necessidades de segurança de seu serviço, e ele fará o levantamento pesado para você. O modo mais comum para configurar ligações é simplesmente escolher de uma suíte de ligações padrões. Aqui é uma tabela das ligações geralmente usadas:

Ligação	Comentários
basicHttpBinding	É um perfil básico de ligação WS-I. Não é seguro por padrão, mas pode executar sobre SSL/TLS sendo uma prática comum hoje por segurar serviços de Web que comportam perfil básico.
wsHttpBinding	Esta é a ligação que você usará se quiser suportar a suíte de protocolos WS - * . Segura por padrão utiliza a segurança message-mode com credenciais de Windows.
wsDualHttpBinding	Semelhante a wsHttpBinding até onde segurança está preocupada.
netTcpBinding	Esta é a ligação que você usará para uma maior velocidade entre plataformas de interoperabilidade não é necessário. Segura por padrão, utiliza transpor de segurança built-in com as credenciais do Windows.

Uma vez escolhido o padrão de ligação, você pode usar outros ajustes de padrões de segurança para a ligação como eu descrevi anteriormente, ou você pode ajustar de acordo com suas necessidades. Se você decidir realizar mudanças, há duas decisões principais que você precisará tomar. Até mesmo programadores avançados de WCF que criam as próprias ligações customizadas e precisam tomar estas mesmas decisões.

Passo 1: Escolha um Modo de Segurança

Nenhum

Um modo de segurança de Nenhum significa você não quer ter problemas com autenticação, integridade, ou confidencialidade. Os clientes e serviços que usam este modo serão vulneráveis a ataques sórdidos (como personificação de cliente, spoofing de serviço, espionagem, e assim por diante), assim tenha uma certeza antes de escolher este modo!

Transporte

Modo de Segurança de Transporte é simples, amadurecido, e de alto desempenho, geralmente usado em cenários de interoperabilidade (como HTTPS).

Se você estiver usando uma ligação HTTP, será necessário configurar SSL/TLS fora de WCF (tipicamente no IIS, por exemplo) para segurar o canal. Por outro lado, WCF implementa segurança de transporte intrinsecamente pelo netTcpBinding (via autenticação integrada do Windows). Seguranças de transporte são boas para serviços de ponto-a-ponto onde não há nenhum intermediário como roteadores.

Mensagem

Modo de segurança de mensagem é infinitamente flexível. Usa a suíte de protocolos WS - * (WS-Security, WS-SecureConversation, e WS-Trust, para autores). Estes protocolos permitem uma grande variedade de credenciais de cliente, certificados X.509 e token Kerberos para conjuntos de reivindicação assinados emitidos por tokens de serviços de segurança (como provedores de identificação Cardspace, por exemplo). Você pode projetar sistemas sofisticados com estes protocolos. Por exemplo, desde que suportes de tokens WS-security que suportam múltiplos tokens para qualquer mensagem, não há nada que pare a construção de uma mensagem dinâmica que roteia onde não só o cliente original, mas também o roteador provê prova de identidade ao serviço. Isto é realmente legal!

O intercâmbio para este nível de flexibilidade é que segurança de mensagem não é um transporte amadurecido, e não será fácil, provavelmente uma interoperabilidade com clientes/serviços não-WCF. A partir deste código, você terá somente um perfil básico de serviço Web executando sobre HTTPS para interoperabilidade, mas indo adiante verá que menos desenvolvedores implementam estes protocolos e mais criptógrafos analisem a suas fraquezas.

Passo 2: Escolha o Tipo de Credencial de Cliente

Ambas as mensagem e transporte de segurança combinam no WCR e são  configuradas baseadas no tipo de credencial que você espera que o cliente apresente. Sua escolha aqui não só ditará a forma de credencial que WCF exigirá de seus clientes, mas também a forma da credencial que seu serviço tem que usar. Esta escolha também determina o protocolo de autenticação que será usado. Há cinco credenciais de cliente digita WCF, e eles são representados pela enumeração de ClientCredentialType:

Nenhum

Esta é a credencial de cliente mais simples: nenhum nada! Neste caso o cliente será anônimo, mas o serviço será autenticado com um certificado. Isto é semelhante ao que você vê quando você visitar uma loja de Internet: você está pastando como um usuário anônimo, mas quando você pastar em cima de HTTPS, o site de Web identifica você por um certificado de SSL. É importante para autenticar serviços a clientes assim o cliente sabe que o serviço não está sendo nenhum spoofed. (lembrem-se que os clientes enviam freqüentemente informação sensível a serviços, como números de cartão de crédito e senhas! ).

Nome de usuário

Aqui o serviço usa um certificado para identificar os clientes, e eles provêem um nome de usuário e senha ao serviço. Por padrão, o WCF examina a conta do usuário no Windows usuário e tenta estabelecer um logon com a senha fornecida. Se o usuário não prover a senha correta para a conta, o pedido será negado pela segurança do WCF.

Se você não mantém as contas de usuários do Windows para os clientes, você pode prover uma classe que autentica um banco de usuário de sua escolha, ou utilizar um ASP.NET membership provider (como o provedor de SQL que vem com ASP.NET) para autenticar seus usuários.

Windows

Selecione esta opção se você quiser que seus usuários autentiquem usando as credenciais únicas do Windows. Cliente e servidor usarão as credenciais do Windows para autenticar. Esta é sem dúvida a melhor escolha para aplicações de Intranet em um ambiente de domínio. Você não tem que desenvolver certificado ou customizar nomes e senhas, e pode facilmente ajustar grupos ou AzMan para autorização. Comece aqui se possível, realmente não requer muita habilidade.

Certificado

Neste caso, o serviço e cliente têm os seus próprios certificados que eles apresentam um ao outro para autenticar. Esta opção é popular para construir soluções de negócio-a-negócio onde cada lado se identifica usando um certificado. No futuro, muitas destas soluções usarão o conceito de federação por estar em toda parte.

IssuedToken

Selecione esta opção se você quer que seu serviço suporte conjuntos de reivindicação tais como os fornecidos pelo Serviço de Segurança de Token (STS - security token service) eu descrevi anteriormente com o metasystem de identidade e Cardspace. Seu serviço se identificará aos clientes por um certificado, enquanto os clientes apresentarão um token de segurança emitido de um STS. Você precisará apoiar autorização baseada em reivindicação.

Você pode ter mais de uma ligação!

Um dos grandes pontos sobre a arquitetura WCF é que você pode expor um contrato de serviço em vários hosts diferente. Por exemplo, você poderia querer um serviço para não só estar disponível aos empregados da organização, mas também para parceiros empresariais externos. Para prover suporte os empregados locais utilizar credenciais de Windows, dando aos empregados um single sign on para os parceiros externos, utilizar um segundo host com uma internet amigável e clientCredentialType como Certificado ou IssuedToken, dependendo de suas necessidades. E se você tiver cuidado para separar sua lógica empresarial de sua lógica de autorização, você pode ter uma única implementação do serviço que apóia ambos os hosts simultaneamente!

Estratégias de autorização

Não importa que estratégia de autorização que você escolhe, lembre-se do conselho eu dei na seção de Autorização: faça o melhor para fatorar a política de autorização fora de sua lógica empresarial. Regras de autorização precisam freqüentemente ser flexíveis e configuráveis por um administrador. Regras de códigos são mais rígidas a mudança!

Dependendo da forma de credencial de cliente que você escolhe, autorização pode ser tão simples quanto o WindowsIdentity do cliente e personificando isto antes de acessar recursos, ou tão complicado quanto construir uma política de autorização baseada em reivindicação completa com uma interface de usuário que permite um administrador executar a política em tempo de execução.

Por exemplo, quando seu cliente prover uma credencial do Windows, você não só tem a habilidade para personificar o cliente, mas também pode usar grupos do Windows para autorização, ou com algumas linhas extras de código AzMan para realizar acesso de cheques de operações. Por outro lado, se seu cliente prover um certificado, você não tem nenhuma destas opções. Você poderia mapear o certificado sobre uma conta de Windows “sombra” mas estaria forçando o administrador a criar contas de Windows para seus usuários que podem aumentar significativamente o custo de manter sua aplicação.

Indo adiante, está claro que o futuro está em autorização baseada em reivindicação, porque habilita cenários de identidade federados. Como eu apresentei anteriormente neste documento, um dos benefícios principais de soluções de identidade federadas é que não há nenhuma necessidade para prover estas contas “fantasmas” de usuários. Também é o próximo passo para o Cardspace. Enquanto não há nenhum apoio direto por autorização baseada em reivindicação hoje utilizo a plataforma do Windows (por exemplo, não há uma versão de AzMan que é baseada em reivindicação), eu espero ver muita inovação da Microsoft nesta área.

Programando a segurança de WCF

Enquanto a maioria das características de segurança no WCF simplesmente pode ser controlada mudando configurações, em algum ponto você vai querer escrever código sobre o modelo de identidade de WCF. Uma das razões mais comuns para fazer isto em um serviço é descobrir as necessidades apresentado por seu cliente. O modo mais básico para ler estas necessidades é obter um conjunto de reivindicações do ServiceSecurityContext do pedido. Você pode enumerar as reivindicações então sobre o assunto. Por exemplo, pode usar esta técnica para descobrir detalhes como o nome de assunto no certificado do cliente. Aqui é um exemplo:

  public string getSubjectName()
{
    // if sctx is null, user has not been authenticated
    ServiceSecurityContext sctx = ServiceSecurityContext.Current;
    if (null == sctx) throwAccessDenied();
 
    // we expect the user to supply a cert to authenticate
    X509CertificateClaimSet cs =
        sctx.AuthorizationContext.ClaimSets[0]
            as X509CertificateClaimSet;
    if (null == cs) throwAccessDenied();
 
    return cs.X509Certificate.SubjectName;
}

  

Visualizando melhor, uma autorização baseada em reivindicação é mais adequada para aplicações que precisam suporte de identidade de federação, para aplicações mais simples você pode evitar este nível simplesmente programando em IPrincipal e IIdentity, por exemplo. Isto faz sentido se você esperar que seus clientes forneçam credenciais de Windows.

Validação de dados de entrada

Poderia estar tentando caminhar longe deste tópico e dizer, “Use WCF e suas aplicações estarão seguras”, ainda há muitas precauções básicas que você precisa levar em conta para assegurar que seus serviços estão bastante seguros. Modelagem é um grande modo para priorizar seu trabalho de forma que você está protegendo as áreas de maior risco de sua aplicação primeiro. Introduzir Validação também é imperativo; qualquer desenvolvedor em seu time pode inadvertidamente introduzir vulnerabilidades de segurança em um SQL escrevendo código ingênuo. Entradas são más até provado o contrário!

Onde Nós Estamos?

WCF faz muito do levantamento pesado exigido para construir aplicações de identidade, inclusive autenticação, integridade, confidencialidade, e auditoria. WCF também faz isto fácil de adicionar sua própria lógica de autorização provendo os ponto necessários para programar em regras de segurança baseadas no AzMan, ASP.NET ou uma solução baseada em reivindicação trabalha com o metasystem de identidade. Lembre de que no futuro, autorização baseada em reivindicação é uma grande porção do quebra-cabeça de sistemas conectados, federados, por isso comece pensando hoje!

Virtualmente todas as ligações de WCF exceto o perfil básico são seguras fora da aplicação, provendo encriptação e integridade, cheques de todas as mensagens, e autenticação (tipicamente usando credenciais Windows por padrão). Não esqueça que você ainda precisa seguir diretrizes de codificação básicas de segurança.

Recursos

· Writing Secure Code, Second Edition

· ACE threat modeling tool

· Patterns & Practices threat modeling guidance

· Patterns & Practices online input validation training modules