Service principals for applications in Azure - Step-by-Step Execution

Process Flow - Service principals for applications

Create Application Registration

↓

Generate Service Principal

↓

Assign Roles/Permissions

↓

Use Service Principal for Auth

↓

Access Azure Resources

↓

Done

This flow shows how an application gets a service principal, which is like its identity, then gets permissions to access Azure resources.

Execution Sample

Azure

az ad sp create-for-rbac --name MyAppSP --role Contributor --scopes /subscriptions/12345

This command creates a service principal named MyAppSP with Contributor role on a subscription.

Process Table

Step	Action	Input/Command	Result	Notes
1	Create Application Registration	az ad app create --display-name MyApp	App registered with appId	AppId is unique app identity
2	Create Service Principal	az ad sp create --id <appId>	Service principal created	SP links to appId
3	Assign Role	az role assignment create --assignee <spId> --role Contributor --scope /subscriptions/12345	Role assigned	SP can access resources
4	Use SP Credentials	Use clientId and secret to auth	Token received	Token used to call Azure APIs
5	Access Resources	Call Azure API with token	Access granted	SP acts as app identity
6	End		Process complete	Service principal ready for app use

💡 After step 5, the service principal can authenticate and access resources as assigned.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
appId	None	Generated appId	Same appId	Same appId	Same appId	Same appId
spId	None	None	Generated spId	Same spId	Same spId	Same spId
roleAssignment	None	None	None	Contributor role assigned	Contributor role assigned	Contributor role assigned
authToken	None	None	None	None	Token received	Token valid for API calls

Key Moments - 3 Insights

Why do we need both an application registration and a service principal?

The application registration defines the app's identity globally, while the service principal is the local identity in a tenant used to assign permissions. See execution_table rows 1 and 2.

What happens if we skip assigning a role to the service principal?

Without a role assignment (row 3), the service principal cannot access Azure resources even if it exists.

How does the service principal authenticate to Azure?

It uses its clientId and secret or certificate to get an auth token (row 4), which is then used to access resources.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the service principal created?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Action' column for 'Create Service Principal' in execution_table.

According to variable_tracker, when does the authToken variable get a value?

A After Step 2

B After Step 4

C After Step 3

D After Step 5

💡 Hint

Look at the 'authToken' row and see when it changes from None.

If the role assignment is missing, what will happen when the service principal tries to access resources?

A Access will be denied

B Access will be granted

C Authentication will fail

D Service principal will be deleted

💡 Hint

Refer to key_moments about role assignment importance and execution_table row 3.

Concept Snapshot

Service principals are identities for apps in Azure.
Create an app registration first.
Create a service principal linked to the app.
Assign roles to the service principal.
Use its credentials to authenticate and access resources.
This enables secure app access without user accounts.

Full Transcript

Service principals are like user accounts but for applications. First, you register your application in Azure Active Directory to get an app ID. Then, you create a service principal which acts as the app's identity in your tenant. Next, you assign roles to this service principal to give it permissions to Azure resources. The app uses the service principal's credentials to get an authentication token. This token lets the app access Azure resources securely. Without role assignments, the service principal cannot access resources even if it exists. This process ensures apps can authenticate and act securely without needing user credentials.

Practice

1. What is the main purpose of a service principal in Azure?

easy

A. To allow applications to access Azure resources securely without user accounts

B. To create user accounts for Azure administrators

C. To monitor network traffic in Azure

D. To store data in Azure Blob Storage

Solution

1. Step 1: Understand service principal role

   A service principal acts like an identity for an application to access Azure resources securely.

2. Step 2: Compare options

   Only To allow applications to access Azure resources securely without user accounts describes this purpose correctly; others describe unrelated Azure features.

3. Final Answer:

   To allow applications to access Azure resources securely without user accounts -> Option A

4. Quick Check:

   Service principal = app identity for secure access [OK]

Hint: Service principals are app identities, not user accounts [OK]

Common Mistakes:

• Confusing service principals with user accounts
• Thinking service principals manage storage or network
• Assuming service principals are for monitoring

2. Which Azure CLI command correctly creates a service principal with contributor role for a specific resource group?

easy

A. az ad sp create --name MyApp --role reader --scopes /subscriptions/123/resourceGroups/MyGroup

B. az sp create --name MyApp --role contributor --scope /resourceGroups/MyGroup

C. az ad create-sp --name MyApp --role admin --scope /subscriptions/123/resourceGroups/MyGroup

D. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

Solution

1. Step 1: Identify correct Azure CLI syntax

   The correct command to create a service principal is 'az ad sp create-for-rbac' with parameters for name, role, and scopes.

2. Step 2: Validate options

   az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup uses correct command and parameters. Others have wrong commands, roles, or parameter names.

3. Final Answer:

   az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup -> Option D

4. Quick Check:

   Correct CLI command = az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup [OK]

Hint: Use 'az ad sp create-for-rbac' with correct role and scope [OK]

Common Mistakes:

• Using wrong command like 'az sp create'
• Misspelling 'scopes' or 'scope'
• Assigning incorrect roles like 'admin' or 'reader'

3. Given this Azure CLI output after creating a service principal:

{
  "appId": "abcd-1234",
  "displayName": "MyApp",
  "password": "secret",
  "tenant": "tenant-5678"
}

What does the appId represent?

medium

A. The password to access the service principal

B. The unique identifier for the service principal application

C. The tenant ID where the service principal is created

D. The display name of the Azure subscription

Solution

1. Step 1: Understand Azure CLI output fields

   The 'appId' is the unique ID for the service principal's application identity.

2. Step 2: Match fields to meanings

   'password' is the secret, 'tenant' is the Azure tenant ID, 'displayName' is the name shown.

3. Final Answer:

   The unique identifier for the service principal application -> Option B

4. Quick Check:

   appId = service principal unique ID [OK]

Hint: appId is the app's unique ID, not password or tenant [OK]

Common Mistakes:

• Confusing appId with password or tenant
• Thinking appId is subscription name
• Mixing displayName with appId

4. You run this command to create a service principal:

az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

But you get an error: Insufficient privileges to complete the operation.
What is the most likely cause?

medium

A. The role 'contributor' does not exist

B. The resource group name is incorrect

C. Your user account lacks permission to create service principals

D. The Azure CLI is not installed

Solution

1. Step 1: Analyze error message

   'Insufficient privileges' means the user does not have rights to create service principals.

2. Step 2: Check other options

   Resource group name errors or missing CLI cause different errors; 'contributor' is a valid role.

3. Final Answer:

   Your user account lacks permission to create service principals -> Option C

4. Quick Check:

   Permission error = user lacks rights [OK]

Hint: Check user permissions if 'Insufficient privileges' error appears [OK]

Common Mistakes:

• Assuming resource group name typo causes privilege error
• Thinking role name is invalid
• Ignoring user permission requirements

5. You want to create a service principal that can only read data from a storage account named mystorage in resource group MyGroup. Which Azure CLI command correctly limits permissions to just that storage account?

hard

A. az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage

B. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup

C. az ad sp create-for-rbac --name MyApp --role reader --scopes /subscriptions/123

D. az ad sp create-for-rbac --name MyApp --role Storage Account Contributor --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage

Solution

1. Step 1: Identify required permission and scope

   To allow only read access to blobs, use role 'Storage Blob Data Reader' scoped to the specific storage account.

2. Step 2: Evaluate options

   az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage uses correct role and precise scope. az ad sp create-for-rbac --name MyApp --role contributor --scopes /subscriptions/123/resourceGroups/MyGroup is too broad (contributor on resource group). az ad sp create-for-rbac --name MyApp --role reader --scopes /subscriptions/123 scopes too wide with reader role. az ad sp create-for-rbac --name MyApp --role Storage Account Contributor --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage grants more permissions than needed.

3. Final Answer:

   az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage -> Option A

4. Quick Check:

   Least privilege with correct role and scope = az ad sp create-for-rbac --name MyApp --role Storage Blob Data Reader --scopes /subscriptions/123/resourceGroups/MyGroup/providers/Microsoft.Storage/storageAccounts/mystorage [OK]

Hint: Use least privilege role scoped to exact resource [OK]

Common Mistakes:

• Using broad roles like contributor unnecessarily
• Scoping to resource group instead of specific storage account
• Choosing roles that allow write or delete permissions