It's me, and here's my proof: why identity and authentication must remain distinct

My February Security Management column is posted:

https://www.microsoft.com/technet/community/columns/secmgmt/sm0206.mspx

No matter what kinds of technological or procedural advancements occur, certain principles of computer science will remain -- especially those concerning information security. I’ve noticed lately that, among all the competing claims of security vendors that their latest shiny box will solve all your security woes, a basic understanding of computer science fundamentals is missing. Because good computer science never loses importance, and because knowing the science can help you choose products and develop processes, from time to time I will cover such topics in this column. This month I’d like to explore the concepts of identity, authentication, and authorization, to help you understand their important distinctions, and to help guard you against the increasingly common tendency to combine the first two.

Comments

• Anonymous
  January 01, 2003
  Digital ID World has a blog called "Editor's Corner" - and in a recent edition, they talk about "Network...
• Anonymous
  February 16, 2006
  An excellent article - very nicely underlines the characteristics that separate a claim of identity from its associated proof.
  
  There are a few other notes I'd make about why you want to separate claim from proof:
  
  New proof technologies come out from time to time, with varying levels of strength.  New strength requirements dictate that an organisation review the strength of their proofs - should this require them to change their employee's identities within the system?
  
  What about if the authentication provider changes (you authenticate against an LDAP server, rather than directly to the domain controller) - should your identity change then?
  
  Obviously, the answer ought to be "no".
  
  We're being rather fast and loose with the term "identity", according to some people's definitions, so I'll underline here that identity is not a thing, it's a relationship between at least two parties, where one party wishes to be recognised by / recognise the other each time they communicate.  You can call that an identifier, if you like, or an identity.  Some people assert that we have one identity, but several identifiers, I prefer to talk about having multiple identities (some of which can be taken away from me!)
  
  Without a separation of identity and authenticator, or claim and proof of identity, you would have no way to include a "duress" authenticator (used in banking and other circles to indicate that you are getting access because you have been forced to provide it).  [Okay, you could identify yourself with a different finger, or the other eye, but I think you can see how that would be a greater risk than typing the other password]
  
• Anonymous
  February 17, 2006
  Let's not forget there's also another identity mapping layer that should always be kept conceptually idependent and site configurable in basic computer science terms.  There must be a layer that enables mapping more than one Authentication Identity to a site or resource specific Authorization Identity.  
  
  A separate Authorization Identity is required to permit mapping more than one external trusted Authentication Identity such as other domains or WS-Security realm authentication services, to site specific, private local resource Authorization rights and properties for that individual.  Management of group rights to access a self service web page, and the user's associated private account numbers at that site, must remain local to the site to retain privacy and security.  At the same time, reuse of external trusted credentials must be accomodated.
  
  This means that while the Authentication Identity and Authorization Identity can both be the same in the classic enterprise model, they cannot be a unary relationship in a many-to-one world that is required to enable user choice of reusable credentials (eg a logon/password or finglerprint) and site choice of reusable authentication services (eg trusted domains or WS-Security realms).
  
  The ongoing industry and educational failure to conceptually recognize and integrate system and service level support for administrative mapping of multiple trusted Autentication Identities to site specific Authorization Identities, is the fundamental cause of difficulties with reuse of single credentials and enabling single-signon that has been such a struggle for the industry.  
  
  This does not require a particular technology such as PKI or LDAP or Kerberos, just the basic functionality to enable administratively managed trusts of more than one Authentication Identity and authorization service.  Nor is it a solution to push user Authorization rights and user properties up to yet larger hierarchial Authentication Identity trees, which would introduce major SOX and HIPPA privacy and security issues.  The answer is to keep Authentication Identity and Authorization Identity conceptually separate and securely and administratively mappable.
  
  The pragmatic model for this is 'we take Visa and Mastercard'.  User selected identities and credentials Authenticated by one or more externally trusted services, can be mapped to site specific Authorization Identities to access site specific services, rights, and accounts.  
  
  
• Anonymous
  February 17, 2006
  One other related thought and goal.  The mapping if identites to rights and accounts all too often continues to happen at the code layer, perhaps by mapping a system enforced user logon to user properities and accounts in a local database via a database index.  
  
  That's pretty ugly and weak security.  The question is how do we push that mapping up into administratively managed system enforced security of the sort typically desired in enterprise systems?  
  
  The answer is for the industry and enterprises to strategically invest in system and service level security engines that support administrative level mapping of trusted Authentication Identities to system secured Authorization Identites that include the user's locally assigned resource group rights and account properties.  
  
• Anonymous
  February 22, 2006
  The comment has been removed
• Anonymous
  April 06, 2006
  Interesting article but I disagree with your conclusions.
  
  My wife authenticates me by biometrics (my appearance or my voice on the phone) and this works wonderfully - there is no reason that a computer won't be able to in the future. With a security guard ensuring that gummy bears and severed fingers aren't used at an access point (say a data centre) security can be quite strong. You have fallen into the trap of assuming limitations onto computer systems today will always remain (the human body is a system and it is very good about identifying and authenticating other humans - comptuers can and will catch up).
  
  One point you did not bring up was that authentication of an identity, even if it is absolute (say an atomic-level scan of every atom in my body), would not always be sufficient -- sometimes my authentication should be based on time of day or locaiton (i.e. I can only successfully authenticate to a stock trading application on a particular trading floor during market hours -- yes, I realize that part of this is authorization not just authentication).
  
  You mention that you need to have proof as a secret. Say I want to determine if someone claming to be Tiger Woods is the real Tiger Woods. One method I could use is to have him shoot a round of golf. If he really was Tiger then I'd expect a good game and if he was an imposter, he wouldn't be able to match one of the world's top golfers (at least the F.A.R. would be quite low). Security is about risk management -- coming full circle on my comment, my wife could have an identical twin that I don't know about but I'm not going to go about asking her for a password every time I see her!
  
  - Doug
• Anonymous
  April 07, 2006
  Of course, if Tiger's having a bad day, he'll miss your standard for authentication - you'll refuse to recognise him, but you'll happily take Jack Nicklaus in and give him access to Tiger's bank account.
  Biometrics measure what they measure, and as long as they can be matched - as simple biometrics can - they can be fooled.  You then have to increase the complexity, often to the extent that the real biometric will fail the test (Tiger, you shot 67 last time, and today it's 68 - I refuse to believe your assertion).
  Since many biometrics can be directly observed by the public, and reproduced easily (fingerprints are really easy), they are much more claim than proof.