Access And Authentication
This page describes how users and clients enter the Alpha Looms platform and how authentication is enforced across the edge and gateway layers shown in the architecture diagram.
Primary Actors
The diagram shows the main frontend access channels.
Admin WebBorrower WebSales WebSales App
These entry points represent separate application channels that converge on the same platform edge before being routed to the correct backend capability.
Public Access Path
The public access path in the diagram is:
- web or app entry from
Admin Web,Borrower Web,Sales Web, orSales App - DNS resolution through
DNS - traffic reaching the
Public Loadbalancer - routing by the
NGINX Ingress Controller - forwarding to the appropriate gateway or service
This path is the main route for browser-facing traffic and public integration entry.
Gateway Layer
The ingress layer routes to three gateway components:
Admin API GatewayBorrower API GatewayOpenAPI API Gateway
This separation makes it easier to keep admin, borrower, and public API traffic concerns distinct while still running them within the same AKS environment.
Typical responsibilities at this layer include:
- route partitioning
- authentication enforcement
- token forwarding or validation coordination
- access control before traffic reaches downstream services
Keycloak And Token Validation
Keycloak is shown as the central identity and token-validation component.
The diagram indicates token validation relationships between Keycloak and the gateway layer. In practice, this means authenticated traffic is checked before requests are allowed to continue into service routes.
From an integration perspective, this means you should expect:
- token-based access control for protected routes
- role or client-specific access patterns depending on gateway and downstream service configuration
- different access scopes or audiences for admin, borrower, sales, and public API flows
Internal Service Communication
Not every interaction is intended for public access.
Inside AKS, services communicate with each other through Kubernetes DNS and service discovery.
Use this distinction when deciding whether an integration should be:
- internet-reachable through the public edge
- internal service-to-service communication inside the cluster
Related Platform Services
The access layer also connects with nearby platform components shown in the diagram, including:
FormioN8NSupabaseSuperset
Some of these may be reached through the same ingress boundary, but they serve different purposes from the API gateways and should be treated as separate platform capabilities.
Integration Guidance
When planning an integration:
- Identify whether the consumer is an admin flow, borrower flow, sales flow, public API consumer, or internal system.
- Confirm whether the route belongs behind the public edge or is intended only for internal service-to-service communication.
- Confirm the token model and identity provider expectations around
Keycloak. - Use the API Catalog for contract-level details.