# Unified Protection for SaaS APIs > Octelium documentation. Canonical page: . ## Overview Octelium is a unified zero trust architecture. It can seamlessly provide an effortless zero trust, identity-based, application-layer (L7) aware secretless access (read more about secretless access [here](https://octelium.com/docs/octelium/latest/management/core/service/secretless.md)), via both the private client-based access over WireGuard/QUIC-based tunnels as well as the clientless (i.e. "BeyondCorp") access, to all your SaaS APIs, including REST and gRPC APIs, for all your *Users*, both humans and workloads, via a unified identity management at scale. These [CASB](https://en.wikipedia.org/wiki/Cloud_access_security_broker)-like capabilities can provide multiple benefits especially at scale: - All your *Users*, both humans and workloads, can now have a unified identity management to all your *APIs* using the same credentials (e.g. SSO identity providers for humans (read more [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#web-identity-providers)) and OAuth2 client credentials and standard bearer access tokens for workloads (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#oauth2-client-credentials))). - Unified identity-based, application-layer (L7) aware, context-aware ABAC-based access control via policy-as-code (read in detail about *Policies* and access control [here](https://octelium.com/docs/octelium/latest/management/core/policy.md)) where you can control access way beyond what the SaaS API providers themselves can offer. - Unified L7 aware visibility and logging for access to all of your APIs (read more [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md)). ## A Simple Example Here is a simple example where you can have an API *Service* that's protected by a bearer access token. This *Service* is publicly exposed (read more about the public clientless BeyondCorp mode [here](https://octelium.com/docs/octelium/latest/management/core/service/clientless.md)) and can be accessed, for example, by workloads that can be written in any programming language via OAuth2 client credential flows (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#oauth2-client-credentials)) or even directly by directly issued standard bearer access tokens (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#access-tokens)): ```yaml kind: Service metadata: name: my-api spec: mode: HTTP isPublic: true dynamicConfig: configs: - name: v1 upstream: url: https://api.example.com http: auth: bearer: fromSecret: example-access-token ``` > **Note:** > > In addition to providing secretless access to upstreams protected by standard bearer access tokens (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#bearer-authentication)), Octelium additionally supports basic authentication (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#basic-authentication)), OAuth2 client credential flows (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#oauth2-client-credentials)) as well as custom headers (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#authentication-via-a-custom-header)) You can now apply the creation of the *Service* as follows (read more [here](https://octelium.com/docs/octelium/latest/management/core/overview.md)): ```bash octeliumctl apply /PATH/TO/SERVICE.YAML ``` ## Dynamic Configuration Octelium also allows you to dynamically route to an upstream based on the identity and the access context via policy-as-code. Here is an example where you have 2 access tokens corresponding to 2 different accounts/tenants and where you can choose one of them depending on the *Group* to which the *User* belongs: ```yaml kind: Service metadata: name: my-api spec: mode: HTTP isPublic: true dynamicConfig: configs: - name: v1 upstream: url: https://api.example.com http: auth: bearer: fromSecret: account-1-token - name: v2 upstream: url: https://api.example.com http: auth: bearer: fromSecret: account-2-token rules: - condition: match: '"prod" in ctx.user.spec.groups' configName: v1 - condition: match: '"dev" in ctx.user.spec.groups' configName: v2 ``` You can also, for example, have a unified endpoint for your API and route to different upstreams (e.g. multiple versions of the same API) depending on the request's path. Here is an example: ```yaml kind: Service metadata: name: my-api spec: mode: HTTP isPublic: true dynamicConfig: configs: - name: v1 upstream: url: https://v1.api.example.com http: auth: bearer: fromSecret: access-token path: removePrefix: /v1 - name: v2 upstream: url: https://v2.api.example.com http: auth: bearer: fromSecret: access-token path: removePrefix: /v2 rules: - condition: match: 'ctx.request.http.path.startsWith("/v1")' configName: v1 - condition: match: 'ctx.request.http.path.startsWith("/v2")' configName: v2 ``` ## Access Control Octelium's application-layer (L7) awareness seamlessly enables you to control access using CEL and Open Policy Agent (read more [here](https://octelium.com/docs/octelium/latest/management/core/policy.md)) based on HTTP request paths, methods and the JSON body of the requests. For example, a REST API whose JSON body has the following structure: ```json { "id": "abc123", "name": "user-2", "data": { "books": ["book-1", "book-2"] }, "isActive": true, } ``` Access control of such API can be as follows: ```yaml kind: Service metadata: name: my-api spec: mode: HTTP isPublic: true config: upstream: url: https://api.example.com http: enableRequestBuffering: true body: mode: JSON maxRequestSize: 100000 authorization: inlinePolicies: - spec: rules: - effect: ALLOW condition: all: of: - match: ctx.request.http.method in ["PUT", "POST"] - match: ctx.request.http.bodyMap.isActive - match: ctx.request.http.bodyMap.name.startsWith("user") - match: '"book-1" in ctx.request.http.bodyMap.data.books' ``` ## Visibility Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#visibility)). You can read more about visibility [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md) This was a very short guide to show you how to use Octelium to deploy, scale, route and provide dynamic zero trust secure access to your workloads. Here are a few more related features that you might be interested in: - Routing not just by request paths, but also by header keys and values, request body content including JSON (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#json-request-body)). - Request/response header manipulation (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#header-manipulation)). - Cross-Origin Resource Sharing (CORS) (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#cross-origin-resource-sharing-cors)). - gRPC mode (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#grpc)). - Secretless access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#secretless-access)). - Exposing the API publicly for anonymous access (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/anonymous-access.md)). - OpenTelemetry-ready, application-layer L7 aware auditing and visibility (read more [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md)).