XACML Architecture

Topcon’s CIAM architecture follows the XACML (eXtensible Access Control Markup Language) model, which is commonly used by large SaaS platforms like Amazon AWS. This architecture allows for flexible domain modeling and collects necessary data for security decisions from various sources, including our master data, data lake, ERP, CRM, and application systems. 

In this section, we will briefly outline the XACML architecture and how it is implemented at Topcon, helping readers understand the CIAM service and trust its security, flexibility, and scalability. The XACML model ensures that CIAM can grow with the company’s evolving product and business needs.

XACML defines five main roles (PAP, PIP, PRP, PEP, and PDP). While XACML can be prescriptive about these roles, many systems—including Topcon’s—use them in a descriptive manner without strict adherence to XACML’s XML policy format. Topcon leverages XACML as a Policy-Based Access Control (PBAC) architecture, which offers more flexibility and is easier to govern compared to Role-Based Access Control (RBAC).

XACML Roles

Below is an overview of the XACML roles and their implementation in Topcon’s CIAM service. For those already familiar with XACML, you can skip ahead to the next section to see how these elements come together for Topcon’s SaaS services.

Policy Administration Point (PAP)

The PAP is the single point in the system where policies are administered.

Topcon implements the PAP as a REST API. OpenAPI documentation for the PAP can be found here.

Topcon has created its own REST API for the PAP because:

• It decouples our back-end vendor systems from our homegrown SaaS products, allowing us to swap out back-end vendor systems if needed.
• It simplifies or streamlines the REST API with entities and workflows specific to Topcon’s business, such as managing our direct and indirect customer relationships.

The PAP API includes endpoints for administering Business Partners  (a direct or indirect customer), Identities  (a person), Users  and their profiles (roles), and Groups , among others. These terms will be explained later. However, most Topcon web services won’t need to interact directly with this part of the PAP API, as customer management of these entities happens centrally through the My Topcon self-service dashboard.

The PAP API also includes endpoints for administering Permissions to access Resources  (e.g., a construction site or a design file for a construction site). Topcon web services that use CIAM may need to interact with this part of the PAP API.

Topcon’s CIAM uses a Policy-Based Access Control (PBAC) system. Service-specific policies are administered through the PAP REST API. We use Open Policy Agent (OPA) and REGO for policy code, which will be discussed [later in this document](#writing-opa-rego-policies-for-your-topcon-web-service).

Policy Decision Point (PDP)

The PDP is a highly available, low-latency service that makes authorization decisions for Topcon web services.

Authorization decisions generally follow this form:

• Can the token subject  perform action X  on resource Y  in environment Z ?

While this is the typical structure, PBAC allows flexibility in how authorization decisions are made by the use of extensible policies. This enables product managers and developers to adapt the system to fit new products.  Policies offer flexibility such as enabling support for X509 Client Authenticated TLS, OAuth 2.0 access tokens, and various other protocols.

Topcon CIAM uses Open Policy Agent (OPA) as the PDP, discussed further below. OPA's policy language REGO is well-established and well-documented.

Topcon web service developers can use IT-provisioned PDP services or provision their own PDP if they need full control over factors such as throughput and latency. Collaborate with us to determine the best approach for your specific needs.

Policy Enforcement Point (PEP)

The PEP can be thought of as a security guard at the front door, checking who is allowed to enter.

The PEP’s role is to enforce a service request, determining whether the request is accepted or denied based on inputs like:

• The request URL
• The authorization token
• Any other necessary inputs

Continuing with the analogy, the security guard (PEP) needs to check with a system to determine if you’re allowed entry. That system is the PDP mentioned above. The PEP enforces the request by consulting the PDP. This decoupling between the PEP and PDP gives us flexibility in how we secure our web services. Below is a list of sone IT-supported PEP technologies:

• Ping Access
• AWS API Gateway integration
• Nginx integration
• Traefik integration
• Envoy integration
• Integrated within web service source code (library) for fine-grained request enforcement

As shown, the PEP is often implemented as an integration with an HTTP proxy or gateway. The proxy or gateway gathers information about the incoming request (e.g., URL, tokens) and passes it to the PDP for authorization. If the PDP denies the request, the proxy or gateway responds with a 401 status. However, this isn’t limited to HTTP. Any protocol that provides the necessary information can serve as a PEP that accesses our PDP agents.

As with the PDP, developers can use IT-provisioned PEP services or provision a PEP themselves if they need control over throughput and latency. Work with us to determine the best approach for your needs.

Policy Retrieval Point (PRP)

The PRP is where the PDP accesses the policy store. For scalability, the policy store is globally replicated. Topcon uses a globally replicated AWS DynamoDB as the backend for the PRP, ensuring scalability and redundancy—both critical for a core service like CIAM.

Policy Information Point (PIP)

A PIP decouples the data used in policy decisions, allowing it to come from external data sources outside of CIAM. For example, information about a device and its entitlements (such as what software it can run) might be integrated with CIAM as a Policy Information Point, accessing other systems in the background.

Topcon’s CIAM expects a PIP to be implemented as a REST API, allowing policy evaluation to query the PIP via REST requests.

The use of PIPs provides tremendous flexibility. It allows a Topcon web service to access any data store necessary to:

• Resolve IDs in URLs
• Resolve X509 CN fields to obtain device ID information
• Access information such as time of day, end-user machinery operator tickets, etc.

Putting it all together

The following diagram shows how the XACML roles come together in Topcon’s CIAM implementation.

What’s important to note here?

• Data used for policy decisions comes from two main sources: the policy domain model and Policy Information Points (PIPs). The policy domain model contains records of our business partners (OEMs, dealers, technical partners, end-customers), their employees, and agreements between these partners (e.g., Dealer A may support Customer B). This is discussed further in the [CIAM Domain Model](#ciam-domain-model) section below. PIPs, on the other hand, can be other systems within Topcon Infrastructure Services (such as a data lake) or from Topcon web services.
• Data flows in one direction—from the policy domain model through a functional mapping to the policy documents (in orange). These policy documents are decoupled from our policy domain model, allowing their schema to change independently and providing isolation from domain model changes. The PDP only reads these policy documents, enabling the orange (and green) sections to be globally replicated, which supports high availability and scalability.
• Topcon web services integrate at just a few key points: They retrieve a JWT token from the OAuth 2.0 Authorization Server (Ping Federate) and integrate with a PDP and PEP. These points are further discussed in the [CIAM for Developers](#ciam-for-developers) section below.  This is detailed by the large light green circle.
• This architecture is robust, secure, extensible, and scalable.