If we use a computer to create, edit or store sensitive information, then we can expect to be able to limit who has access to it and have mechanisms to support this. In this blog we delve into some of the more common security features of the Windows environment, such as passwords and certificates, along with Microsoft KeyVault.
Username/Password
In the Microsoft Windows environment, we are all very familiar with having to supply a username and password combination when we log in. The username describes who wants access and the password is the secret that confirms that this person really is who they say they are. What we are doing is confirming that this person or user is authentic. This initial process is called authentication and it compares supplied credentials with what is stored in an authentication server.
ClientId/Secret
In a similar scenario, we might have a computer application that wants to access data – without a human being involved. The authentication process is the same, but this time the application supplies credentials in the form of a ClientId/ Secret combination to the authentication server. This is great and works nicely – but there is, however, an inherent problem. Unlike a human who has memory, the application needs to store the credentials away from prying eyes. It could password protect the credentials – but then we enter the realm of chicken and the egg.
Certificate
To try and get around secrets securing other secrets, some clever person thought of a different way of performing authentication. She set herself up as a grand organisation that everyone else was supposed to trust. She then advertised that for a small fee, she could supply time limited packaged secrets back to other lesser untrusted purchasing organisations. Once having this secret package, the purchasing organisation could install it wherever they wanted and trust it to be safe enough to be used for authentication. This package is commonly known as a certificate. This was a great idea, could work with almost all technologies and is to this day a great revenue earner. However, it was soon found to have some painful drawbacks – like having to install it, paying a regular renewal fee, or even worse letting the certificate expire.
Tokens
So now we a have a variety of ways of authenticating users, computers or applications and gaining the identity, principle or claims from the authentication server. Identity, principle, claims? What are they? It is the different flavours of returned information that can be used to authorise what the user, application or computer can do. Claims are packaged inside what is also generally known as a Token. In fact, there are two kinds of token- an Authorisation Token which typically expires after an hour and a Refresh Token that is used to obtain a new authorisation token. The most popular tokens are SAML and JWT and these dominate the authentication mechanism of the internet. If we include the token our authentication data flow now looks like something like this:
Keys
In modern internet architectures connecting different systems from different software vendors, it is common for simplicity to use a single key value instead of credentials or tokens for authentication. If we can imagine a single server that is accessible from two other servers using a shared key. The shared key now must be stored in all three systems for it to work and can become a nightmare when the key needs to be changed:
KeyVault
Instead of each system storing a copy of the same shared key – we move it to a dedicated security store or vault. Each system will need to securely download a copy of the key on start-up and keep it safely stored for a time before downloading again. In more advanced systems the key could be updated in the vault and then interested clients could be notified that the key has changed and they need to download the latest version.
Microsoft Azure cloud amongst other vendors supplies such a technology. Instead of storing many shared keys or secrets in insecure configuration files across many computer systems we simply place each key in the MS KeyVault. The mechanism to obtain a key from KeyVault is to first obtain a token from the authentication server (Azure Active Directory) using either a ClientId/Secret or a Certificate and then presenting the token to KeyVault alongside the address of the key in the vault.
If you have any queries about Microsoft KeyVault or would like to discuss this in further detail please don't hesitate to contact us.
- By Nigel Wardle (Application Architect)