Customer Identity and Access Management with Curity
A customer identity and access management (CIAM) system offers tools and processes to control access for external parties. It allows customers to authenticate and manage their privacy settings in a user-friendly way. APIs are now of major importance to a customer-facing digital business. They provide the functionality needed to deliver services and good customer experiences. Securing a business nowadays means securing access to APIs.
Why Is CIAM Important?
Secure access implies that APIs can determine whether or not they should grant access based on who is requesting it. To be able to do so, organizations first need to authenticate their users and then enforce their access control policies in their APIs based on the identity of the caller. Consequently, organizations need a CIAM system that not only supports complex user authentication processes depending on their requirements, but also caters to API authorization.
At Curity, we emphasize basing authorization decisions on identity data. The idea is simple: Customers need to authenticate when they request access to APIs to interact with a business via a customer-facing application (like a mobile app or website). Authentication means that customers prove that they are who they claim to be. The means of authenticating vary. At the end of the authentication, a CIAM system can draw a pretty good picture of who the external user is. It describes the user in the form of attributes we call identity attributes. It's the responsibility of a CIAM system to authenticate the user and forward the corresponding identity attributes to APIs. APIs read the identity attributes and check — based on the values — whether or not they allow access.
CIAM Capabilities: What Should You Look For?
Every business is different and has different requirements. Therefore, a CIAM system must be very customizable so that an organization doesn't compromise security. Therefore, a CIAM system must, for example, support single sign-on as well as a dynamic authentication process with various authentication methods as a starting point. It must be possible to combine several authentication methods to support multi-factor authentication, have various strategies for different scenarios, and dynamically change the behavior based on the context.
The result of an authentication process is a set of identity attributes. As mentioned before, those attributes are the foundation for access controls. As every organization has its own rules and a unique approach to describing its customers, a CIAM system must allow for adapting the set of identity attributes to reflect the organization’s data model. It must further be possible to dynamically shape the identity attributes depending on the context, such as, the API itself and the calling application. In that way, organizations can ensure that APIs receive the data they need to make accurate, informed decisions.
Functional features are essential, but the long-term maintenance of the CIAM system is equally important. A SaaS CIAM may at first appear to be a tempting, convenient solution because an organization doesn't have to bother with any deployment-related concerns. It simply pays the provider to take care of that. However, because of their business models, SaaS providers typically cannot offer the same flexibility as you get when deploying your own CIAM system. What is more, SaaS providers are an attractive target for cyberattacks because of the potentially big impact of a successful breach. Therefore, building, hosting, and operating your own CIAM system may be the preferred option in the long run. If the CIAM system supports cloud-native paradigms, you can deploy a scalable, future-proof solution that fits into a modern software landscape.
Curity’s CIAM Solution
The Curity Identity Server comes with a set of built-in authentication methods and an extensive list of actions. Actions are steps in an authentication process allowing customized behavior and user journey orchestration. For example, you can dynamically enforce additional authentication methods, read, change, or modify identity attributes, link accounts, send emails, request user confirmation, and many more actions. If the provided actions are not enough, you can, with some basic technical skills, write custom logic and plug it into authentication processes. Built-in authentication methods range from basic username and password over federated logins using OpenID Connect or SAML to passwordless methods with Passkeys. You can both customize single sign-on and first login behaviors. If successful, an authentication results in attributes about the user. But that's not where security ends.
We believe the best way to communicate identity attributes with APIs is via a token called an access token using a protocol called OAuth. In the Curity Identity Server, we clearly separate authentication from authorization. Therefore, we introduced two separate configuration profiles in our product: the authentication service that allows you to configure your own authentication processes as explained above, and the token service that allows crafting the token and related identity attributes that APIs should receive.
The token service of the Curity Identity Server takes the results of the authentication process and crafts the access token. You can adapt the access token for each application that integrates with APIs. We recognize that an organization may have many sources for identity attributes. While some of the identity attributes in an access token come from the authentication process, the Curity Identity Server also allows for fetching additional attributes from various origins like an LDAP directory, a database such as Microsoft SQL Server, Oracle, DynamoDB, and more, including arbitrary RESTful APIs. As with actions, you can write custom logic for when the provided solutions do not meet your requirements.
Besides customers, applications, and APIs, a CIAM system should account for another group of clients: its administrators and operators. Just because a product is rich in features does not mean it has to be complicated to get and keep it running. The Curity Identity Server is a cloud-native CIAM with a user-friendly web UI and a DevOps dashboard for manual configurations, which caters to human users. Operating the Curity Identity Server is no different from operating APIs. The Curity Identity Server allows full control over when, where, and what to run. Organizations can, for example, use continuous integration and continuous delivery pipelines to deploy the Curity Identity Server on any platform at any stage in the development process. If you can run APIs, you can run the Curity Identity Server and do so in a cloud-native manner.
Tailored Security Using Standards
The great benefit of OAuth is that you can fit all the customizations into a standard protocol. This means despite customized authentication processes or proprietary identity attributes, APIs and applications only rely on well-established and open standards. Cloud-native paradigms allow for running the product using current best practices. There is no need to implement proprietary code to integrate with the Curity Identity Server. APIs and customer-facing applications can use standard security libraries for that purpose, and deployment processes can integrate the product using existing tools. Developers can focus on what’s important: implementing business logic, protecting access, and securing data — making your business work better with the Curity Identity Server.
