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
  • Overview
  • What Does it Mean to Link Identities?
  • When do I need to link Identities?
  • Which Applications does Abbey Linking with?
  1. Build a Grant Kit

Link Identities

PreviousCreate a Grant KitNextWrite Access Policies

Last updated 1 year ago

Overview

For a user to request access to a resource in another application, sometimes an identity in this external application is required. For example, if you have a resource which controls access for your Github User to a Github Team, then Abbey needs a mechanism to link a user's central account (often their Abbey account, which is often email) to an identifier in the downstream system.

For example:

  • Github has

  • AWS Identity Center has an

  • etc

We call this process linking.

What Does it Mean to Link Identities?

Linking an application identity is the process by which we associate the application's identity with your Abbey user. Once identity data has been linked for an external application, Abbey can use this identity data in its grant kits.

Below is an example of linking Github data into Abbey:

curl -X POST -d '{"type": "github", "data": {"username": "Alice"}}'

This links the Abbey user with Github, and lets Abbey know that the Github username for the Abbey user is "Alice". Now we can refer to this in a grant kit output block using the user object as follows:

output = {
    location = "..."
    append = <<-EOT
      resource "github_team_membership" "eng_team_membership" {
        team_id = github_team.eng_team.id
        username = {{ .user.github.username }}
        role = "member"
      }
    EOT
}

Now when this grant kit is applied, Alice will become part of the eng_team Github team. Note that Github specific application information is found in user.github and a field named username contains the Github username you linked earlier.

When do I need to link Identities?

By default Abbey provides access to your Abbey email in the user object as user.email for use in Grant Kits and policies. If the resource you're controlling access to only requires the email you signed up for Abbey with, then you don't need to link any application identity data!

Which Applications does Abbey Linking with?

Abbey supports linking data from any external application! Abbey does however have first-class support for a set of applications which require linking application data in a specific way.

For more info about linking from first-class supported Abbey applications or just more information about Linking Application Identity Data in general, read Linking Application Identities into Abbey.

usernames
Identity Center ID