Introducing the Neo-Security Architecture

The Neo-Security Architecture is a modular and open-standard-based security architecture. It aims to secure, protect and assert legitimate access to APIs and services as well as to applications both on web and on mobile. A centralized system for managing Identities, Token issuance, Federation and so on is critical to building a secure and scalable API platform.

The primary goal of the Neo-Security Architecture is to provide a blue-print architecture that can be used to map new and existing systems against the functions needed to scale securely. It is not intended to be implemented as a whole but rather to be used as a road-map to be prepared when new needs arise.

The main design principle follows the Unix idiom of do one thing and do it well, or more formally: Separation of Concerns. Each subsystem within the architecture has a singular responsibility, which helps architects map a problem onto an architectural solution. This also provides the benefit of scaling over time, when new standards arise, old components can be integrated with new components, to provide a wider scope of functions.

A good example of this is the Federation Service which will be described more in detail further on. It services older federation standards such as SAML and WS-Federation, but when placed separately with only federation as its singular function, it can be used together with the Token Service allowing OAuth tokens to be issued to applications using federated identities.

The second principle is that the architecture is based on standards. Each function should use the appropriate standards available to integrate with edge applications or internally. This makes for easier replacement of components and helps asserting that security is maintained.

There are three main pillars of the Neo-Security Architecture:

• An Identity Management System
• An API Management System
• An Entitlement Management System

Each of these encapsulate a system function that is loosely coupled with the others. At the heart of the architecture is the Identity Management System, that is responsible for asserting identities to other systems using Security Tokens.

The Neo-Security Stack of Open Standards

The following is a non-exhaustive list of open standards used in the architecture. The purpose is not to lock down the architecture to a certain set of standard, but rather to provide the base plate to build upon.

Many of the standards listed are large sets of specifications, sometimes a complete standard is required but often only parts of the standard is needed to solve functional requirements.

The Identity Management System

An Identity Management System's (IMS) main responsibility is to handle identities within the system. This means it needs to be capable of directly authenticating users as an Identity Provider (IdP) or by using a Federated Identity via another IdP.

There is no distinction of the type of user in the system. The IMS should be able to authenticate directly or via federation both Customers, Employees and Partner users (or whatever type you may have). This by no means indicate that they will obtain the same type of access, but the process of establishing proof of identity is the same no matter what the user type.

Any resulting identity assertion is provided as a Security Token in the appropriate standard. For API access this is using OAuth Access Tokens, for Web Applications it is OpenID Connect ID Tokens and for federated service providers it can be using SAML tickets.

The resulting Security Tokens should contain enough claims so that the recipient can determine the scope of access for the particular request. From this perspective the IMS is delegating access from the user to the application on its behalf. This is a base principle in the OAuth specification.

Following the principle of separation of concern, the IMS is split into the following sub-systems.

The API Management System

Moving to an API-driven and/or microservice based architecture requires more systems to work together. The first step is to have an identity management system in place, as described above. This allows the APIs (Microservices) to pull the identity out from the APIs and manage it centrally.

There is no distinction of the type of user in the system. The IMS should be able to authenticate directly or via federation both Customers, Employees and Partner users (or whatever type you may have). This by no means indicate that they will obtain the same type of access, but the process of establishing proof of identity is the same no matter what the user type.

The API Management System (AMS) is the logical structure of an API deployment. Its purpose is to service data and functions via APIs and other types of services. It depends on the Identity Management System for all identity related operations which are pulled out from the API Management System and contained within the IMS. The AMS simply acts as the police and enforces access policies based on the identity information found in the tokens issued by the IMS.

There are three distinct functions of an AMS that when needed are represented in this architecture. Securing access to APIs, integration of APIs into services, and developer access to APIs.

Often organizations with greenfield deployments find themselves only needing the security mechanism of APIs. However the Neo-Security Architecture aims to help architects map their current landscape of products into distinct functions so it is meaningful to also map out the less common functions.

The Entitlement Management System

The Entitlement Management System (EMS) is the last pillar in the Neo-Security Architecture. It provides Attribute Based Access Control (ABAC) which is a more powerful entitlement mechanism than the traditional Role Based Access Control (RBAC). ABAC provides flexibility and preciseness by providing a policy framework where administrators can author security policies that are enforced throughout the entire architecture.

ABAC takes the following into account for an authorization decision:

• Attributes of the subject (user)
• The context in which the decision is being made
• The action that is being performed
• The resource that is requested

It then applies the configured policies to come to an allow or deny decision. The Entitlement Management System is responsible for managing and enforcing the policies as well as distributing these to each sub-system that needs enforcement.

The benefit of this approach is that authorization policies need not be known at design time of a system, but can be added and updated as the business requirements evolve.

To ensure authorized access to highly regulated and valuable data, fine-grained policies are usually created with attribute-based access control. Consequently, the API Security Service validates users with their current context, their client applications and their requested actions besides their roles.

Conclusion

The Neo-Security Architecture is designed as a blueprint for organizations that act as service platforms with growing needs in terms of both identity and security. It can serve as a road map to set the direction for new projects, but also as a guide to understand what functions are present in the organization's infrastructure already. Many times a function exists but is in the wrong place to operate to its full potential.

The Neo-Security Architecture is built on open standards that are accepted and adopted by the market. In the architecture, dedicated services are separated in respective modules and interact through APIs, which provides easy integration and future scalability as well as secure access to data.

Because each service is dedicated to its function and loosely coupled to the others, you can update one service independent of another service, making the system easier to manage and develop over time.

In the next section we'll go through each sub-system in more detail and the open standards used to implement them.

Published: 2020-04-08

Curity