Control of access is a typical part of how a modern authorization system is modelled.
Access Control refers to the control of the access to which something or someone is permitted, and is commonly implemented around access control models.
Hi, I’m Peter Fernandez, and as a CIAM expert, I want to share my experience building the modern Authorization paradigm of Access Control into modern applications.
User Access
Typically enabled via some user authentication mechanism, authorization systems track and determine access based on a combination of Permission and/or Consent — irrespective of whether someone is acting by themselves or on behalf of someone else.
Client Access
Controlling access for something other than a user will typically employ client-level authorization, with Client Credentials, a service account, or some other authentication mechanism providing the context from which Permission(s) would be derived.
Mandatory Access
Mandatory Access Control (MAC), the most common form, is where access permissions are determined by a central authority and which users cannot modify. MAC is often based on predefined policies that specify what users and systems can access based on various factors.
Discretionary Access
In contrast, Discretionary Access Control offers the owner of a resource the discretion to determine who can access it and to what extent. This allows users or groups to share access (with someone acting on their behalf) to resources based on personal preferences.
Access Control vs Consent
Access Control refers to the access to which something or someone is permitted, whilst Consent gives a user the ability to authorize the scope of operation(s) an application can perform when it’s accessing their resources whilst acting on their behalf. Access Control and Consent will typically work hand-in-hand in a modern, secure and compliant Authorization implementation.
Permission
Permission(s) assigned to a user or a machine will typically play a part in determining Access Control. For a user, this may have a bearing on the user interface experience and will ultimately impact the function(s) the user can perform. For a machine — i.e. an account in a non-user context — permission will determine what functionality is available and, by virtue, the operations that can be performed.
Policy
Access Control is also commonly associated with what is known as an Authorization Policy. Authorization Policy is typically comprised of distinct parts — usually referred to as “points”: a Policy Decision Point (a.k.a. PDP), a Policy Enforcement Point (a.k.a. PEP), and a Policy Information Point (a.k.a. PIP) to name but a few — and which get implemented is largely determined by the Access Control model(s) employed.
Granularity
Granularity relates to the enforcement of Access Control and, by virtue, the degree of access control precision required. Fine-grained Authorisation, for example, typically involves employing access control at a level nearest to the protected resource itself. In short, the lower (or finer) the granularity, the more precise you can be about exactly what access is controlled and how.
Access Control Models
Access Control mechanisms enforce policies, preventing unauthorized access while allowing legitimate entities to engage with services securely in a B2C and/or B2B SaaS solution environment. These mechanisms are largely implemented around models that provide Role Based Access Control (a.k.a. RBAC), Attribute Based Access Control (a.k.a. ABAC) and Relationship-Based Access Control (a.k.a. ReBAC), to name a few. Access Control is an essential component in any CIAM integration to ensure secure implementation, and you can read more about it in the following article.
Buy vs DIY
You could build an in-house custom solution yourself…it’s certainly an option. Particularly if you have a team with the time, capacity, knowledge, and expertise to develop SSO; deploy and maintain Attack Protection; leverage OIDC and/or SAML for Authentication, Social and/or (Enterprise) Federation; implement Passwordless, Passkeys and/or MFA, and/or optionally OAuth 2.0 for API Authorization.
The alternative is to integrate with a SaaS solution provided by one of the popular vendors, and the cost of subscribing to one of these typically depends on the features you use and the number of active consumer identities you have.
With vendor-based CIAM the cost is typically associated with the platform hosting the backend service(s) that deliver Authentication, Authorization, Management and Protection from attack. With consumer-oriented software, much of this infrastructure is already in place: cloud-based “compute”, database, network resources, etc. could be a necessity for your solution, and delivering these at scale may be something you also need to do.
Deploying a standards-based open-source DIY solution within your existing infrastructure might provide a more cost-effective approach — delivering secure and robust CIAM without the need to build everything yourself and with the added benefit of more flexibility and control.
Got questions?
Feel free to reach out!
