Check out my Windows Store and Windows Phone apps!
The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft
Authentication is often confused with authorization. I’ve even heard of an eCommerce course wherein the teacher was using both terms as if they were interchangeable. In fact, there is a huge difference between them. Authentication is used to authenticate a user with confidential information known only by the user. After the user is authenticated, the only assurance we have is that the user is the one who created the account and provided the confidential information. This information does not include enough detail to know if the user has access to a system-specific function (at least it shouldn’t).
On the other hand, authorization is used to provide information about system-specific functions. Authorization is often used at the application level, after authentication is complete. Once the user is authenticated, the account is authorized to use some functionality in a system by the authorization provider.
When considering authorization, AzMan is usually the component of choice. Many other products are using their own authorization mechanism; SharePoint and Dynamics CRM are a couple of examples.
Now let’s discuss authentication. Before looking toward future trends, it’s necessary to explore some history. We will review why LANMAN is bad, Kerberos is complex but at least can use delegation, and Federated Authentication is the ideal choice.
Once upon a time, there was a need to authenticate users when computer began to talk to each other. Obviously, users wanted to keep a minimum of confidentiality, and administrators needed the ability to restrict access to specific resources.
One of the first implementations of an authentication mechanism was the LAN Manager or LANMAN. This technology was based on OS2 and was co-developed by IBM and Microsoft.
The concept was simple. An LM Hash was made of two parts, containing 7 characters and encrypted with a static key (without a salt). This method of encrypting passwords had many drawbacks. For one thing, because it was divided into two parts, all passwords with less than 7 characters had a static second part, which makes a password really easy to guess.
Also, passwords were not case sensitive!
To address these security issues, a new version of LANMAN was created especially for the Windows NT platform. It was called NTLM or NT LAN Manager.
NTLM is a more complex authentication protocol. It uses three messages to establish the identity of the client. Without going too deep into the details, the underlying cryptography algorithm is mainly MD4 and DES.
A second generation of the protocol was released to make it more secure. NTLMv2 employs the HMAC-MD5 algorithm instead of MD4.
Both of these protocols are secure enough, but once the user is authenticated, he or she is authenticated against a single server in a specific context. If the authenticated service requires access to another resource on behalf of the user, it cannot use those credentials to access the other service. One of the solutions is to use a service account and rely on the system to give the user appropriate permissions.
To mitigate this problem (even if it's more a new need than a problem), a token-based authentication mechanism was created – Kerberos.
Kerberos is a ticket-based system that can authenticate a user and delegate the authentication ticket to another service. By doing that, the user is always authenticated for all the hops in the architecture.
In order to issue a ticket for a specific service, the service itself must be registered in Active Directory. A Service Principal Name is registered for each service/address/port combination and associated to a specific machine.
Kerberos relies heavily on infrastructure components. The first is the KDC dedicated to Kerberos, and the second is Active Directory, which is the authentication source.
Both NTLM and Kerberos are widely used in the corporate world, where all the services are consumed in the local (or wider) network. With the advent of the cloud and other Software as a Service (SaaS), many resources are located outside the organization. Kerberos, which depends upon corporate components, cannot be used outside the organization, except if system administrators wants to open what is usually known as a security breaches.
As always, security is a challenge. The challenge is even greater when there is a mix of on-premise and online services. To address that, a new way of authentication called Federated Identity is now widely used. Office 365 can use Federated Identity, as an example.
Federated authentication is a superset of the well-known SSO (Single Sign On). It’s a superset because it is not only limited to authentication, but also includes additional information. The authentication part is usually known as Federated Authentication.
Many standards can enable Federated Identity as of now, such as OpenID and OAuth. The main difference between these two cases is that the first is for Authentication, and the later is for Authorization.
As an example, if a user wants to access a website, OpenID is the standard that will enable the user to validate that his or her identity. If, on the other hand, the user wants to upload photos to a website, OAuth will be the standard that authorizes the user to access this specific functionality.
To enable those standards, there is a complete set of components under Identity Management. The most common ones are ADFS, along with the not-so-new foundation available that is addressing Identity in general, called Windows Identity Foundation (WIF).
Source: The .NET Developer's Guide to Identity
ADFS is based on the WS-* specifications, which are industry standards for security from the W3C. Those standards include WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security and WS-Trust.
ADFS use a claim-based approach. The simplest way of explaining that is: you trust the claim received if you already trust the issuer. There are some excellent whitepapers on the subject.
On the other hand, you might want to use external services to authenticate your user. Windows Account (Live Id), Facebook and Google can be used as Token Issuers for a claim-based system. To leverage all those Token Services without modifying applications, the Access Control Service (ACS) can be used as a token provider. Afterward, ACS can be configured to accept Tokens from many providers and can perform translation and transformation of tokens so that applications can expect the same format. Obviously, Microsoft offer a great ACS in the cloud called Windows Azure Active Directory Access Control. It can be used by any application, and can authenticate users from identity providers like Windows Live Id, Google, Yahoo, Facebook and any ADFS 2.0 servers.
A great (and free) book is available online concerning MSDN: Federated Identity with Multiple Partners and Windows Azure Access Control Service.
From the unsecured LANMAN to the federation-enabled Azure ACS, the objective remains to give the appropriate rights to the appropriate persons. We began by trusting the users with LANMAN/NTLM; afterwards, we trusted servers using delegation in Kerberos; now, we are trusting “trusters” with Federated Authentication.
Even though many of those security mechanisms are secure enough, users are still authenticating with passwords. What will be the next step? Some are saying that two-factor authentication will be a solution. Some are already trying hardware based authentication mechanisms, and there are already some alternative passwords, such as gesture on the Surface. With the arrival of the augmented reality trend, and the future vision from Microsoft, no one can tell what will happen next.