We are trying to promote Vault as OIDC provider for Boundary, but it is not working as expected

The auto generated issuer address is missing the vault address, ideally it should be “issuer”: https:// vaultaddres s:8200/v1/identity/oidc/provider/my-provider

But the issuer address is :"/v1/identity/oidc/provider/my-provider"

ref url: Vault as an OIDC Identity Provider | Vault - HashiCorp Learn

Does your Vault cluster config have an api_addr set in its configuration?

If it does, that should be what’s being used as the scheme://host:port part of the URL – if not, Vault will try to determine one to use automatically, but it’s not always able to do this (I believe you can check by looking at the api_addr value in the output of vault read sys/config/state/sanitized). If none is set or auto-detected, you can specify the OIDC issuer explicitly as part of the OIDC provider setup.

Hi, Omkensey we tried to follow the url and modify the issuer, but it not changing.

Would really appreciate it if you could show in commands how to change issuer.

We are getting {“errors”:[“unsupported operation”]} when updating the issuer value

LOGS Below

curl --header “X-Vault-Token: $VAULT_TOKEN” --request POST --data @payload.json $VAULT_ADDR/v1/identity/oidc/provider/my-provider/.well-known/openid-configuration

{“errors”:[“unsupported operation”]}

root@vaultx:~# cat payload.json
{
“data”: {
“issuer”: “https://vaultx.techrock.info:8200/v1/identity/oidc/provider/my-provider”,
“jwks_uri”: “/v1/identity/oidc/provider/my-provider/.well-known/keys”,
“authorization_endpoint”: “/ui/vault/identity/oidc/provider/my-provider/authorize”,
“token_endpoint”: “/v1/identity/oidc/provider/my-provider/token”,
“userinfo_endpoint”: “/v1/identity/oidc/provider/my-provider/userinfo”,
“request_uri_parameter_supported”: false,
“id_token_signing_alg_values_supported”: [
“RS256”,
“RS384”
],
“response_types_supported”: [
“code”
],
“scopes_supported”: [
“groups”,
“user”,
“openid”
],
“subject_types_supported”: [
“public”
],
“grant_types_supported”: [
“authorization_code”
],
“token_endpoint_auth_methods_supported”: [
“none”,
“client_secret_basic”
]
}
}

root@vaultx:~# curl --header “X-Vault-Token: $VAULT_TOKEN” --request POST --data @payload.json $VAULT_ADDR/v1/identity/oidc/provider/my-provider/.well-known/openid-configuration -v
Note: Unnecessary use of -X or --request, POST is already inferred.

  • Trying 3.19.74.64:8200…
  • TCP_NODELAY set
  • Connected to vaultx.techrock.info (3.19.74.64) port 8200 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Request CERT (13):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, Certificate (11):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=vaultx.techrock.info
  • start date: Apr 8 01:02:31 2022 GMT
  • expire date: Jul 7 01:02:30 2022 GMT
  • subjectAltName: host “vaultx.techrock.info” matched cert’s “vaultx.techrock.info”
  • issuer: C=US; O=Let’s Encrypt; CN=R3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • Using Stream ID: 1 (easy handle 0x56348e450fa0)

POST /v1/identity/oidc/provider/my-provider/.well-known/openid-configuration HTTP/2
Host: vaultx.techrock.info:8200
user-agent: curl/7.68.0
accept: /
content-length: 805
content-type: application/x-www-form-urlencoded

  • We are completely uploaded and fine
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
    < HTTP/2 405
    < cache-control: no-store
    < content-type: application/json
    < strict-transport-security: max-age=31536000; includeSubDomains
    < content-length: 37
    < date: Sat, 16 Apr 2022 07:44:23 GMT
    <
    {“errors”:[“unsupported operation”]}
  • Connection #0 to host vaultx.techrock.info left intact

The OIDC well-known path isn’t an API endpoint you can send a configuration update to in Vault. Our Learn guide for setting up the OIDC provider will step you through how to set that up. But as a first step, what do you see for the api_addr when you run vault read sys/config/state/sanitized?

The endpoints for the OIDC provider are documented in the OIDC provider API docs.

root@vaultx:~# vault read sys/config/state/sanitized
Key Value


api_addr n/a
cache_size 0
cluster_addr n/a
cluster_cipher_suites n/a
cluster_name n/a
default_lease_ttl 0s
default_max_request_duration 0s
disable_cache false
disable_clustering false
disable_indexing false
disable_mlock false
disable_performance_standby false
disable_printable_check false
disable_sealwrap false
disable_sentinel_trace false
enable_response_header_hostname false
enable_response_header_raft_node_id false
enable_ui true
listeners [map[config:map[address:0.0.0.0:8200 tls_cert_file:/opt/vault/tls/vaultxfullchain.pem tls_key_file:/opt/vault/tls/vaultxprivatekey.pem] type:tcp]]
log_format unspecified
log_level n/a
log_requests_level n/a
max_lease_ttl 0s
pid_file n/a
plugin_directory n/a
raw_storage_endpoint false
seals [map[disabled:false type:shamir]]
storage map[cluster_addr: disable_clustering:false redirect_addr: type:file]
root@vaultx:~#

cat /etc/vault.d/vault.hcl

ui = true

storage “file” {
path = “/opt/vault/data”
}

HTTPS listener

listener “tcp” {
address = “0.0.0.0:8200”
tls_cert_file = “/opt/vault/tls/vaultxfullchain.pem”
tls_key_file = “/opt/vault/tls/vaultxprivatekey.pem”
}

  • issuer (string: <optional>) - Specifies what will be used as the scheme://host:port component for the iss claim of ID tokens. This defaults to a URL with Vault’s api_addr as the scheme://host:port component and /v1/:namespace/identity/oidc/provider/:name as the path component. If provided explicitly, it must point to a Vault instance that is network reachable by clients for ID token validation.

You have set neither api_addr in the Vault configuration file, nor the issuer parameter when setting up the OIDC provider - you are going to have to set one of these.

1 Like

I think you can just repeat step 5 of the “Create an OIDC provider” section in the Learn guide, but this time add issuer=https://[your Vault hostname]:8200 to the command parameters.

Then repeat step 6 as-is to check the OIDC well-known path to see if it worked.

Thanks omkensey & maxb…

Now it’s Displaying the correct Vault OIDC configuration endpoint