TLS, or Transport Security Layer, is a component of almost every web server as of 2020. It is a protocol that allows a client computer to authenticate the identity of a server before sending any data, which ensures that sensitive information is not being sent to a fraudulent end point. After verifying the identity of the server, all further communication is encrypted under a set of session keys unique to the client and server. This article will unpack the details of TLS a little later on, but with an important distinction; this article isn’t about TLS authentication, but instead TLS authorisation.
Authentication vs Authorisation
While the concepts of authentication and authorisation might at first seem to be essentially the same, the difference between them is crucial for Internet security. To use a real-world comparison, imagine going to a bank in which you have an active account—be it savings, checking, or anything else. If you want to access your account, you will be asked to present your card as proof that you are the legitimate owner of the account. This is authentication: the process of verifying the identity of a party.
Presenting your credit card to the teller does not, however, grant you access to other bank accounts, nor does it give you permission to wander into the back vault, hop behind the desk, or otherwise engage with restricted areas. This is because although your card is able to authenticate you, it is not able to authorise you to interfere with the working of the bank; for that you would need to present something like a bank-issued ID badge proving your level of authority.
This is why there are protocols on the Internet that ensure both authentication and authorisation of a client are possible. A common and practical method is to use TLS.
As it stands, a lot of sites on the Internet that use TLS authentication do not also use authorisation. However, there are some occasions where you might want to deny access to certain parts of your site to certain users or, conversely, only allow access to certain parts of your site to select users. A lot of University sites, for example, have pages that are only accessible to staff. Facebook also uses authorisation tactics when determining if someone has the ability to see a post. If this is your goal, then you’ll also need to set up TLS authorisation.
Important Concepts
SSL/TLS: Standing for Secure Sockets Layer and Transport Layer Security, respectively, these protocols are one and the same. TLS has long been the upgraded version of SSL, however SSL is still more common in IT vernacular than TLS.
TLS/SSL Handshake: This is the name for the process that occurs the first time a new client makes contact with a server. This process generates unique keys to secure that particular session, predictably called session keys. The server is then capable of remembering the unique session key, and can continue the session if it recognises that the client TLS certificate has an identical key.
Can TLS truly allow authorisation?: Even though TLS certificates were only designed to authenticate clients, their infrastructure makes them ideal for authorisation as well. Doing so does require additional software, which will be discussed further shortly. Ultimately, having a client-side TLS certificate serving double-duty is one of the most secure and simple methods of enabling authorisation to specific white-listed certificate holders.
Authorisation
Typically, when a client computer accesses a web server using TLS, only the server is required to present a certificate for the client computer to verify. However, it is possible to configure a TLS protocol to check both the server AND client certificate in a process called mutual TLS. Since authorisation requires review of the client certificate, a mutual TLS is necessary for TLS authorisation to work. Getting TLS for your site is easy, and can be done at a small cost.
In simple terms, TLS authorisation checks aspects of the client-side certificate to see if a certain certificate-holder is meant to be given the power to interact with select API. Once a client visits a site, mutual TLS will check their TLS certificate. If this is a first visit, there will be no record of that client’s unique certificate values, so a normal TLS handshake will occur. If this is a return visit, then the web server will recognise the session key that was used last time, and can resume from where the client left off. Before giving access to the site, however, a server with implemented TLS authorisation will first check the client certificate for authorisation details.
Typically the server will request an identity token. If you recall the earlier example of the bank, an identity token is like a security badge. This data is passed to a security manager, a separate software element that can parse the token and determine the level of clearance the presented certificate has. It uses data from the provided token and replaces certain information in the properties tree identity fields. According to IBM, the data that is affected is as follows:
- “The IdentitySourceType is set to the user name.
- The IdentitySourceToken is set to the subject name of the client certificate.
- The IdentitySourceIssuedBy is set to the issuer name of the client certificate.”
Once this process is complete, the session will continue using a set of session keys. However, the server will then be able to allow or restrict the activity of the client based on its predetermined parametres.
A key component of this process is that a client certificate must be capable of being propagated throughout the entire process, called the message flow. Since basic TLS authentication only allows for verification of the certificate, additional software is required to carry the client certificate onward through the extra steps. OAuth is an example of a popular and widely used service for this. Spring Security is another such software and may be ideal for a less experienced developer. Should you decide to enable TLS authorisation on a website of your own, make sure to carefully read the details of your chosen software.
The benefit of using TLS as a method of authorisation is that it already has a solid infrastructure in place. Since a TLS handshake involves the generation of unique keys, these are sometimes used in the generation of a security token. Additionally, because a web server can remember the session key of a client computer, it can also remember the changes made to the properties tree identity fields. If you’re interested in learning more about TLS, especially about the traditional authentication aspect, check out this article for more information.