OIDC Auth Method - Multiple Discovery URLs

[dtns2]

Overview

HashiCorp Vault does not currently support configuration of the OIDC Auth Method that can be leveraged on a system that is accessible from more than one URL.

Simply put, there are limitations in how the Identity Provider's permission groups get mapped to Vault Identity Group Alias / OIDC Auth mount point pairs that prevents this behavior.

Problem: This can result in Vault OIDC authentication remaining inaccessible to a subset of its intended users depending on where they are accessing Vault from.

Context

Consider a scenario where Vault is deployed on a network that uses as single Identity Provider for single-sign-on (SSO) authentication. This network is accessible publicly for a subset of whitelisted IP addresses, but also has a VPN into the network to access resources internally. For this reason, the Vault will be accessed with two different URLs based on where the users are authenticating from:

1. External Users (coming from whitelisted external network)
   • URL: https://vault.example.com
   • OIDC Discovery URL: https://sso.example.com
   • Example OIDC Mount: auth_oidc_1a2b3c4d
2. Internal Users (accessing while on VPN)
   • URL: https://vault.example.internal
   • OIDC Discovery URL: https://sso.example.internal

What Vault expects for the functioning of OIDC is a one-to-one mapping of each Identity Provider's permission group to a single Vault Identity Group Alias with matching names.

Identity Provider Permission Group	Vault Identity Group Alias
group1	group1
group2	group2

The issue here lies in the fact that each Vault Identity Group Alias must be mapped to a single OIDC Auth mount which are specific to a single OIDC Discovery URL in order to authenticate with the Identity Provider. Meaning, there is not a one-to-many relationship that can be created in order to map a single permission group that exists in the Identity Provider to more than one OIDC Discovery URL.

Vault Identity Group Alias	OIDC Auth mount	OIDC Discovery URL
group1	? auth_oidc_1a2b3c4d / auth_oidc_2z4y6x8w	? https://sso.example.com / https://sso.example.internal
group2	? auth_oidc_1a2b3c4d / auth_oidc_2z4y6x8w	? https://sso.example.com / https://sso.example.internal

Requested Solution(s)

In general, request is to see more flexibility in the form on a one-to-many relationship that can created somewhere along the chain from Identity Provider Permission Groups to Vault OIDC Auth Method Discovery URLs. There are multiple potential ways to do this:

1. Allow a single OIDC Auth Method mount point to direct users to more than one OIDC Discovery URL
   • This could take the form perhaps of a selection menu of different OIDC Discovery URL options to choose from (when more than one is configured) for the user to select to authenticate to when signing in with OIDC
   • e.g. auth_oidc_1a2b3c4d could map to both https://sso.example.com and https://sso.example.internal
2. Allow a single Vault Identity Group Alias to associate with more than one OIDC Auth Method mount point
   • e.g. Identity Group Alias group1 could map to both auth_oidc_1a2b3c4d and auth_oidc_2z4y6x8w
3. Allow the creation of Vault Identity Group Aliases with identical names, but with different OIDC Auth Method mount points
   • Essentially the same as number 2, but inner-workings may be different
   • e.g. There could exist two Identity Group Aliases named group1
     • group1 (id: 02e6b3c5-998a-9a33-bd5c-6c79630f36a2), maps to auth_oidc_1a2b3c4d
     • group1 (id: 0f0b6a9f-d997-6118-e6ed-941251acb8ff), maps to auth_oidc_2z4y6x8w

Alternatives Considered

1. Don't allow multiple discovery URLs
   • This would be the easiest workaround if there is an option to do so, but is not always the case
2. Create duplicates of every permission group in the Identity Provider to map to alternatively named Vault Identity Group Aliases
   • In this example, there could be a set of -external and -internal permission groups that map to two different OIDC Mount points perhaps oidc-external and oidc-internal
   • Problem with this is when the number of permission groups grows exceedingly large and maintainability becomes limiting factor
   • Many other applications do not suffer from this limitation, and have more flexible mechanisms to support authentication with the identity provider. To avoid naming confusion, you might see thrice the groups created
     • group1 - for tools that work both externally and internally
     • group1-external - for Vault and other tools limited to needing specific groups for external access
     • group1-internal - for Vault and other tools limited to needing specific groups for internal access
     • group2 - for tools that work both externally and internally
     • group2-external - for Vault and other tools limited to needing specific groups for external access
     • group2-internal - for Vault and other tools limited to needing specific groups for internal access
     • ...

[UXabre]

From reading this, it seems to be a related to my issue. But which I mean, the proposal above could very well serve my purpose as well (which could lead to killing 2 birds with on stone perhaps?):

#9763

[aghassemlouei]

Any updated @swayne275 ? Also seeing this same issue and it's been a few months with a possible fix for @UXabre.