Identity and Access Management Primer
Intro
This article provides an entry-level explanation of Identity and Access Management (IAM). We present basic IAM concepts and give practical advice on implementing IAM for small businesses, startups, or other organizations with a shoestring budget.
Startups and Digital Solutions
Startup companies often begin with an original business idea then deliver many software applications and APIs. These apps use sensitive data that is not always owned by the startup company. Thus, they must secure access to the data.
Security Challenges
Small companies often struggle to deliver a good security implementation that addresses the OWASP Top 10 API Security Risks. With limited resources, it's challenging to estimate costs and organize team members while addressing the following requirements:
- Avoiding data leaks and cyber attacks
- Meeting compliance and regulatory requirements
- Integrating security features in a simple and scalable manner
These are architectural requirements that need an architectural solution. Your security should only need designing once and should then be easy to grow.
Security Standards
Security standards for modern apps are based on the OAuth 2.0 family of technologies, which provide the best capabilities. The technology provides great connectivity with other systems and can be integrated into most stacks:
OAuth provides a mechanism to control which parties can access which information. Below, we will describe the recommended architecture in terms of data. When done correctly, this provides a technically simple solution.
Security Architecture
Components
At a minimum, we recommend that startups use the following components in their security architecture. Your apps are described as 'clients' in OAuth terminology, and they interact securely with APIs.
These apps outsource the difficult security work to two types of components, both of which are implemented by security experts:
- The Identity Server provides an implementation of OAuth standards, dealing with security details, including authentication and token issuance.
- Certified Security Libraries trigger authentication and verify received tokens.
Clients
Within apps, users authenticate at the Identity Server to obtain an access token. There are many variations or 'flows' for this process, each with its own security nuances. OAuth flows are initiated when security libraries call Identity Server endpoints using standards-based messages.
After authentication, the Identity Server issues tokens that control which data can be accessed and which operations can be performed on that data. This 'delegation' can be automatic or can involve approval by the end-user.
Access Tokens
Next, access tokens are used as a message credential when calling APIs. The following approach is the most secure way to manage them:
- Internet clients receive short-lived access tokens in a lightweight opaque reference token format.
- The reference token is a pointer to the security state stored in the Identity Server, which will be forwarded to APIs later on.
- APIs receive digitally signed JSON Web Tokens (JWTs) containing the security state, then use this data to authorize access to resources.
Reverse Proxy
Since the Identity Server connects to sensitive data sources, it should not be directly exposed to the Internet. Instead, security experts recommend hosting the server behind a simple reverse proxy, such as an NGINX Ingress or a Cloud API Gateway.
The reverse proxy's main architectural role is to swap incoming reference tokens for JSON Web Tokens to retrieve the security state from the Identity Server and forward it to APIs.
This requires the below introspection capability, and the proxy may also perform some basic token validation. It is common for the proxy to then securely cache results for future requests with the same access token.
These days, a reverse proxy usually already exists in your API infrastructure. So, the above behavior does not require any new systems. Curity provides tutorials on setting up reverse proxy introspection for various providers:
API Token Validation
After introspection, the reverse proxy forwards the incoming request to the API, updating the HTTP Authorization header with the JWT. The API must then cryptographically verify the token's digital signature on every request before using the token data.
APIs must receive security state in a digitally verifiable manner, as opposed to unverifiable plain data that could be exploited. The API must also follow JWT Best Practices to avoid potential vulnerabilities.
If digital verification succeeds, the API trusts the scopes and claims in the token. These are then processed into a Claims Principal object in memory. The API then uses this object to check if the caller is allowed to perform the requested operation on the requested resources.
API Authorization
The two types of data that APIs use for authorization are 'Scopes' and 'Claims', the first of which is a high-level privilege and the second of which contains more fine-grained data. The API can, if required, combine the two types of data to enforce access control, as in the below example:
| Data Type | Value | Meaning |
|---|---|---|
| Scope | orders_read | The API is allowed to return order information |
| Claim | transaction_data | The API can return items purchased and their prices |
| Claim | user_data | The API can return personal user information contained in orders |
public List<Order> getOrders() {
// Verify that the caller can get this type of data
if (!this.claimsPrincipal.hasScope("orders_read")) {
throw forbiddenError("The caller has insufficient scope");
}
// Return only data the caller is allowed to see
return this.repository.getOrders(
this.claimsPrincipal.hasClaim("transaction_data"),
this.claimsPrincipal.hasClaim("user_data");
}Within some business domains, APIs must meet complex rules. Therefore, the Identity Server must be flexible enough to issue the scopes and claims needed.
Microservices Authorization
The above design pattern requires only simple code in the APIs, and scales well to a microservices architecture, where access tokens are forwarded to downstream services. In some cases, it can be useful to generate a new token for the downstream service, with updated/reduced privileges:
Identity Server
The Identity Server is the central security component, dealing with many core areas:
- Handling OAuth 2.0 and OpenID Connect messages for many flows.
- Providing a secure and friendly login experience for end-users.
- Capturing user consent when applicable.
- Storing secrets such as passwords and certificates.
- Issuing confidential tokens to clients, and storing scopes and claims for APIs.
- Auditing security-related events and the privileges granted.
By auditing scopes and claims, the Identity Server provides a secure record of who has accessed which data over time, in line with compliance requirements.
Curity
At Curity, we specialize in security, providing both a mature Identity Server and detailed architectural advice. This gives our customers the tools they need to secure their systems correctly.
Curity Identity Server
The Curity Identity Server has comprehensive support for many standards. The most important of which are OAuth 2.0 and OpenID Connect. We build layered solutions with a great separation of concerns so that the system is easy to extend in the crucial places.
Free Community Edition
Curity Identity Server has a free community edition with Extensive OAuth Features, to enable the above security architecture. See the FAQs Page for further details.API Features
The Curity Identity Server supports rich token issuing behavior, with many types of scopes, runtime claims, and compound tokens. These are fully customizable per client, via data source lookup or custom code that can reach out to remote endpoints.
The business benefit is that companies will not run into blocking issues when business rules become complex, or when APIs need to call each other. Each API just needs to deal with a set of claims and scopes for its business area, which should be easy to reason out.
In addition, we provide advice and tutorials on the most effective design patterns for managing API security in depth:
Authentication Features
By following our code samples, you can quickly implement an Authentication Flow within your clients. Then, your app will achieve Single Sign-On across domains. Without code changes, you can then integrate with many third-party identity providers.
You can configure authentication workflows based on multiple factors and runtime conditions. The Login User Experience is fully customizable per client, including CSS branding, Javascript logic, and localization.
The Hypermedia Authentication API can be used for further control over Login UX and to avoid redirecting the user from their current app location. You can do this without much code by integrating the HAAPI SDK.
Deployment and Upgrades
The Curity Identity Server can be hosted anywhere, though we recommend deploying to a Kubernetes Cluster so that you can use its built-in cloud-native reliability features:
There is advanced support for many types of deployment, including multi-tenancy for companies who want to provide separate OAuth endpoints per business partner.
By following Kubernetes best practice, customers can achieve high availability and zero downtime upgrades via simple scripting. The system's configuration can also quickly be rolled back to any earlier state.
Administration
Security settings are stored in our Configuration Management System, and customers usually get started with the Admin UI, which interacts with our Configuration API. Administrator changes to increase security or revoke access come into effect immediately. We also provide SCIM 2.0 User Management endpoints for managing users in bulk.
Getting Started
To get secured apps running in your environments, start with the below link. This will enable you to run Curity code samples against your own instance of the Curity Identity Server. You can then apply the same coding techniques to your own systems to implement your security architecture.
Conclusion
Here are the key components you need to implement a secure architecture correctly and to outsource the difficult security work:
- An Identity Server that supports customizing scopes, claims, and authentication
- A Reverse Proxy located in front of APIs and the Identity Server
- APIs that authorize requests using digitally verifiable claims
- Certified libraries that implement lower-level security for APIs and Clients
The Curity Identity Server and our technical resources are an excellent fit for software companies, enabling secure end-to-end solutions. By addressing security concerns, Curity enables software companies to spend more time on core business features.