The authorisation is a security mechanism to determine access levels or user/client privileges related to system resources, including files, services, computer programs, data and application features. This is the process of granting or denying access to a network resource that allows the user access to various resources based on the user's identity.
The authorisation is a security mechanism used to determine user/client privileges or access levels related to system resources, including computer programs, files, services, data and application features. An authorisation is usually preceded by authentication for user identity verification. System administrators (SA) are typically assigned permission levels covering all system and user resources.
During authorisation, a system verifies an authenticated user's access rules and grants or refuses resource access.
A good example is house ownership. The owner has full access rights to the property (the resource) but can grant other people the right to access it. You say that the owner authorised people to access it. This simple example allows us to introduce a few concepts in the authorisation context.
For instance, accessing the house is permission, that is, an action that you can perform on a resource. Other permissions on the house may be furnishing it, cleaning it, repairing it, etc.
Permission becomes a privilege (or right) when it is assigned to someone. So, if you permit your house to your interior decorator, you are granting them that privilege.
On the other hand, the decorator may ask you permission to furnish your house. In this case, the requested authorisation is a scope, that is, the action that the decorator would like to perform at your home.
Sometimes authorisation is somewhat related to identity. Think of the process of boarding a plane. You have your boarding pass that states you are authorised to fly with that plane.
However, it is not enough for the gate agent to let you get on board. It would help if you also had your passport stating your identity. In this case, the gate agent compares the name on the access with the name on the boarding pass and lets you go through it if they match.
In the authorisation context, your name is an attribute of your identity. Other attributes are your age, your language, your credit card, and anything else relevant in a specific scenario.
Your name written on the passport is a claim, that is, a declaration stating you've got that attribute. Someone reading your name on your passport can be sure of your name because they trust the government that issued your passport.
The boarding pass, along with the proof of consumers' identity, represents a kind of ‘access token’ that grants access rights to jump onto the plane.
In the scenarios described above, you can see that authorising enables entities to execute tasks that other entities are not allowed to complete.
Computer systems that similarly use authorisation work.
Handling Authorisation in a Computer System
In computer systems, authorisation rules are part of an IT discipline called Identity and Access Management (IAM). Within IAM, authorisation and authentication help system managers control who has access to system resources and set client privileges. The way that IT systems deal with authorisation services is very similar to a real-world access control process.
Authorisation Use Case
Consider a collaboration tool like Google Docs.
The application allows you to create and share documents. Other permissions include being able to update, delete, comment on a record. If you are the document owner, you can share it with someone else and define one or more access policies. For example, you can share your document with someone by letting them add comments.
The authorisation is the basis by which the authority to complete the various transaction stages is delegated. These stages include Recording (initiate, submit, process), Approving (pre-approval, post-entry review), and Reconciling. The main aspects of authorisation are:
- Privilege: Typically, the application for which an individual is granted the ability to use or the duty in which they are given the ability to perform.
- Role: Typically, a type of user, such as staff, principal investigator, administrator or other, more specific roles such as payroll coordinator. This often is dependent upon the privilege the function is associated with.
- Action: Typically, an action that the user can perform. Some examples are initiating, submitting, approving, reconciling or viewing (inquiry).
- Span-of-control: This is a restriction upon the action granted to a user. This is often a restriction by organisation code, budget number, or other organisational or financial entity defined restriction.
All transactions and activities should be carried out and approved by employees acting within their range of knowledge and proper span of control. Acceptable authorisation practices serve as a proactive approach for preventing invalid transactions from occurring.
Authorisation systems are software that determines whether a given user profile or identity is allowed to access a system or perform a specific action. Authorisation tools provide access control through centralised enforcement of access policy to a multi-user computer system. Authorisation systems are usually part of more extensive identity processes, serving as the conclusion of a workflow that includes additional authentication and identity management functions.
Authorisation capabilities are sometimes offered as a standalone product, integrating with other point solutions in the identity management and system access workflow. However, many solutions will provide authentication and authorisation features within a single solution. Larger identity management suites have become a more centralised and widespread mechanism for delivering authorisation capabilities and other necessary identity-related processes.
Modern and multiuser operating systems depend on effectively designed authorisation processes to facilitate application deployment and management. Key factors include user type, number, credentials requiring verification and related actions and roles. For example, a role-based authorisation may be designated by user groups requiring specific user resource tracking privileges. Additionally, commission may be based on an enterprise authentication mechanism, like Active Directory (AD), for seamless security policy integration.
For example, ASP.NET works with Internet Information Server (IIS) and Microsoft Windows to provide authentication and authorisation services for Web-based .NET applications. Windows uses New Technology File System (NTFS) to maintain Access Control Lists (ACL) for all resources. The ACL serves as the ultimate authority on resource access.
The .NET Framework provides an alternate role-based security approach for authorisation support. Role-based security is a flexible method that suits server applications and is similar to code access security checks, where authorised application users are determined according to roles.
Definition of Authorisation Using Authorisation Strategies
There are several different authorisation strategies that computer systems leverage during application deployment. The most prominent ones are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). There are multiple other alternatives, including Graph-Based Access Control (GBAC) and Discretionary Access Control (DAC). Each one of these strategies will help application developers deal with different authorisation requirements and authorisation services.
Attribute-Based Access Control (ABAC) and Authorisation
When using ABAC, a computer system defines whether a user has sufficient access privileges to execute an action based on a trait (attribute or claim) associated with that user. An example use case of this authorisation process is an online store that sells alcoholic beverages. A user of the online store needs to register and provide proof of their age. In the authorisation context, this scenario can be described as follows:
- The online store is the resource owner.
- The alcoholic beverage is the resource.
- The consumer's age validated during the registration process is a claim, that is, the proof of the user’s age attribute.
Presenting the age claim allows the store to process access requests to buy alcohol. So, in this case, the decision to grant access to the resource is made upon the user attribute.
Role-Based Access Control (RBAC) and Authorisation
RBAC, on the other hand, treats authorisation as permissions associated with roles and not directly with users. A function is nothing but a collection of permissions. For example, imagine that you work as a department manager in an organisation. In this situation, you should have licenses that reflect your role, for example, the ability to approve vacation requests and expense requests, assign tasks, and so on. To grant these permissions, a system manager would first create a role called "Manager" (or similar). Then, they would assign these permissions to this role and associate you with the "Manager" role. Of course, other users that need the same set of licenses can be associated with that role.
The advantage of using RBAC is that managing authorisation privileges becomes easier because system managers can deal with users and permissions in bulk instead of dealing with them one by one.
What is Authorisation and Access Control?
You are probably familiar with the concept of authentication, the way that security systems challenge you to prove you are the customer, user, or employee whom you claim to be, using a password, token, or another form of credential. You may be less familiar with the concept of authorisation, and the related term, access control.
Authentication verifies your identity, and authentication enables authorisation. An authorisation policy dictates what your identity is allowed to do. For example, any bank customer can create and use an identity (e.g., a user name) to log into that bank's online service. Still, the bank's authorisation policy must ensure that only you can access your account online once your identity is verified.
Authorisation can be applied to more granular levels than simply a website or company intranet. Your identity can be included in a group of identities that share a standard authorisation policy. For example, imagine a database that contains both customer purchases and a customer's personal and credit card information. A merchant could create an authorisation policy for this database to allow a marketing group access to all customer purchases but prevent access to all customer personal and credit card information. The marketing group could identify popular products to promote or put on sale.
We implicitly create authorisation policies when we use social media: Facebook, Linked In, or Twitter may authenticate hundreds of millions of users, but to some extent, we can authorise whether or how these users engage with us. The same is true when you share files, videos, or photos from sites like Google Docs, Dropbox, Instagram, Pinterest, or Flickr or even when you create a "shared" folder on your laptop.
Whereas authorisation policies define what an individual identity or group may access, access controls – also called permissions or privileges – are the methods we use to enforce such policies. Let's look at examples:
- Through Facebook settings – Who can see my stuff? Who can contact me? Who can look me up? – We allow or deny access to what we post on Facebook to users or the public.
- Google Docs settings let us set edit or sharing privileges for documents we use collaboratively.
- Flickr settings allow us to create or share albums or images with family, friends, or publicly under different (e.g., Creative Commons).
- Shares and permissions on the MacOS or the Security tab in a Windows OS file properties dialogue box allow you to set access privileges for individual files or folders.
Correct configuration of access privileges is a critical component of protecting information against unauthorised access and protecting computer systems from abuse, but access control configuration is a tricky business. In our next post, we'll look at how organisations implement authorisation policies using access controls or user permissions. We'll follow that with a post that examines attacks that malicious actors or criminals can conduct when access controls are not adequate to prevent unauthorised use, unintended disclosure, or privilege escalation.
Common Authorisation Only Transactions
With an authorisation, only a transaction, only half of the transactional process is undertaken. These types of charges are usually only used in specific situations. Sometimes it may be to provide a form of deposit for a merchant.
Take one example of a rental car transaction. A driver renting an automobile may have their card authorised to hold an amount that exceeds the rental charge. The rental car company requests authorisation from the issuer for a specified value, but when approval is received, it does not complete the transaction. Once the car is returned, the reserved fund value is adjusted. In a car rental, the final value is usually only for a fraction of the total reserve. However, if the car is damaged—or if additional fees are charged—then the final transacted value will be higher. At the return, the rental car company adjusts the value and submits a concession for the adjusted amount.
Hotels may also charge a reservation fee to cover potential incidentals during a customer’s stay. At a hotel, funds may be charged for room service or à la carte items found in the room. Just as with the rental car, the final amount taken from the cardholder’s account is adjusted when the guest checks out.
Also standard are temporary authorisation holds used by gas stations and restaurants that allow cardholders to add tips.
Businesses may also use authorisation only to sell transactions if an item that a customer wants is temporarily out of stock. The transaction would place a hold on the amount that the product costs while it is being ordered, with the transaction being finalised when the item is ultimately given to the customer.
For a consumer, it is essential to be aware of authorisation only charges. A commission-only holds funds from the cardholder’s account until the actual amount is adjusted or potentially released if no transaction occurs. During the hold, the funds are deducted from the cardholder’s accessible balance.
Banks and financial institutions may charge a business using authorisation only transactions a fee if the transaction is not finalised within a given period. Thus, companies have to weigh the possibility of incurring a cost with the financial benefits of placing a hold on a customer’s account.
Authorisation Systems Comparison
When comparing different authorisation systems, consider these factors:
- Point vs. Suite Solution: There is a range of point solutions for authorisation. However, the most popular and standard solutions are broader suites that centralise all steps of the identification and access process into a single system. Consider whether the business needs a point solution to fit into existing structures or if a complete overall and centralisation would be more efficient.
- Integrations: Any system with authentication capabilities will need to integrate smoothly with other security and identity-based systems. Consider prebuilt or native integrations between each potential authorisation product and the business’s existing tech stack.
How can authorisations fail?
Authorisations can fail for technical or financial reasons. Buyers are notified of failures automatically by most online processors. The cause of an authorisation failure is identified by its error code. Error codes will differ based on the acquirer. The most crucial point is that a failed authorisation means a sale can not be completed. The seller should not ship the product or complete the transaction without an authorisation code.
If the error code indicates a technical problem, then it is usually the seller's job to fix the issue. In rare cases, the acquirer will be having technical issues, and the seller will have to wait until these are set. In most cases, there is a problem with the information being supplied to the processor. This can be an issue with the configuration or the online submission, such as an incorrectly typed or missing value. In this case, the seller should fix the problem as soon as possible. Error codes indicating financial reasons usually mean there is a problem with the buyer's account.