Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Junho 2009 >  Inspeção de segurança: considerações na identid...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Security Watch Thoughts on Identity, Part 1
Jesper M. Johansson


A concept many of us thought we had a good handle on keeps coming back up these days: identity. With unrelenting speed, we are seeing various new identity projects, most in the form of some kind of distributed identity systems and/or something that will finally replace passwords. These systems all have one basic goal—to replace the plethora of username-and-password combinations we all have to remember with a single identity. Instead, these new systems would offer one identity that gets us access to everything.
As I look at the 127,128 passwords I have stored in my Password Safe , I think that actually sounds quite appealing. And each time I go to any Microsoft.com property and am asked, again, for my Windows Live ID and password, I realize we also have a very long way to go before reaching a world of single sign on (SSO).
Identity, however, is a nebulous concept and an oft-misunderstood one. In this article, I lay out some thoughts on identity and principles that an identity system has to meet. I do not have enough gray hair yet to pretend that these are fundamental laws that these systems must obey. However, I do believe that any identity system that fails to abide by these principles will fail in the court of consumer opinion, as well as in the one of enterprise support and deployment. An identity system, as theoretically pleasing as it may be, must ultimately provide value to a business and to a user if it is going to succeed.

What Is an Identity?
An identity, simply put, is an abstract representation of an entity in a computer system. Philosophy defines it as the "sameness" of two things. Two (or more) things are identical if they are the same. Yes, that would qualify as a highly circular definition. So, instead, let's say that identity states that an entity is definable and recognizable. Maybe this is simpler:
(P=Q)→(P=Q)
That is the basic definition of identity in symbolic logic. P is equal to Q if P is the same thing as Q. Restated slightly differently, if Peter is Peter then clearly Peter is Peter. Now all we need is a way for Peter to prove that he (or she?) is in fact Peter.
Methods of proving identity are highly interesting in digital systems. In the digital world, we have a slightly different definition of identity from that in symbolic logic. In his seminal paper " The Laws of Identity ," Kim Cameron defines digital identity as "a set of claims made by one digital subject about itself or another digital subject."
That is a different definition than the pure logical one. The pure logical definition is simply who you are. In the digital world, identity is rooted in the claims you choose to present. In other words, a digital identity is not who you are, but rather, who you choose to be. In a digital identity system, as long as Peter, or whoever claims to be Peter, can provide an acceptable proof of that claim (meaning that the can authenticate the claim), we must accept Peter's identity. The claims Cameron talks about are essentially a manifestation of identity. Those are the authenticators Peter, or whoever needs to be Peter, is presenting.
Therein lies the first identity problem. Digital identity is not the same as an ontological (in the philosophical sense) identity—a representation of a real world entity that actually exists. Digital identity is ephemeral. Digital identity is incomplete. Digital identity is optional. And, most interesting of all, a single physical entity can present many different sets of claims and, therefore, have many different digital identities. Digital identities are quite possibly most useful when they do not have a 1:1 correspondence to an ontological entity.

The Identity Problem
A claims-based digital identity concept causes many interesting problems. First is the fact that an identity has a price. You can buy a whole new identity for only a few thousand dollars. For that money you get a functioning social security number along with a valid address that you can change. Driver's licenses, credit cards, passports, and the rest can be had with that. If you want an identity with a verifiable personal history, that will probably cost you quite a bit more.
Some people, including myself, claim that this means that ontological identity is meaningless as it relates to digital identity systems. Personally, I find true identity (or at least, correctness of identity) to be irrelevant and uninteresting when dealing with it in the context of a digital system. For the vast majority of applications, identity merely means that you can lie consistently. If you are able to present the same lies to me today that you did two weeks ago, I am going to assume you are the same person/entity/computer and give you whatever access I granted to you last time.
Given that true, ontological identity is not only ephemeral, but irrelevant to most applications, I don't care about binding you to a real-world entity. I just need correlation, not true physical identity, for most purposes. Any application that relies on binding identity to a physical and immutable entity is doomed from the start, and relying on such a strong connection means you will always make mistakes and they will always be critical. Any real-world person can undermine such a system merely by lying or withholding the claims of identity or, of course, by sharing them (inadvertently or deliberately) with another entity.
Rather, by building a system that (1) is based on the assumption that any claimed identity is fake, and (2) that merely attempts to correlate identity between sessions, we can build a far more resilient, useful, and valuable system. And we waste far fewer resources attempting to solve a problem that, throughout history, nobody has been able to solve without outrageous violations of personal privacy.

Authenticating Identity
Another problem with identity is that identity by itself is not something you can use. Yet, throughout history, identities have often been taken for granted, without authentication. In Shakespeare's Henry IV, there is a passage where a character says, "I am Robert Shallow, sir, a poor esquire of this county, and one of the King's justices of the peace." Curiously, the character to whom Justice Shallow was speaking took this claim of identity as truth, with no further verification. Go back into earlier forms of literature, such as the Norse Sagas, and you will find similar claims of identities made by Thor and Odin, all of which were immediately accepted without question.
Clearly, if you have only one eye, are riding on an eight-legged steed, and claim to be Odin, one might argue that you have provided some amount of verification of identity. However, on the Internet, we cannot use the mounts we ride as verification of identity. As the old saying goes, "On the Internet nobody knows you are a dog." Therefore, unauthenticated claims of identity are hardly ever accepted. Therefore, we need to somehow authenticate identity.
"Ay, there's the rub." (Hamlet.) How do you prove your identity? After all, the proof of your identity is as important, perhaps more so, as the actual identity. So, how do we prove identities? The method we used to use was a form of shared secret authentication, known as "passwords." On February 14, 2006, Microsoft Chairman Bill Gates declared that passwords would be gone where the dinosaurs rest in three to four years.
But as I write this in March 2009, it is pretty clear that Bill was wrong. I have more passwords now than I had in February 2006. Just at work, I have my network password, my Unix password, the password for the expense reporting system, the password for the HR system, passwords for the company stock broker and benefits providers, the root passwords for my developer machine and a few servers, the admin passwords for my laptops, the PIN for my phone, and a couple of extraneous passwords to access the company products as various users. Still, despite having so many passwords, I can honestly say that I really do not wish passwords were dead. They are not actually a bad authentication claim.
What was Bill Gates thinking? He thought, three years ago, that by now InfoCard would have replaced all these passwords. InfoCard, which was eventually renamed Windows CardSpace, is a kind of authentication technology that shipped in Windows Vista and later in Windows XP SP3.
Points go to anyone who has ever created a card. I will give you extra credit if you find a single Web site that accepts a Windows CardSpace credential. If you just want to try it, you can take part in a beta test of InfoCard for Windows Live .

Stakeholders in Identity
There are, of course, other ways to authenticate an identity. Some are more useful in certain situations. To understand where, you need to understand the difference between the stakeholders in an identity system.
A provider of identity services is some entity that provides a service to the other parties. Typically, the provider holds the identity database and authenticates the end users of identities. Typically, the provider is not a person. Thus, the provider can deal with much larger volumes of structured data than a person can. For example, a provider can use a shared secret of arbitrary length to prove its own identity. Therefore, the credential used to authenticate the identity of an identity provider can often be many orders of magnitude more complex than what you and I can remember. Consequently, it is potentially many orders of magnitude more secure. I say "potentially" because whether it really is depends greatly on how the secrets are managed. It does no good to have a 4096-bit secret to prove your identity if you do not actually keep it secret.
Identity providers can very easily use constructs such as Digital Certificates to authenticate themselves. A Digital Certificate is simply a relatively sizeable chunk (a couple of thousand bytes) of structured information. A computer can easily send that as part of every transaction. You and I, however, would not be too thrilled if we had to enter that to authenticate for a transaction.
The end user is the entity that needs to have its identity asserted. Very often, the user is a person, but that is not always the case—the user can also be a computer system. Therefore, the quality of the claims the user can present varies greatly.
Finally, there's the relying party. The relying party is the entity that trusts the identity provider to verify the user before providing the user some service. The relying party is almost always a computer system. To the extent that the relying party proves its own identity to a user and the identity provider, it can do so with equally strong claims as the identity provider used.
It is important to note that a user in one scenario is often a relying party in another. If the user is a piece of software, or has the help of a piece of software, this user can easily deal with the same types of structured data as the provider. That is why distributed identity protocols, such as OAuth and the various security specifications part of WS-* focus heavily on significant quantities of structured data for authentication—they are primarily focused on services authenticating to each other. Even when those specifications deal directly with people, they tend to be brokered through services that can handle the structured data on behalf of the people. Often, the broker is just an application on the user's computer.

Using Identities
The concept that a user (a person) uses a computer system as an intermediary when accessing services from a relying party is quite important. It goes to the heart of how to make identities usable by people, as opposed to systems. Unfortunately, other than InfoCard, which so far has found little success, few systems really address that topic. To a large extent, the process flow when a physical person uses an identity service to get access to something looks something like Figure 1.
Figure 1 Process Flow of Using an Identity Service
Notice the "Then A Miracle Occurs" (TAMO) box. The sociotechnical aspects of the system—how you enable users to take full advantage of them—is where a system is truly made or broken.
There have been many attempts at resolving the TAMO issue. Most came about because of the incongruity that on the Internet we want to use strong identities, typically based on certificates, but users persistently refuse to type them in every time they need to access a service. Microsoft Passport, currently called Windows Live ID, was an early attempt. Google has entered the fray with its Google Account, and there are others, as well. Even Windows CardSpace can be said to have been an attempt at solving this problem. All are designed to provide some level of SSO. All have succeeded, largely, in doing so, within the domains owned by their various purveyors of the particular solutions. All have failed almost entirely outside of their purveyor's domains.
In the remainder of this article and Part 2, I will address this problem in more detail. Note that I do not purport to solve the problem, but merely to point out some reasons why nobody else has yet solved the problem either. Eventually, I will arrive at a set of principles that I believe any solution to this problem must follow. That, in turn, will lead to a conclusion that says, to sum it up, ontological identity may just be a pipe dream.

How Many Identities Do You Have?
The big challenge with respect to identity is not in designing an identity system that can provide SSO, even though that is where most of the technical effort is going. It's not even in making the solution smoothly functioning and usable, where, unfortunately, less effort is going. The challenge is that users today have many identities. As I mentioned above, I have well over 100. On a daily basis, I use at least 20 or 25 of those. Perhaps users have too many identities, but I would not consider that a foregone conclusion.
The purist would now say that "SSO can fix that problem." However, I don't think it is a problem. At least it is not the big problem. I like having many identities. Having many identities means I can rest assured that the various services I use cannot correlate my information. I do not have to give my e-mail provider my stock broker identity, nor do I have to give my credit card company the identity I use at my favorite online shopping site. And only I know the identity I use for the photo sharing site. Having multiple identities allows me to keep my life, and my privacy, compartmentalized.
In addition, if the credit card company manages to get itself hacked, all the other identities are unaffected. If I had a single identity, that may or may not be the case, depending on how that single identity was implemented. A properly implemented SSO system would never expose one site using the system to a failure in another, unrelated site. However, enforcing that separation is not trivial, and if the identity provider is compromised, every site that depends on it is automatically compromised.
This latter point is one reason why the digital identity systems Cameron described have, so far, failed to become the single universal identity provider—any single identity provider is an extremely sensitive entity.

Principles of Identity
There are several principles of identity that must be met in at least some way to provide a successful digital identity system. These are very different from the laws Cameron outlined in the Laws of Identity paper. Cameron's laws were design principles—use cases, more or less—that essentially define technical requirements for a trustworthy digital identity system. As such, they are a set of necessary but insufficient criteria for success. While many systems can be designed to meet or exceed Cameron's laws, I do not think any of them will be broadly successful without also taking into account the principles I define here. My principles are higher-level principles, dealing with business requirements, not with direct design points of the system.

1. The identity provider is at least as sensitive as the most sensitive relying party.
First, as I mentioned earlier, the identity provider is trusted by all parties. This is why we refer to them as "relying parties." That means that the identity provider must be at least as well protected as the most sensitive relying party requires. This single point is why many of the candidate universal systems have failed to create broad-reaching SSO systems—the trust simply is not there. Even if the trust is warranted, it is extraordinarily difficult to prove why one party should trust another.
Would you trust your e-mail provider with your bank account information and all your checking account data? If the answer is "no," you should not trust it to provide the identity you use to sign into your bank. Consumers today are deluged by unreliable software, incomprehensible pop-ups, and anti-malware vendors (legitimate and not-so-legitimate) who claim you can't possibly surf the Internet safely unless you pay them. Consequently, and quite wisely, consumers trust almost nobody. Very few organizations today are trusted enough to be candidate identity providers for other organizations. Building that kind of trust is not cheap. Keeping it is a fragile proposition. And earning it back once lost due to a breach is nearly impossible.
If we will ever see a company providing a successful universal digital identity system, it will be from a company that has earned a very high level of trust. Interestingly, many of the players in the identity provider space are not very high up in the surveys, or they do not show up at all (See the Ponemon Institute’s fifth annual survey of Most Trusted Companies for Privacy ).

2. Permit the enterprise to protect its customer relationships and to own and control information that it deems as business confidential.
Anyone who has an MBA knows that there are three ways to succeed with a business: you have the most innovative product, or you have the lowest price, or you excel at customer intimacy (or some combination of all three). Interestingly, virtually every business is interested in the latter scenario: customer intimacy. Customer relationships, especially in an online business, are sacred! In a world where switching costs are next to nothing, where everyone guarantees (for some loose definition of "guarantees") the lowest price, and the same product is available everywhere, customer relationships become key. Even where innovation does happen, such as in social networking and e-mail providers, customer connection is still critical.
One primary reason why no large Web site accepts credentials from another company (or another company that did not use to own them, as in the case of Expedia) is that it dilutes its relationship with its customers. Imagine, for example, if Yahoo simply received a claim from NetIdentitiesRUs that, yes, it really is customer 923071235309342-2 that just signed in. Yahoo would no longer own the database of its customers. It would not know who the customer actually is. Yahoo could no longer manage the customer and the system the way it wanted. It could no longer do customer research by cross-checking the identity with the databases in its subsidiaries and acquisitions. It could not even sell the information to third parties for extra revenue (should it wish to and had the customers opted in, of course). Clearly, Yahoo would not be particularly interested in giving all that up and, consequently, would need some exceptional incentives to do so.
Now imagine instead that Yahoo is the identity provider. Yahoo can get information on exactly where customer 923071235309342-2 goes on the Web because it knows exactly which sites request claims for that customer. Yahoo could compile invaluable data on that customer's browsing habits, allowing extraordinarily well-targeted advertisements with astonishingly high click-through rates. For an ad-funded organization, and especially one that is actually in the ad business itself, that is a competitive advantage you just cannot give up.
Trusting identities provided by other companies would be equivalent to giving up huge opportunity. Providing your own to others would be jumping on it. In other words, there's a conflict and the result is exactly what we are seeing on the Web today. Within conglomerates, we see one universal identity, and while all of the major conglomerates are also identity providers, virtually nobody relies on them.
This analysis points to a fundamental asymmetry in identity provisioning. There is huge value in being the identity provider and no value at all in being the relying party. Unless the market can figure out ways to equalize the two, we will continue to see as many identity providers as relying parties, with virtually a 1:1 relationship between them.
Check back next month when I will look at the remaining principles in this two-part series.

Jesper M. Johansson is Principal Security Architect for a well-known Fortune 200 company, working on risk-based security vision and security strategy. He is also a contributing editor to TechNet Magazine. His work consists of ensuring security in some of the largest, most distributed systems in the world. He holds a Ph.D. in Management Information Systems, has more than 20 years experience in security, and is an MVP in Enterprise Security. His latest book is the Windows Server 2008 Security Resource Kit.

Inspeção de segurança Opiniões sobre identidade, parte 1
Jesper M. Johansson


Um conceito que muitos de nós pensou que tivéssemos uma alça de BOM no mantém voltem até hoje em dia: identidade. Com velocidade implacável, vemos novos projetos de identidade, mais na forma de algum tipo de sistemas de identidades distribuído e / ou algo que finalmente substituirá as senhas. Esses sistemas todos os possuem uma meta básica — para substituir a gama de combinações de nome de usuário e senha temos todas as que lembre-se com uma única identidade. Em vez disso, esses novos sistemas poderiam oferecer uma identidade que obtém nos acesso a tudo.
Como eu examinar as senhas 127,128 armazenados no meu Segurança de senha , Acho que realmente parece bastante atraente. E sempre que vá para qualquer propriedade do Microsoft.com e sou solicitado, novamente, para Meu Windows Live ID e senha, perceber que também temos uma maneira muito antes de atingir um mundo de single sign on (SSO).
Identidade, no entanto, é um conceito nebulous e um misunderstood oft. Neste artigo, eu ordene algumas idéias na identidade e princípios que um sistema de identidade deve atender. Não tenho suficiente cabelo cinza para fingir que essas são fundamentais leis que esses sistemas devem obedecer. No entanto, acredito que qualquer sistema de identidade que tenta obedecer por esses princípios falhará no tribunal da opinião do consumidor, bem como de suporte de empresa e implantação. Um sistema de identidade, como pleasing, teoricamente, pois ele pode ser, por fim deve fornecer valor para uma empresa e para um usuário se ele for bem-sucedida.

O que É uma identidade?
Uma identidade, simplesmente colocar, é uma representação abstrata de uma entidade em um sistema de computador. Filosofia define-lo como "igualdade" destas duas coisas. Dois (ou mais) coisas são idênticas se eles forem iguais. Sim, que seria qualificado como uma definição circular altamente. Portanto, em vez disso, digamos que identidade afirma que uma entidade é definable e reconhecíveis. Talvez isso é mais simples:
(P=Q)→(P=Q)
Essa é a definição básica de identidade em lógica simbólica. P é igual a Q se P é a mesma coisa que Q. Reafirmando de maneira um pouco diferente, se Peter for Peter claramente Peter é o Peter. Agora tudo o que precisamos é uma maneira de Peter provar que ele (ou ela?) é de fato Peter.
Métodos de fornecer identidade são altamente interessantes em sistemas digitais. No mundo digital, temos uma definição ligeiramente diferente da identidade do em simbólicos lógica. No seu documento seminal" As leis de identidade " Kim Cameron define a identidade digital como "um conjunto de declarações feitas por um assunto digital sobre si ou outra entidade digital".
Que é uma definição diferente daquele puro lógico. A definição de lógica pura é simplesmente quem você é. No mundo digital, a identidade está enraizada nas declarações escolhido para apresentar. Em outras palavras, uma identidade digital não é quem você está, mas em vez disso, que você optar por ser. Em uma identidade digital sistema, como longa como Gustavo, ou quem alega ser Peter, pode fornecer uma prova aceitável dessa reivindicação (que significa que o pode autenticar a declaração), deve aceitar identidade Pedro. As reivindicações que Cameron fala sobre são essencialmente uma manifestação de identidade. Esses são os autenticadores Peter ou quem precisa ser Peter, está apresentando.
Nele é o primeiro problema de identidade. Identidade digital não é o mesmo que uma identidade ontological (no sentido philosophical) — uma representação de uma entidade real que realmente existe. Identidade digital é efêmera. Identidade digital está incompleta. Identidade digital é opcional. E, mais interessante de tudo, uma única entidade física pode apresentar vários conjuntos diferentes de declarações e, portanto, ter várias identidades digitais diferentes. Identidades digitais são muito possivelmente mais úteis quando eles não têm uma correspondência 1: 1 a uma entidade ontological.

O problema de identidade
Um conceito de identidade digital baseada em declarações faz com que muitos problemas interessantes. Primeiro é o fato de que uma identidade tem um preço. Você pode comprar uma nova identidade por apenas alguns milhares de dólares. Para que o money, você obtém um número da previdência social funcionando juntamente com um endereço válido que você pode alterar. Licenças, cartões de crédito, passports e o restante do driver podem ser tinha com isso. Se você desejar uma identidade com um histórico pessoal verificável, que provavelmente custará é um pouco mais.
Algumas pessoas, inclusive me, declarar que isso significa que a identidade ontological é sem sentido como ela se relaciona aos sistemas de identidade digital. Pessoalmente, acho identidade verdadeira (ou pelo menos, correção de identidade) para ser irrelevante e uninteresting quando lidar com ele no contexto de um sistema digital. Para a grande maioria dos aplicativos, identidade simplesmente significa que você pode estar consistente. Se você não conseguir apresentar o mesmo está para mim hoje mesmo que você fez duas semanas atrás, vou assumir que é a mesma pessoa/entidade/computador e dar a você qualquer acesso que concedido a você última vez.
Considerando que true, ontological identidade está não apenas efêmero, mas irrelevantes para a maioria dos aplicativos, não me importo ligar você a uma entidade do mundo real. Apenas preciso correlação, não é verdade identidade física, para a maioria dos fins. Qualquer aplicativo que depende de ligação identidade a uma entidade física e imutável é doomed desde o início, e depender de uma conexão segura significa que sempre fará erros e eles sempre será críticos. Qualquer pessoa do mundo real pode prejudicar um sistema simplesmente residente ou retenção as declarações de identidade ou, claro, compartilhando-los (inadvertidamente ou deliberadamente) com outra entidade.
Em vez disso, criando um sistema que (1) se baseia no pressuposto de que qualquer identidade reivindicada é falsificação e (2) que simplesmente tentar correlacionar identidades entre as sessões, podemos criar um sistema muito mais resistente, úteis e valioso. E nós desperdiçar recursos muito menos tentar resolver um problema que, em todo o histórico, ninguém foi capaz de resolver sem outrageous violações de privacidade pessoal.

Autenticação de identidade
Outro problema com identidade é que a identidade por si só não é algo que você pode usar. Ainda, em todo o histórico, identidades foram geralmente tomadas para concedido, sem a autenticação. Do Shakespeare Henry IV, há uma passagem no qual um caractere diz, "Estou Robert Shallow, sir, um esquire ruim desta região e um dos justices do the paz o Rei." Curiously, o caractere a quem justiça Shallow foi falando levou essa declaração de identidade como verdade, com nenhuma verificação. Voltar em formulários anteriores da literatura, como Sagas Norse, e você encontrará declarações semelhantes de identidades feitas por Thor e Odin, que foram aceitas imediatamente sem pergunta.
Obviamente, se você tiver apenas um olho, é seqüestro em um steed esta oito e afirmam ser Odin, um pode argumentar que você forneceu alguma quantidade de verificação da identidade. No entanto, na Internet, não é possível usar as montagens que é divertido como verificação da identidade. Como o antigo diz, "na Internet ninguém sabe tiver um cachorro." Portanto, não autenticadas declarações de identidade mal poderia nunca são aceitos. Portanto, precisamos alguma forma autenticar a identidade.
"Para, há o rub." (Mítico.) Como você pode provar sua identidade? Afinal, o prova de sua identidade é tão importante, talvez mais assim, como a identidade real. Portanto, como nós provam identidades? O método que são usados para usar era uma forma de autenticação secreta compartilhada, conhecida como senhas. Em 14 de fevereiro de 2006, o presidente da Microsoft Bill Gates declarado que as senhas seriam eliminadas onde posicionar os dinossauros em três ou quatro anos.
Mas à medida que escreve em março de 2009, é bastante claro que lista estava errada. Eu tenho senhas novamente agora que eu tinha em fevereiro de 2006. Apenas no trabalho, eu tenho minha senha de rede, minha senha do UNIX, a senha para a despesa de relatório de sistema, a senha para o sistema de RH, senhas para o agente de ações da empresa e os provedores de benefícios, as senhas de raiz para minha máquina de desenvolvedor e alguns servidores, as senhas de administrador para Meus laptops, o PIN para meu telefone e alguns de estranhas senhas para acessar os produtos da empresa como vários usuários. Ainda assim, apesar de ter tantas senhas, pode Honestamente dizer que eu realmente não deseja senhas foram inativos. Eles não são, na verdade, uma declaração de autenticação inválido.
O que Bill Gates estava pensando? Ele pensou, três anos atrás, que agora InfoCard poderia ter substituído dessas senhas. Renomeado de InfoCard, que foi, finalmente, o Windows CardSpace, é um tipo de tecnologia de autenticação fornecido no Windows Vista e posterior no Windows XP SP3.
Pontos vá para qualquer pessoa que já criou um cartão. Eu lhe dará crédito extra se você encontrar um site único que aceita uma credencial do Windows CardSpace. Se desejar apenas experimentar, você pode fazer parte em um teste de beta de O InfoCard do Windows Live .

Os interessados na identidade
Há, claro, outras maneiras para autenticar uma identidade. Alguns são mais úteis em determinadas situações. Para entender onde, você precisará compreender a diferença entre os interessados em um sistema de identidade.
Um provedor de serviços de identidade é alguma entidade que fornece um serviço para as outras partes. Normalmente, o provedor contém o banco de dados de identidade e autentica os usuários finais de identidades. Normalmente, o provedor não é uma pessoa. Portanto, o provedor pode lidar com muito volumes maiores de dados estruturados que uma pessoa pode. Por exemplo, um provedor pode usar um segredo compartilhado de comprimento arbitrário para comprovar sua própria identidade. Portanto, a credencial usada para autenticar a identidade de um provedor de identidade normalmente pode ser várias ordens de magnitude mais complexos do que o que você e possa se lembrar. Conseqüentemente, é potencialmente várias ordens de magnitude mais seguros. Digo "potencialmente" porque se ele realmente é depende bastante como os segredos são gerenciados. Ele faz não bom ter um segredo de 4096 bits para provar sua identidade se, na verdade, não mantivê-lo secreta.
Provedores de identidade muito facilmente podem usar construções como certificados digitais para se autenticar. Um certificado digital é simplesmente um relativamente ajustável bloco (alguns milhares de bytes) de informações estruturadas. Um computador pode facilmente enviar que como parte de cada transação. Você e, no entanto, não será muito thrilled se tivéssemos digitar para autenticar para uma transação.
O usuário final é a entidade que precisa ter sua identidade declarada. Com freqüência, o usuário é uma pessoa, mas que não é sempre o caso, o usuário também pode ser um sistema de computador. Portanto, a qualidade das declarações que o usuário pode apresentar varia muito.
Finalmente, há a terceira parte confiável. A parte confiante é a entidade que confia o provedor de identidade para verificar o usuário antes de fornecer o usuário algum serviço. A terceira parte confiável é quase sempre um sistema de computador. Na medida em que a parte confiante comprova sua própria identidade para um usuário e o provedor de identidade, ele pode fazer isso com igualmente as declarações de alta seguras como o provedor de identidade usado.
É importante observar que um usuário em um cenário é geralmente uma terceira parte confiável em outro. Se o usuário é uma parte do software, ou tiver a ajuda de uma parte do software, este usuário pode facilmente lidar com os mesmos tipos de dados estruturados como o provedor. Isto é porque identidade distribuída protocolos, como OAuth e a vários parte de especificações de segurança do WS-* enfatizar bastante significativas quantidades de dados estruturados para autenticação — eles são voltados principalmente serviços de autenticação para si. Mesmo quando as especificações lidar diretamente com as pessoas, elas tendem a ser brokered por meio de serviços que podem manipular os dados estruturados em nome das pessoas. Geralmente, o agente é apenas um aplicativo no computador do usuário.

Usar identidades
O conceito que um usuário (uma pessoa) usa um sistema de computador como um intermediário ao acessar serviços a partir de uma terceira parte confiável é muito importante. Ele vai para o coração do como criar identidades utilizável por pessoas, ao contrário de sistemas. Infelizmente, diferente do InfoCard, que até agora tem encontrado pouco sucesso, alguns sistemas realmente abordam esse tópico. Em grande parte, o fluxo do processo quando uma pessoa física usa um serviço de identidade para obter acesso a algo é semelhante a Figura 1 .
Figura 1 fluxo do processo de usando um serviço de identidade
Observe a caixa "em seguida, A Miracle ocorre" (TAMO). Os aspectos de sociotechnical do sistema — como você permite que usuários tirar proveito delas — é onde um sistema está realmente feitas ou interrompida.
Houve muitas tentativas de resolver o problema TAMO. Mais fornecida sobre devido a incongruity que na Internet queremos usar identidades de alta seguras, geralmente base certificados, mas os usuários persistentemente recusam a digitá-los sempre que precisam acessar um serviço. O Microsoft Passport, atualmente chamado Windows Live ID, foi uma tentativa de início. Google tiver inserido o fray com sua conta do Google, e há outras pessoas, bem. Até mesmo o Windows CardSpace pode se dizer que está foram uma tentativa de resolver esse problema. Todos são projetados para fornecer algum nível de SSO. Todos os tiverem êxito, basicamente, ao fazer isso, dentro dos domínios pertencentes a seus purveyors várias das soluções específicas. Todos falharam quase inteiramente fora de domínios do seus purveyor.
No restante deste artigo e a parte 2, será resolver esse problema em mais detalhes. Observe que eu não purport para resolver o problema, mas apenas para destacar alguns motivos por que ninguém mais tiver ainda resolveu o problema ou. Finalmente, será chegar a um conjunto dos princípios que eu acredito que deve seguir qualquer solução para esse problema. Que, por sua vez, causará uma conclusão que diz, para somá-lo, identidade ontological pode ser apenas um sonho de pipe.

Quantos identidades você possui?
O desafio grande em relação à identidade é não na criação de um sistema de identidade que pode fornecer o SSO, mesmo que que seja onde a maioria do esforço técnica será. Não é mesmo em que a solução funcionando sem problemas e utilizável, em que, infelizmente, menos esforço será. O desafio é que os usuários atualmente têm várias identidades. Como mencionei anteriormente, eu tenho bem mais 100. Em uma base diária, eu uso pelo menos 20 ou 25 deles. Talvez os usuários têm identidades de muitos, mas eu consideraria não que uma conclusão foregone.
O purist agora dizem que "o SSO pode corrigir esse problema." No entanto, eu não acho que é um problema. Pelo menos não é o grande problema. Eu gosto de ter várias identidades. Ter várias identidades significa que pode descansar certeza de que os vários serviços que uso não pode correlacionar minhas informações. Não tenho que fornecer meu provedor de email minha identidade do agente de ações, nem Tenho que dar minha empresa de cartão de crédito identidade que uso no meu site favorito de compra on-line. E apenas sei que a identidade que uso para a foto compartilhamento site. Ter várias identidades me permite manter minha vida e minha privacidade, compartmentalized.
Além disso, se a empresa de cartão de crédito consiga obter próprio hacked, todas as outras identidades não são afetados. Se eu tivesse uma única identidade, que pode ou não ser o caso, dependendo de como essa identidade única foi implementada. Um sistema SSO implementado corretamente nunca exporia um site usando o sistema a uma falha no site de outra, não relacionado. No entanto, aplicar essa separação não é trivial, e se o provedor de identidade for comprometido, todos os sites que depende dele automaticamente for comprometido.
Esse último ponto é um motivo por que os sistemas de identidade digital Cameron descrito, até o momento, falharam para se tornar o provedor de identidade universal único — qualquer provedor de identidade única é uma entidade extremamente confidenciais.

Princípios de identidade
Há vários princípios de identidade que devem ser atendidos de pelo menos alguma forma para fornecer um sistema de identidade digital bem-sucedida. Elas diferem muito das leis que Cameron descrito no papel leis de identidade. Leis Cameron foram princípios de design — use casos, mais ou menos — que essencialmente definir requisitos técnicos para um sistema de identidade digital confiável. Assim, eles são um conjunto de critérios necessários, mas suficiente para o sucesso. Apesar de muitos sistemas podem ser criados para atender ou exceder leis Cameron, não acho que qualquer uma delas será amplamente bem-sucedida sem também levando em consideração os princípios que eu defino aqui. Meus princípios são princípios de nível superior, lidar com requisitos de negócios, não com pontos de design direto do sistema.

1. O provedor de identidade é pelo menos tão confidenciais como a parte confiante mais confidenciais.
Em primeiro lugar, como mencionei anteriormente, o provedor de identidade é confiável por todas as partes. Esse é o motivo pelo qual nós nos referimos a eles como "partes confiantes." Isso significa que o provedor de identidade deve ser pelo menos bem protegido pois a parte confiante mais confidenciais requer. Esse único ponto é por que muitos dos sistemas universal candidato tem Falha ao criar alcançar amplas SSO sistemas — a relação de confiança simplesmente não existe. Mesmo se a relação de confiança é garantida, é muito difícil provar por que uma parte deve confiar outro.
Você deve confiar em seu fornecedor de correio electrónico com suas informações de conta bancária e todos os seus dados de conta bancária? Se a resposta for "não", você deve confiar que fornecer a identidade você usa para entrar em seu banco não. Os consumidores hoje são avalanche por software não confiável, incompreensível pop-ups e fornecedores de anti-malware (legítimos e não tão legítimas) que afirmam que você não pode, possivelmente, navegar na Internet com segurança, a menos que você paga-los. Conseqüentemente e bastante organizadamente, consumidores confiam praticamente ninguém. Organizações poucos hoje são confiáveis para ser candidatos provedores de identidade de outras organizações. Criar esse tipo de relação de confiança não é barata. Mantê-la é uma proposta frágil. E ganhando-lo novamente depois perdidas devido a uma violação é quase impossível.
Se nunca veremos uma empresa fornecendo um sistema de identidade digital de universal bem-sucedida, ele será de uma empresa que tenha obtido um nível muito alto de confiança. Curiosamente, muitos dos jogadores no espaço de provedor de identidade não estão muito altos até as pesquisas, ou eles não aparecem em todos os (consulte quinta anual pesquisa o Instituto ’s Ponemon of Companies mais confiáveis para privacidade ).

2 Permite que a empresa para proteger seus relacionamentos com clientes e para o proprietário e controlar informações que ele considere como comerciais confidencial.
Qualquer pessoa que tenha um MBA sabe que há três maneiras de ser bem-sucedida com uma empresa: você ter o produto mais inovadora, ou você tem o menor preço, ou excel no cliente intimacy (ou alguma combinação de todos os três). Curiosamente, praticamente toda empresa está interessada no segundo cenário: intimacy do cliente. Relacionamentos com clientes, especialmente em uma empresa on-line, são sacred! Em um mundo onde alternar custos está próximo a nada, onde todos os usuários garante (para alguns definição ampliada da "garantias") o menor preço, e mesmo produto está disponível em qualquer lugar, chave de relações tornam-se do cliente. Mesmo onde inovação acontecer, como em rede social e provedores de email, conexão de cliente é crítica ainda.
Uma razão primária porque nenhum site grande aceitar credenciais de outra empresa (ou outra empresa que não usou possui-las, como no caso de Expedia) é que ele dilutes sua relação com seus clientes. Imagine, por exemplo, se Yahoo simplesmente recebido uma declaração de NetIdentitiesRUs que, Sim, ele realmente é cliente 923071235309342-2 que assinados apenas no. Yahoo não deve possuir o banco de dados de seus clientes. Ele não deve saber quem o cliente realmente é. Yahoo pode não mais gerenciar o cliente e o sistema da maneira que ele quisesse. Ele não poderia fazer pesquisa de cliente por verificação cruzada a identidade com bancos de dados de suas subsidiárias e aquisições. Ele pode não mesmo vender as informações a terceiros para a receita extra (deve ele deseja e tinham os clientes decidido no, é claro). Claramente, Yahoo não ser especialmente interessado em desistir tudo isso e, conseqüentemente, seria necessário alguns incentivos excepcionais para fazer isso.
Agora, imagine em vez disso, que Yahoo é o provedor de identidade. Yahoo pode obter informações sobre o exatamente onde cliente 923071235309342 2 vai na Web porque ele saiba exatamente quais sites solicitam declarações para esse cliente. Yahoo pode compilar dados valiosos em hábitos de navegação do cliente, permitindo anúncios well-targeted extraordinariamente com astonishingly altas taxas de cliques. Para uma organização ad-suportado e especialmente um que está realmente no negócio anúncio próprio, que é uma vantagem competitiva que você apenas não pode conceder backup.
Confiar em identidades originários de outras empresas poderia ser equivalente a desistir enorme oportunidade. Fornecer seu próprio para outras pessoas deve ser saltar sobre ele. Em outras palavras, há um conflito e o resultado é exatamente o que nós está vendo na Web hoje. Em conglomerates, vemos uma identidade universal, e embora todos os principais conglomerates também sejam provedores de identidade, praticamente ninguém depende-los.
Essa análise aponta para uma assimetria fundamental no provisionamento de identidade. Não há valor grande em sendo o provedor de identidade e nenhum valor em todos os no que está sendo a parte confiante. A menos que o mercado pode descobrir maneiras Equalizar os dois, continuaremos ver como muitos provedores de identidade como partes confiantes, com praticamente uma relação 1: 1 entre eles.
Verifique novamente no próximo mês quando eu veremos os princípios restantes nesta série de duas partes.

Jesper M. Johansson é arquiteto de segurança principal para uma empresa de 200 empresas da lista Fortune conhecida, trabalhando em visão de segurança com base em risco e estratégia de segurança. Ele também é editor colaborador da TechNet Magazine. Seu trabalho consiste em garantir a segurança em alguns dos sistemas do mundo maiores, mais distribuídos. Ele contém o título de Ph.d. em sistemas de informações de gerenciamento, tem mais de 20 anos experiência em segurança e é um MVP em segurança da empresa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.

Page view tracker