Skip to main content
Version: 26.2

Quick start

This guide walks you through the core workflow for defining and managing Attribute-Based Access Control (ABAC) policies in Authorization Hub. It covers the essential steps, from defining attributes to creating a deployable authorization domain.

Your starting point - Projects​

After logging in, you land on the Projects page that lists every project you belong to.

tip

Projects are isolated collaboration spaces. Each team works within its own project, so your configurations never interfere with another team's work.

Click a project name to open it. You land on the Dashboard, which has shortcuts to every area of the project (attributes, policies, attribute connectors, domains, and policy insights), your team's latest activity, and the people who have access to the project. The header shows the project name and your role in it.

To complete the steps below, you need the Project editor or Project admin role. Project viewers have read-only access, and domain viewers only see the Dashboard and Domains pages.

My workspace​

Changes you make to attributes, policies, attribute connectors, and cache configuration don't affect the project right away. They're staged in My workspace, which is private to you until you save it to the project. The header shows how many changes are pending, and the sidebar shows a counter next to each page that has pending changes. See My workspace for details.

The five-step workflow​

The four steps below build on each other and each step produces an output that the next step depends on. Work through them in order.

Step 1 - Define attributes in the Dictionary

Open the Dictionary page and define the attributes your policies will use. Attributes are the building blocks of ABAC: they describe the subject (user), action, resource, and context of every access request. Add attributes manually, or import them from a file.

You can also define attributes through the API. Read Dictionary and the API overview for details.

Step 2 - Author policies

Open the Policies page and write policies in the ALFA language. Policies define the rules that grant or deny access based on the attributes you defined in step 1. Write ALFA in the Code view, or switch to the Split or Graphical view to build and edit policies visually.

The attribute-dictionary.alfa file in the ALFA resources panel is a read-only copy of the Dictionary, including attribute changes in your workspace. The file is refreshed when you open the Policies page. If attributes are added or changed while the editor is open, reopen the Policies page to see them.

Step 3 - Configure attribute connectors

Policies reference attributes by name, but the Policy Decision Point (PDP) must know where to fetch the actual values. Attribute connectors answer that question. Open the Attribute connectors page and configure attribute connectors for any attributes whose values must come from external systems at runtime. For example, a user's department from an LDAP directory, or a resource's classification from a database. You can also import attribute connectors from a file.

Step 4 - Save your changes to the project

Open My workspace to review your changes, compare policy changes, and discard anything you don't want to keep. When you're ready, save your changes to the project. All changes are applied as one changeset: they all land together, or none do. If someone changed the same items since you started, you're asked to resolve the conflicts before saving.

warning

Domains only use changes that have been saved to the project. Changes that are still in your workspace aren't included.

Step 5 - Compose a domain

Open the Domains page and click Add domain. Give the domain a name, select the policy entry point (the root policy that the PDP evaluates), and optionally select the attribute connectors to include. Authorization Hub automatically includes the attributes your policies use. The PDP fetches this domain configuration and uses it to evaluate access requests.

A domain lets you use different configurations for different purposes. For example:

DomainPurpose
app1-testTest environment for Application 1
app1-prodProduction environment for Application 1
app2-prodProduction environment for Application 2

Each domain specifies its own policy entry point and attribute connectors, so the same underlying policies can behave differently per environment.

note

Updating a domain brings in the latest policy and attribute connector changes saved to the project, including changes made by other users. You can roll a domain back to a previous version if needed.