Abbey Docs
  • 👋Welcome
  • Getting Started
    • Quickstart
    • Step-by-Step Tutorials
      • AWS: Managing Access to Identity Center Groups
      • AWS: Managing Access to Identity Center Permission Sets
      • AWS: Managing Access to IAM Groups
      • Azure AD: Managing Access to Groups
      • Confluent: Managing Access to Kafka ACLs
      • Databricks: Managing Access to Managed Tables in Unity Catalog
      • Databricks: Managing Access to Groups
      • GitHub: Managing Access to Teams
      • Google Cloud: Managing Access to Groups
      • Google Workspace: Managing Access to Google Groups
      • Kafka: Managing Access to ACLs
      • Okta: Managing Access to Groups
      • Postgres: Managing Access to Roles
      • Snowflake: Managing Access to Tables
      • Tabular: Managing Access to Apache Iceberg Roles
      • Tailscale: Managing Access to ACLs
      • Vault: Managing Access to Groups and Policies
      • Integrating Abbey with Terraform Cloud
      • Using Abbey with Atlantis
      • Using Abbey with Spacelift
    • Starter Kits
  • How Abbey Works
    • How Abbey Works
    • Key Concepts
  • Build a Grant Kit
    • Get a Starter Kit
    • Connect a Repo
    • Create a Grant Kit
    • Link Identities
    • Write Access Policies
    • Deploy Your Grant Kit
    • Request Access
    • Approve or Deny Access Requests
  • Use Cases
    • Time-Based Access
      • Expire After a Duration
      • Expire At a Specific Time
    • Approval Workflows
      • Using a Single Approval Step
      • Using Multiple Approval Steps
      • Conditionally Skip Approval Steps
  • Admin
    • User Roles
    • Sign-in and MFA
      • Sign-in Methods
      • Multifactor Authentication (MFA)
      • Enabling Single Sign-On
    • Sources
      • PagerDuty
      • Directory Sync
    • End User Notifications
    • Manage API Tokens
  • Reference
    • Grant Kits
      • Workflows
      • Policies
      • Outputs
    • Referencing Users and Groups
    • Linking Application Identities into Abbey
      • Why do I need to link application identities?
      • How do I Link Application Identities?
      • Supported Application Identity Types and Schemas
      • Application Data Object
    • Access Policies
      • Types of Access Policies
      • Policy Bundles
      • Inline Policies
      • Helper Functions
      • Policy Examples
    • Terms of Service
    • FAQ
      • Troubleshooting
  • Resources
    • Abbey Labs
    • Terraform Registry
    • GitHub
    • System Status
    • Privacy Policy
    • Logo
Powered by GitBook
On this page
  • Before you start
  • Step 1: Identify which application you are linking data for
  • Step 2: Make an API request to our Users API to link identity data
  • Step 3: Use your Imported Identity Data in a Grant Kit
  1. Reference
  2. Linking Application Identities into Abbey

How do I Link Application Identities?

PreviousWhy do I need to link application identities?NextSupported Application Identity Types and Schemas

Last updated 1 year ago

Before you start

Make sure you have:

  • An

  • An

  • The User ID of the Abbey user you want to link identity data for

Step 1: Identify which application you are linking data for

Abbey has first-class support for linking data for certain applications. Other applications can also have application identity data linked, but Abbey enforces a certain structure on first-class applications to make sure that you have all the identity data you need to successfully use Abbey.

To find out what the structure of your app data payload should be, take a look at Supported Application Identity Types and Schemas

In this page we'll be linking Github application identity data.

Step 2: Make an API request to our Users API to link identity data

We'll be making a request to the to link data an external identity to an Abbey identity.

curl \
  -H "Authorization: Bearer $ABBEY_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -X POST "https://api.abbey.io/v1/users/<userID>/apps" \
  -d '{"type": "<app type>", "data": { ... app data ... }}'

As an example, we wish to link this user's Github username:

curl \
  -H "Authorization: Bearer $ABBEY_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -X POST "https://api.abbey.io/v1/users/user/user_2U4vhAMp6hByuOVA7EGwEwmI5NK/apps" \
  -d '{"type": "github", "data": {"username": "Alice"}}'

Let's take a closer look at the JSON payload we're POSTing:

{"type": "github", "data": {"username": "Alice"}}

Here we're specifying that the type of application we're linking data for is github and that we have a data payload which contains a username key whose value is Alice. The structure of the data payload differs per application, and is unspecified for app types not supported. Look at Supported Application Identity Types and Schemas to see a list of custom applications and the structure of each application type.

Step 3: Use your Imported Identity Data in a Grant Kit

When creating a grant kit, in your output block you can make references to imported application data and Abbey will fill in these references with the data you imported in the above step. For example:

{{ .user.github.username }}

will resolve to a Github username linked through the API.

Here's an example:

Let's create the output block of a grant kit which uses the application identity data we just imported to grant access to a resource:

  output = {
    # Replace with your own path pointing to where you want your access changes to manifest.
    # Path is an RFC 3986 URI, such as `github://{organization}/{repo}/path/to/file.tf`.
    location = "github://organization/repo/access.tf"
    append = <<-EOT
      resource "github_team_membership" "gh_mem_{{ .user.github.username }}" {
        team_id = github_team.test_team.id
        username = "{{ .user.github.username }}"
        role = "member"
      }
    EOT
  }

Note that the username block will be templated by the Github username we linked in Step 2.

That's it! Now you've imported your application identity information into Abbey.

Abbey account
Users API
Abbey API Token