Phase 2 – Application Integration Using Azure AD App Registration

In Phase 2, I extended my Azure Key Vault project by integrating it with a real application scenario for our Workday API integration effort. The objective was to enable secure, non-interactive access to secrets using an Azure AD App Registration and service principal authentication. This allows the application to authenticate using environment variables instead of developer credentials, ensuring a production-ready, least-privilege security model.

Overview

The Workday API Client requires programmatic access to credentials stored in Azure Key Vault (e.g., usernames, passwords, and API keys). To support this securely, I created a dedicated Azure AD App Registration named Workday API Client, generated a client secret, assigned Key Vault RBAC permissions, and validated end-to-end authentication using Azure CLI and the Azure SDK.

Steps Performed (GUI Workflow)

1. Created App Registration: “Workday API Client”

I created a new single-tenant App Registration in Azure Active Directory. This provides a unique application identity and isolates permissions from any existing Workday system integrations.

2. Generated a Client Secret

Under Certificates & Secrets, I generated a secure client secret for the application. The secret value is used to authenticate the application server and is treated with the same sensitivity as a password.

3. Collected Application Credentials

The following values were provided to the development team for use as environment variables:

• AZURE_TENANT_ID – Directory (tenant) ID
• AZURE_CLIENT_ID – Application (client) ID
• AZURE_CLIENT_SECRET – Client secret value

4. Assigned Key Vault RBAC Permissions

Using RBAC-only mode, I assigned the service principal the Key Vault Secrets User role. This grants read-only access to secrets while following least-privilege best practices.

5. Validated Authentication Using Azure CLI

I verified that the application could authenticate by logging in with:

az login --service-principal --username <client-id> --password <secret> --tenant <tenant-id>

Then I confirmed that the service principal could read secrets:

az keyvault secret list --vault-name <your-key-vault-name>

6. Delivered Variables to the Developer

I provided the required environment variables to the developer, who uses the Azure SDK’s ClientSecretCredential class to authenticate and retrieve secrets:

new ClientSecretCredential(tenantId, clientId, clientSecret);

Why This Matters

This phase demonstrates how Azure Key Vault integrates into real enterprise applications through secure identity, least-privilege RBAC, and service principal authentication. It shows the complete story—from vault deployment to application consumption—and highlights collaboration between infrastructure and development teams. This makes the Key Vault deployment truly production-ready.

Phase 2 – Terraform Code (App Registration + RBAC Integration)

############################################################
# Phase 2 – Application Integration (Workday API Client)
# Azure AD App Registration + Service Principal + RBAC
############################################################

# -------------------------------------------
# Data source: retrieve current tenant details
# -------------------------------------------
data "azurerm_client_config" "current" {}

# -------------------------------------------
# App Registration (Azure AD Application)
# -------------------------------------------
resource "azuread_application" "workday_api" {
  display_name = "Workday API Client"

  owners = [
    data.azurerm_client_config.current.object_id
  ]
}

# -------------------------------------------
# Service Principal for the Application
# -------------------------------------------
resource "azuread_service_principal" "workday_api" {
  client_id = azuread_application.workday_api.client_id
}

# -------------------------------------------
# Client Secret for Workday API Client
# -------------------------------------------
resource "azuread_application_password" "workday_api" {
  application_id     = azuread_application.workday_api.id
  display_name       = "workday-api-client-secret"
  end_date_relative  = "8760h"   # 1 year expiration
}

# -------------------------------------------
# Retrieve Key Vault resource (Phase 1 vault)
# -------------------------------------------
data "azurerm_key_vault" "workday_vault" {
  name                = "kv-workday-appsecrets"
  resource_group_name = "rg-workday"
}

# -------------------------------------------
# Assign RBAC: Key Vault Secrets User
# Allows read-only access to secrets
# -------------------------------------------
resource "azurerm_role_assignment" "kv_spn_secrets_user" {
  scope                = data.azurerm_key_vault.workday_vault.id
  role_definition_name = "Key Vault Secrets User"
  principal_id         = azuread_service_principal.workday_api.id
}

############################################################
# Outputs for application integration
############################################################

output "workday_api_client_id" {
  value = azuread_application.workday_api.client_id
}

output "workday_api_tenant_id" {
  value = data.azurerm_client_config.current.tenant_id
}

output "workday_api_client_secret" {
  value     = azuread_application_password.workday_api.value
  sensitive = true
}