So my field in IT is Identity and Access Management (IAM). Go away if you don’t want to learn what that is.
I came buy this interest though high level network protocols, operating systems and cryptography.
OK – so one of the main challenges in IT is dealing with access control. You are custodian of some resource (like a program) or data and you need to control who has access to it. If it was a physical resource you could put it in a secure location under lock and key, but even that is often more compkicated than it sounds.
For networked programs, you are advertising the location of your resource onto the network (which might be public or private). So it comes down to about four or five concepts:
- Authentication
- Identity Proofing
- Authorization
- Other benefits/complications
- Data Security/Transmission Security
Authentication
How do you prove to the resource that you are the person allowed access? Basically you provide a credential (like a used id) and proof that the credential is yours. That generally is one of three things:
- Something you have – like your debit card, or a key card or a smart card.
- Something you know – like a password, pass phrase or answers to security questions.
- Something you are – A fingerprint, signature, retinal scan, etc.
Within each category some ways (factors) to authenticate a credential are weak and some are stronger. The overarching wisdom is that to achieve strong authentication you need multiple factors from different categories.
Authentication protocols are really neat. There are lots of hidden gotchas. Is the resource you are talking to actually the resource you intend? Is there someone in the middle listening or modifying your authentication? Once authenticated how long is it good for? Once authenticated can someone hijack your session? And about a dozen other considerations.
And then you get into encryption. How to keep the whole authentication transaction secure? And with asymmetric keys the key exchange itself can be you credentials exchange.
About 12 years ago I read this introduction to the Kerberos Authentication protocol. I still like it. http://web.mit.edu/Kerberos/dialogue.html Kerberos is a common authentication protocol now used within Windows Operating systems.
Identity Proofing
It may not be obvious, but successfully authenticating does nothing to prove that you are who you say you are. At best it says that you are the same person to whom I issued the credential. Consider getting a gmail account. To sign in you need your e-mail address and a password. But that address can be anything – when you signed up for gmail you might have chosen Queen.Victoria@gmail.com as your address. It doesn’t mean that you are Queen Victoria. And gmail doesn’t care – it only cares that it is the same person using that credential every time. There is no identity proofing.
Consider an application that provides access to your medical records. Now we need some identity proofing. Generally identity proofing happens only once – before the credential is issued. Authentication happens every time you access the application.
Another big difference is that authentication is all about distrust. Identity Proofing relies on trust. Here are some major methods of identity proofing:
- Presenting another trusted credential – like a driver’s license or passport. In this case, you are trusting whoever issued that credential to have done good identity proofing.
- A trusted witness – A 3rd party who is trusted by both the register and the registrar vouches for the identity.
- An oath is sworn or a contract signed – The person swears (or affirms) their identity. Trust here in the consequence to a fraudulent oath being sufficient to prevent such fraud.
Neat. Obviously any identity proofing scheme is only as good as what it trusts. And sooner or later a chain of trust has to dead end somewhere.
Authentication
So you’ve obtained a credential and authenticated with it. What should you be allowed access to? For instance consider our medical records application. You should be able to see your own medical records. Your doctor should be able to see all their patients records and occasionally other doctors patients for whom they are providing consultation.
Now managing access control for every credential is very hard. So generally some guidelines are used to allow this management. In general, you give each credential the minimum access necessary. Second you group like credentials together and manage access based on the group rather than the individual.
The current grouping mechanism in vogue is role based. So instead of making a group of everyone who needs access to a certain printer you are making a group of everyone who is a marketing manager. In theory this means that future management is easier. Adding a new person, having them acquire a new role or leave an old one as easy operations. But it means the setup and design can be quite complex.
Also you can split authorization into coarse grained – which is often built into the authentication protocol – and distinguishes which resources a credential can access. And fine grained, which is normally part of the application, which controls which features of an application are accessible.
Other Benefits and Complications
The devil is in the details. For instance, does the group that does identity proofing need to be the same as the one doing authentication to be the same as the one doing authorization to be the same as the one running the resource? Of course not.
And that can be flipped a dozen ways. What about having credentials supplied by two different trusted partners allow access to your application? Federation might be the answering to your needs.
Auditing and compliance – we need to track everything. When is a credential used? To access what? When did registration occur, or enrollment? Are there any changes to the credential? And reporting – who out of all the issued credentials actually has access to your resource.
Oddly, once you’ve collected all the information necessary for identity proofing, authentication and authorization, that data itself might be useful for other reasons. If you’ve setup role-based authorization your groups likely map to the actual organizational structure of your business. At the very least you should have a workable phone book/e-mail directory. But with some imagination that directory can be used for many other purposes. Take Windows. It leverages the directory made from its credentials for e-mail routing, patch distribution, and desktop lockdown.
Data Security and Transmission Security
Strictly speaking it isn’t part of IAM, but it would be a shame if you secure your access management if your systems can be bypassed and the resources and data read or modified regardless. Right?
The same cryptographic systems sitting at the root of your authentication systems can also be used for encryption of your resources and data when it is being transmitted or sitting on the hard drive. You can try and ensure that your access control systems need to be used to get at the data.
The End
I’ve only brushed the surface. If y’all want more information I’d consider googling some of these things:
Kerberos, SAML, Radius, PEAP, RSA, PKI, 802.1x, privacy, identity theft, OpenID, Identity Cards, NIST 800-63, FIPS 140-2