You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/blog/identity-stack-cookbook-auth0-okta-azuread-keycloak/index.md
+20-12Lines changed: 20 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ social:
27
27
28
28
Managing identity at scale requires more than a login box. Platform teams need consistent application access patterns across Auth0, Okta, Microsoft Entra ID, and Keycloak.
29
29
30
-
In this cookbook, we'll explore how to implement a portable identity pattern using Pulumi. We'll cover Auth0, Okta, Microsoft Entra ID, and Keycloak, focusing on a common requirement: one application and one access group.
30
+
In this cookbook, we'll explore how to implement a portable identity pattern using Pulumi. We'll cover Auth0, Okta, Microsoft Entra ID, and Keycloak, focusing on a common requirement: one application and one provider-specific access container.
31
31
32
32
This post provides a common SSO application pattern across these providers for your own applications, rather than configuring Pulumi organization SSO. By the end, you will have implemented a portable identity pattern across Auth0, Okta, Microsoft Entra ID, and Keycloak.
33
33
@@ -47,13 +47,13 @@ Identity providers (IdPs) are often treated as static infrastructure, but they a
47
47
The goal is to create a reusable pattern that works across different providers. This pattern includes:
48
48
49
49
1.**An application**: The service or platform users will access.
50
-
1.**A group**: A collection of users who should have access to the application.
50
+
1.**An access container**: A provider-specific organization, group, or role assignment that controls who should have access to the application.
51
51
52
52
## Auth0
53
53
54
-
Auth0 is known for its developer-friendly approach and extensibility. While Auth0 handles SCIM through Enterprise Connections or Actions, the core setup involves defining a client and a connection.
54
+
Auth0 is known for its developer-friendly approach and extensibility. Auth0 does not model application access as a generic group assignment. A practical baseline is to define an application client that requires organization login, an organization as the access boundary, and a connection enabled for that client.
55
55
56
-
Prerequisites: an Auth0 tenant, a Machine-to-Machine application with Management API scopes for clients, organizations, and connections, and the Pulumi Auth0 provider configured with the tenant domain, client ID, and client secret.
56
+
Prerequisites: an Auth0 tenant, a Machine-to-Machine application with Management API scopes for clients, organizations, connections, and connection clients, and the Pulumi Auth0 provider configured with the tenant domain, client ID, and client secret.
57
57
58
58
```typescript
59
59
import*asauth0from"@pulumi/auth0";
@@ -62,16 +62,22 @@ const client = new auth0.Client("auth0-app", {
@@ -111,10 +117,12 @@ const assignment = new okta.app.GroupAssignment("okta-assignment", {
111
117
112
118
## Microsoft Entra ID
113
119
114
-
For organizations heavily invested in the Microsoft ecosystem, Microsoft Entra ID is the standard. Pulumi allows you to manage applications and service principals with ease.
120
+
For organizations heavily invested in the Microsoft ecosystem, Microsoft Entra ID is the standard. Pulumi allows you to manage applications and service principals with ease. This minimal example focuses on the application, service principal, group, and assignment resources; add redirect URI and platform configuration for your specific application type before using it as a live SSO app.
115
121
116
122
Prerequisites: a Microsoft Entra tenant, permissions to create applications, service principals, groups, and app role assignments, and the Pulumi Microsoft Entra ID provider authenticated through your chosen Azure identity flow.
117
123
124
+
The default app role ID assigns the group to the application without requiring a custom app role. Replace it with an `appRoles[].id` value when your application defines custom roles.
125
+
118
126
```typescript
119
127
import*asazureadfrom"@pulumi/azuread";
120
128
@@ -127,15 +135,14 @@ const group = new azuread.Group("entra-group", {
@@ -169,7 +176,7 @@ const group = new keycloak.Group("keycloak-group", {
169
176
name: "My Group",
170
177
});
171
178
172
-
const role =newkeycloak.openid.ClientRole("keycloak-app-user-role", {
179
+
const role =newkeycloak.Role("keycloak-app-user-role", {
173
180
realmId: realm.id,
174
181
clientId: client.id,
175
182
name: "app-user",
@@ -179,11 +186,12 @@ const groupRoles = new keycloak.GroupRoles("keycloak-group-roles", {
179
186
realmId: realm.id,
180
187
groupId: group.id,
181
188
roleIds: [role.id],
189
+
exhaustive: false,
182
190
});
183
191
```
184
192
185
193
## When to switch and how
186
194
187
195
Choosing an identity provider depends on your specific needs. Auth0 is a strong fit for external application authentication. Okta and Microsoft Entra ID are common choices for internal workforce management. Keycloak is ideal for teams that need full control over their identity infrastructure.
188
196
189
-
When switching providers, the key is to maintain the same logical structure. By using Pulumi, you can swap the provider-specific resources while keeping your application logic intact. This approach ensures that your identity stack remains as portable as your cloud infrastructure.
197
+
When switching providers, the key is to maintain the same logical structure. By using Pulumi, you can keep the same intent in code while mapping it to each provider's resource model. Auth0 organizations, Okta groups, Entra ID groups, and Keycloak groups are not identical, so migrations still require a provider-specific access review.
0 commit comments