Fine sand – why many CIAM installations require finer authorization

In recent years, many companies have successfully modernized both their internal access management systems (AM) for employees and their access from web applications and SaaS services as well as their customer identity and access management (CIAM) to secure customer access to the eServices and services offered. The tedious multiple entry of credentials such as user names/emails and passwords has been replaced by standards for federation and single sign-on (such as SAML and OpenID/OAuth).

This has already brought significant benefits in terms of providing new eServices and securing cloud usage and, above all, has considerably improved the user experience for users. The centralization of user identification and authentication through Single Sign-On (SSO) is undoubtedly a milestone in the use of such infrastructures, resulting in a number of benefits, in particular:

• The open transmission of unencrypted passwords is prevented.
• Users no longer have to enter new access data for each application.
• The user experience during registration, login and password reset is standardized – recognition values and uniform processes create additional trust and security.
• Attacks on user accounts can be detected and prevented centrally at the identity provider.
• By using ready-made SaaS CIAM solutions, the total cost of ownership (TCO) is reduced compared to alternative solutions that have to be developed and operated in-house.

At some point, however, the limits of these technologies are slowly but surely coming to the surface. While they enable a simple YES/NO decision for access to resources or services such as customer portals, stores or collaboration platforms, a fine-grained distinction as to what the user can then do often remains unclear and must be managed within the framework of the respective application or service.

In the context of business-to-business federations (usually based on SAML), further differentiation can and is made possible via group membership and corresponding notes in the token, but this is usually limited to a few options, as otherwise there is a proliferation of group memberships on the customer infrastructure side.

However, let’s first take a brief look at the advantages of using a CIAM solution, such as the one offered by cidaas.
Properly planned and implemented, a CIAM offers much more than pure “access management”, as it provides functions for:

• the enrollment of new (end) users, manually or via social identity providers
• the validation of user identities, for example via the “ID validator” from cidaas
• Identification and authentication of users during access, either locally or via federation at the identity provider
• the implementation of a simple YES/NO decision (authorization) for access

But what happens then?

A finer demarcation of what a user can and cannot do in the target system is either not taken into account at all (key to the kingdom), or the fine-grained decisions about access are managed in the target application itself. This is usually done without the possibility of controlling this centrally, as each application is programmed individually by its developers. However, this so-called “fine grained authorization” (FGA) or its abstract and centralized management is becoming increasingly relevant in more complex architectures and some manufacturers such as Axiomatics already attempted to promote such centralization a decade ago with standards such as XACML (eXtensible Access Control Markup Language). Although XACML is not considered a complete failure, adoption has fallen far short of the high expectations.

Other (open source) projects such as the “Open Policy Agent” (OPA) with its description language “REGO” have received considerably more attention since their first release in 2016, and a whole series of “FGA” projects, solutions and above all description languages (such as CEDAR from AWS) have developed in the last two years or so that serve the topic of “fine-grained authorization”.

So it’s high time to address the topic and provide corresponding functions from the leading European provider of CIAM tools!

What can we expect in the coming months and what issues need to be addressed?

1. Fine-grained access in the portfolio always depends on the application and is hardly standardized
2. The need exists not only for the user, but also for the auditors and the audit department – because understanding local authorization concepts and seeing through their logic and log messages causes additional effort
3. A sustainable centralized or centralizable solution is not yet in sight – it is primarily about supporting application owners and application developers
4. Although new tool components such as the OPA and similar are available, developers still have to carry out extensive refactoring in order to convert internal authorization logic to new languages and concepts
5. Only when several applications are converted to this standardized logic and description language can policies and their administration as well as logging and auditing be significantly improved

Is the effort of a finer authorization even worth it?

This question cannot be answered in general, as it must be examined for each application, application and service whether a changeover seems sensible. For new software projects, eServices and services, however, there should be a very sympathetic discussion about the adoption of standardized description languages, especially if central infrastructures for policy management, policy administration and joint evaluation can be provided in parallel by the CIAM provider. Nevertheless, it should be borne in mind that the effort required for older applications will probably be difficult to justify, especially as the CIAM will also have to make corresponding adjustments. In this case, it is advisable to check with the long-term corporate strategy whether the replacement or migration of such “legacy” applications is planned and what opportunities arise from this.

What is clear is that the role and importance of CIAM and AM solutions will expand from a simple “gatekeeper” and YES/NO decision-maker to an adaptive and dynamic instance that can also manage fine-grained access rights and ensure their implementation and compliance.

It is also clear that a lot will happen on the application side: just as the functions for “identification” & “authentication” with SSO have been outsourced from the application to external services, fine-grained access decisions will in future no longer be decided by the application itself, but will be outsourced to external services (PDP – Policy Decision Points). The application then only “stupidly” implements the decision of the PDP and grants or denies access to a specific resource.

Of course, this is not worth the effort for every application, but only for particularly critical services with a corresponding remaining runtime. However, new development projects in particular can benefit from the additional modularization – especially if the use of external components for fine-grained authorization is considered and implemented in the application architecture from the outset.

The advantages on the business and user side are obvious:

• Access rules (policies) can be formulated more easily and independently of the application’s programming language – in some cases even by specialist users
• Uniform and centralized logging of accesses
• Consistent, auditable access checks across the application landscape thanks to central, standardized policies
• Decoupling the application logic from the business logic with regard to fine-grained access checks

Centralized “fine grained authorization” has become a reality, and we would do well to prepare and convert our services and infrastructures accordingly.