Skip to content

WebGUI

Jump to bottom
Sis Nikoyan edited this page Sep 4, 2026 · 12 revisions

Note

Open a bug report or feature request in versitygw Issues for any bugs or new feature requests

Table of Contents

The WebGUI is NOT enabled by default. The listening port must be configured in order to enable the WebGUI.

This guide covers the configuration, authentication, and usage of the VersityGW WebGUI interface. A single build serves every deployment: an S3 gateway on its own, the standalone IAM service on its own, and both together. What you see after signing in is decided by what your credentials can actually reach, not by a role name stored anywhere.

Enabling VersityGW WebGUI

   --webui value [ --webui value ]                                    enable WebUI server on the specified listen address (e.g. ':7071', '127.0.0.1:7071', 'localhost:7071', '/run/vgw/webui.sock'; supports the same UNIX socket forms as --port; can be specified multiple times for listening on multiple addresses; disabled when omitted) [$VGW_WEBUI_PORT]
   --webui-cert value                                                 TLS cert file for WebUI (defaults to --cert value when WebUI is enabled) [$VGW_WEBUI_CERT]
   --webui-key value                                                  TLS key file for WebUI (defaults to --key value when WebUI is enabled) [$VGW_WEBUI_KEY]
   --webui-no-tls                                                     disable TLS for WebUI even if TLS is configured for the gateway (default: false) [$VGW_WEBUI_NO_TLS]
   --webui-gateways value [ --webui-gateways value ]                  override auto-detected S3 gateway URLs for WebUI (e.g. 'http://localhost:7070', 'https://s3.example.com'; can be specified multiple times) [$VGW_WEBUI_GATEWAYS]
   --webui-admin-gateways value [ --webui-admin-gateways value ]      override auto-detected admin gateway URLs for WebUI (e.g. 'http://localhost:7080', 'https://admin.example.com'; can be specified multiple times) [$VGW_WEBUI_ADMIN_GATEWAYS]
   --webui-iam-gateways value [ --webui-iam-gateways value ]          standalone IAM service URLs offered to the WebUI login page (e.g. 'http://localhost:7076', 'https://iam.example.com'; can be specified multiple times). Not auto-detected from an S3 gateway: the IAM service is a separate process. Setting this also tells the WebUI that the standalone IAM service, not the admin API, manages this deployment: the admin endpoint is ignored entirely (hidden from the login page along with every admin-API surface), and the management pages run on the S3 and IAM APIs alone [$VGW_WEBUI_IAM_GATEWAYS]
   --webui-path-prefix value                                          mount the WebUI under a path prefix (e.g. '/ui'); must be single segment path that starts with '/' [$VGW_WEBUI_PATH_PREFIX]
   --webui-s3-prefix value                                            mount the WebUI on the S3 port at the given path prefix (e.g. '/ui'); must start with '/', must not be '/', and must not end with '/' [$VGW_WEBUI_S3_PREFIX]
   --cors-allow-origin value                                          default CORS Access-Control-Allow-Origin value (applied when no bucket CORS configuration exists, for admin APIs, and for the standalone IAM API); required on the 'iam' command before a browser-based WebUI on another origin can reach it [$VGW_CORS_ALLOW_ORIGIN]

The --webui option takes a :<port> or <ip/name>:<port> style option to specify listening interface/port for the webui. For example, if I want to enable the webui on port 7071, I could run the following:

versitygw --access test --secret test --iam-dir /tmp/gw --webui :7071 posix --versioning-dir /tmp/vers /tmp/gw

These are global flags, so they go before the subcommand name; Global Options lists which of them the iam command honours. Two things that reference cannot tell you: versitygw iam --help does not list the --webui* flags even though the iam command honours them, and --webui-s3-prefix is not supported there at all, so the WebUI cannot be mounted on the IAM API port and always needs a --webui listen address of its own. --webui-cert/--webui-key fall back to the process's own --cert/--key unless --webui-no-tls is given — see TLS.

There is no port-conflict pre-check on the iam command: giving --port and --webui the same address fails at bind time with failed to bind webui listener …, not at startup validation.

CORS is not optional for a browser. Read CORS and browser access before deploying any of the modes below.

Deployment modes

One binary and one embedded WebUI bundle serve three deployments. The difference is which endpoints the login page offers and which endpoints the browser can reach with your credentials.

Mode Process hosting the WebUI Endpoints offered on the login page Pages available
S3 only the S3 gateway S3, admin Dashboard, Users, Buckets, Explorer (admin); Explorer (standard user)
IAM only versitygw iam IAM IAM, IAM Users, IAM Roles, IAM Providers
S3 and IAM either process S3, IAM Dashboard, Buckets, Explorer, IAM, IAM Users, IAM Roles, IAM Providers

S3 only

The original behavior, unchanged: the S3 gateway hosts the WebUI, a built-in IAM backend (--iam-dir, LDAP, Vault, FreeIPA or S3) holds the accounts, and the admin API manages them. The S3 and admin endpoint fields are prefilled from the gateway's own ports, and the IAM field renders empty.

versitygw --access test --secret test --iam-dir /tmp/gw \
  --webui :7071 --cors-allow-origin http://127.0.0.1:7071 \
  posix /data

IAM only

The standalone IAM service can host the WebUI itself, for an identity control plane that runs no S3 gateway at all.

versitygw --port :7076 --webui :8080 --cors-allow-origin http://localhost:8080 \
  iam --dir /var/lib/vgw-iam
  • The service auto-detects its own IAM gateway URLs from its --port list, so the login page's IAM endpoint field is prefilled with no extra flag. A --port list made up only of UNIX sockets produces no URL and prefills nothing. --webui-iam-gateways overrides the detection when the browser reaches the service through a name the process does not know about — behind a reverse proxy, for instance.
  • Because the IAM endpoint is set the Admin API Endpoint field is hidden, and because the S3 endpoint is blank Region and Bucket Addressing Style are hidden with it. Signing in with just an IAM endpoint is a complete sign-in.
  • dashboard.html, buckets.html and explorer.html all redirect to iam.html, and users.html to iam-users.html. The Management and Explorer sidebar sections disappear with their pages.
image

S3 and IAM

When an S3 gateway is backed by the standalone IAM service, the WebUI shows both halves at once: the S3 data plane in the Explorer and Buckets pages, the IAM control plane in the IAM pages. Two processes are involved, and both need configuring.

# S3 gateway — hosts the dashboard and points it at the IAM service
versitygw --port :7070 --webui :8080 \
  --webui-iam-gateways http://localhost:7076 \
  --iam-standalone-endpoint /run/vgw/iam.sock \
  posix /data

# IAM service — must allow the dashboard's origin
versitygw --port :7076 --cors-allow-origin http://localhost:8080 \
  iam --dir /var/lib/vgw-iam --private-ports /run/vgw/iam.sock

--iam-standalone-endpoint and --private-ports are the gateway's own control channel to the IAM service and have nothing to do with the browser, which talks to the public IAM API on --port. Configuring that channel, including its mTLS variant, is covered in Standalone IAM Setup.

  • --webui-iam-gateways (VGW_WEBUI_IAM_GATEWAYS) is repeatable, and its only job is to seed the login page's IAM endpoint field: the first entry prefills the field and the rest populate its dropdown.
  • It is never auto-detected. --webui-admin-gateways falls back to the gateway's own URLs when unset, because the admin API shares the gateway's port by default. The IAM service does not: it is a separate process, on a separate port, possibly on a separate host, and the gateway has no way to discover where a browser can reach it. An unset --webui-iam-gateways therefore means "no IAM endpoint to offer", not "same host".
  • Setting the flag is a statement about the deployment as well as a convenience: the WebUI switches to standalone-IAM mode, where the admin endpoint is ignored entirely, hidden from the login page along with every admin-API surface, and the management pages run on the S3 and IAM APIs alone. See The admin API in a standalone IAM deployment.
  • Because the flag only seeds a field, the field remains editable. A user can clear it and sign in to S3 alone, or type an IAM endpoint by hand on a gateway that never set the flag. Everything the WebUI does keys off the session's IAM endpoint, not off the flag.
  • Invalid URLs are reported at startup, one warning per entry — WARNING: invalid WebuiIAMGateways URL "iam.example.com": missing scheme (must be http:// or https://) — and if every entry is invalid the gateway refuses to start with WebuiIAMGateways URLs specified but none are valid.
image

The mirror arrangement works too: let the IAM service host the WebUI and point it at an S3 gateway with --webui-gateways. The pages are identical; only the CORS obligation moves, because it always lands on whichever process is not hosting the WebUI.

CORS and browser access

Important

--cors-allow-origin applies to the iam command as well as to the S3 gateway. Every WebUI call to the IAM API is cross-origin, because the WebUI never shares a port with the IAM API. Without an allowed origin the IAM CORS middleware is not registered at all and no browser can reach the IAM API. The only symptom is IAM navigation that silently never appears.

The value must match the browser's Origin header exactly — scheme, host and port, with no trailing slash and no path — because the IAM middleware returns the configured string verbatim rather than echoing the request's Origin. One consequence: only a single origin can ever be allowed, so two WebUI origins require *.

The wildcard fallback below fires only on the process that has --webui set, so the flag is always needed on the other one.

Deployment Process hosting the WebUI Process that must be given --cors-allow-origin <webui origin>
S3 only the S3 gateway none required — the fallback covers it, but set it anyway
IAM only versitygw iam none required — the fallback covers it, but set it anyway
IAM hosts the WebUI, plus --webui-gateways versitygw iam the S3 gateway
S3 gateway hosts the WebUI, plus --webui-iam-gateways the S3 gateway the standalone IAM service
S3 gateway with --webui-s3-prefix only the S3 gateway, same origin as the S3 API the standalone IAM service, and the admin API if it has its own --admin-port

Setting --webui without --cors-allow-origin falls back to * and warns on stderr. The fallback is gated on --webui being set on that same process, so --webui-s3-prefix alone does not trigger it. On the S3 gateway the warning carries a suggestion computed from the WebUI listen addresses: consider setting it to one of: http://192.0.2.10:8080, http://127.0.0.1:8080 (or your public hostname). * is safe for the WebUI's SigV4 traffic — it signs with an Authorization header and never sends cookies, so the browser rule forbidding a wildcard with credentialed requests does not apply — but narrowing it to the real origin is still worth doing.

An IAM endpoint the browser cannot reach does not block sign-in: the session signs in on whatever else answered, and the failure arrives as a one-off error toast naming CORS and TLS certificates as the usual causes. See Troubleshooting.

Once the WebGUI is enabled and the gateway is running, you can access the interface through your web browser.

Login

To access the WebGUI, navigate to the URL specified in your port configuration in a web browser. For example, if using the configuration shown above, visit http://127.0.0.1:7071.

The login page allows you to authenticate using your access and secret key credentials. Advanced options are available to specify alternative S3, admin or IAM endpoints if your gateway is configured with custom endpoints. By default, the WebGUI uses the endpoints from the process hosting the interface.

To logout after you're finished, click the "Sign Out" button in the bottom left corner of the interface.

login

Advanced Options holds three endpoint fields, and the page rearranges itself as you fill them in:

  • Admin API Endpoint is hidden the moment an IAM endpoint is present, S3 or not. Where it is shown, blank means "the same place as the S3 endpoint", since the admin API shares the gateway's port unless --admin-port was given.
  • Region and Bucket Addressing Style are hidden when the S3 endpoint is blank and an IAM endpoint is set, since both only describe how to talk to an S3 gateway.
  • Either endpoint alone is a complete sign-in; only both blank is refused.
login-iam-endpoint

Capability-gated navigation

Navigation is decided by capability, not by a role name. On sign-in the session probes the S3, admin and IAM endpoints independently, and one success never masks another.

Probe Endpoint Call Establishes
1 S3 data plane ListBuckets (GET /) whether the S3 API accepts these credentials, and whether they may list all buckets
2 Admin API — only attempted if the S3 probe succeeded and an admin endpoint is configured PATCH /list-buckets whether these credentials hold the admin role
3 Standalone IAM service STS GetCallerIdentity whether the IAM service accepts these credentials

An unconfigured S3 endpoint is skipped, not failed — that is an IAM-only sign-in. On the S3 probe, only AccessDenied counts as "the credentials are good but cannot list buckets"; the other 403 codes (InvalidAccessKeyId, SignatureDoesNotMatch, ExpiredToken) mean the credentials themselves were rejected. The admin probe uses list-buckets rather than list-users on purpose: all admin routes share the same role gate, and list-users additionally requires an IAM backend that can enumerate accounts, which the standalone IAM backend cannot.

Every page then gates its own content on those three results, so the same HTML serves every mode. There is no single landing page: a session goes to the Dashboard if it has the management pages, otherwise the Explorer if it has S3, otherwise the IAM page. Direct URLs are guarded the same way, so a page a session cannot use bounces to that same landing page rather than rendering empty.

The badge under the access key in the bottom-left user panel names the combination: Admin, User + IAM, IAM, or User. "IAM" deliberately does not say "IAM user" — the session may be the root credential, and only the IAM overview page can tell.

The admin API in a standalone IAM deployment

Once the session has an IAM endpoint, the admin API is not merely deprioritised — it is not used at all. The standalone IAM service is the user directory, so there are no gateway accounts for the admin API to create or list, and bucket ownership is fixed rather than transferable; access comes from identity policies and bucket policies instead.

  • The login page hides the admin field whenever an IAM endpoint is present, and the session is given no admin endpoint at all — a hidden field still holding a server-prefilled value is discarded at sign-in. The admin probe therefore never runs, and the session is never admin, including when you sign in as the root credential. There is no "IAM admin" mode.
  • users.html redirects to iam-users.html. The IAM check runs before the admin check on purpose: a standalone-IAM session is never admin, so checking admin first would bounce it to the landing page instead of to the IAM equivalent.
  • Every admin-only surface stays off screen — the Users navigation link on every page, the Dashboard's Total Users card, its Manage Users quick action, and its Recent Users table.

Dashboard and Buckets remain available

The management pages are not admin-only. Any S3 session in a standalone-IAM deployment gets them, running on the S3 and IAM APIs alone and surfacing each denial per action rather than redirecting.

  • Dashboard. Every panel is its own request, so one failure does not blank the others, and a denied listing still reads System Status: Connected — a denial is a permissions answer, not a broken connection. System Status only reads Error when no panel answered at all. Total Users becomes an IAM Users card, Recent Users a Recent IAM Users table, and the quick actions Manage IAM Users and Manage IAM Roles.
  • Buckets. The ownership UI collapses: the owner filter is hidden, the Owner column becomes Created, and the Actions column is removed entirely because it held only the ownership transfer. Listing uses the S3 ListBuckets call rather than the admin one, and creation goes through S3 CreateBucket with the gateway fixing the owner. "Enable versioning" is a separate and separately authorized call, so it can fail on its own with Bucket "<name>" created, but enabling versioning failed: <error>.

Which buckets a caller may see and act on is decided per request by policy rather than by ownership; see Standalone IAM Service for the data-plane consequences.

buckets-iam-managed

Browser-side request signing

The WebUI signs IAM and STS calls in the browser, with the signing region fixed to us-east-1 regardless of the region chosen on the login page. It never assumes a role and never uses session tokens — roles and identity providers are managed from the UI, not exercised by it; see STS & Web Identity for the federation flow itself.

Warning

Because signing happens client-side, the secret access key is held in the browser session for the life of the tab; there is no server-side signing proxy. Serve the WebUI over HTTPS, sign in with a credential scoped by identity policy to what that person actually needs, and sign out when finished. The one exception is a newly generated secret from CreateAccessKey, which is kept only in a JavaScript variable and never written to session storage or a DOM attribute.

The following sections describe the management pages backed by the gateway's admin API. They apply only when the WebUI session has an admin endpoint, which means a deployment using one of the built-in IAM backends. In a standalone IAM deployment the Dashboard and Buckets pages drop to the IAM-managed forms described in Dashboard and Buckets remain available, and the Users page is replaced by IAM Users, IAM Roles and IAM Providers. If you're using a standard user account, skip ahead to the Explorer section.

Admin Dashboard

The Admin Dashboard is only enabled when an IAM service is defined. If the gateway is running in single user mode with no IAM service, then the admin login will be treated as a normal user since there are no accounts to manage. For this case skip down to user explorer documentation.

The Dashboard is the initial landing page after logging in with an admin account. It provides an overview of gateway status, including:

  • Gateway health and uptime
  • Total number of users
  • Total number of buckets
  • System statistics and metrics

The left navigation menu provides access to all WebGUI functionality. Which entries appear is decided by the capability probes described in Capability-gated navigation.

admin-dashboard

Admin Users

This page is reachable in admin-API mode only. When the session has an IAM endpoint its navigation link is hidden and its URL redirects to IAM Users.

The Users page provides comprehensive account management capabilities. From this interface, you can:

  • View all user accounts in a searchable table
  • Create new user accounts with customizable credentials
  • Modify existing user properties and roles
  • Delete user accounts when needed

admin-users

Creating a New User

Click the + Create User button to open the user creation dialog. You can configure:

  • Access Key: Enter manually or click "Generate" for an automatic key
  • Secret Key: Enter manually or click "Generate" for an automatic key
  • Role: Select from the dropdown (admin, user, or userplus)
  • Advanced Options: Optionally set uid/gid/projectid when these backend features are enabled

create-user

Admin Buckets

The Buckets page provides administrative bucket management capabilities. From this interface, admins can:

  • View all buckets across all users
  • Change bucket ownership by reassigning to different accounts
  • Create new buckets and assign them to specific users

admin-buckets

When the owner list cannot be enumerated, the owner picker in the create form degrades to a free-text field with the placeholder "Access key ID of a user", since an owner is identified by access key ID.

Admin Explorer

The Explorer page is the primary interface for browsing and managing bucket contents. This view is available to both admin and standard user accounts, with the key difference being scope:

  • Admin accounts: Can view and manage all buckets across all users
  • User accounts: Can only view and manage buckets they own

For detailed Explorer functionality, see the Explorer section below.

admin-explorer

The Explorer is the primary workspace for managing buckets and objects. It is available to every session whose credentials the S3 API accepted.

Explorer

Buckets

The Explorer page at the top level displays a table of buckets accessible to your account (buckets you own for standard users, or all buckets for admin accounts). The bucket table includes:

  • Name: The bucket identifier
  • Versioning: Current versioning status (Enabled/Suspended)
  • Object Lock: Object lock configuration status (Enabled/Disabled)
  • Created: Bucket creation timestamp
  • Actions: Quick access icons for bucket management

The bucket list also supports favorites: click the star icon next to any bucket name to mark it as a favorite for quick access. Favorited buckets are pinned to the top of the list and persist across sessions. Clicking on a favorited bucket directly from the favorites list navigates to its object explorer without returning to the full bucket list.

The following action icons are available for each bucket:

  • Info - Display bucket information and tags; set or modify bucket tags
  • Policy Manager - View and edit the bucket policy
  • Versioning - Enable or suspend bucket versioning
  • Object Lock - Enable or update object lock configuration
  • Multipart Uploads - View and manage outstanding multipart uploads
  • Delete Bucket - Delete the bucket (only available when bucket is empty)

user-explorer-buckets

If the sign-in probe established that the credentials work against S3 but may not list all buckets, the Explorer skips the listing call it knows will fail and renders the denied state directly, still offering to open a bucket by name. A deep link naming a bucket opens it straight away, because policy access to one bucket does not imply permission to enumerate them all.

When the gateway is backed by the standalone IAM service, a bucket policy Principal is a principal ARN — a user, a role, an assumed-role session, the account root, or * — as covered in Bucket Policies, while an ACL grantee is still an access key ID, as covered in Standalone IAM Service. The Policy Manager's help text and its Load Example button follow the backend in use: user ARNs under the standalone IAM service, access keys under the gateway's own account store.

Objects

Clicking on a bucket name opens the object explorer, which provides a folder-based hierarchical view of the bucket contents. Within this view, you can:

  • Create new folders to organize objects
  • Upload objects via drag-and-drop or file selector
  • Download objects to your local system
  • Generate presigned URLs for objects to share time-limited, credential-free access links
  • Navigate through folder structures using browser-style back/forward history buttons
  • Manage object versions when versioning is enabled

The object explorer uses server-side pagination when listing large buckets, so only a page of results is fetched at a time rather than loading the entire bucket contents at once.

The object explorer table displays the following information for each object:

  • Name - The object name (last component in the path). For example, object dir1/dir2/file is shown as "file" within the dir1/dir2/ folder
  • Versions - Version count (appears when multiple versions exist); click to list/download/delete specific versions
  • Size - Object size in human-readable format
  • Modified - Last modification timestamp
  • Class - Storage class for the object (e.g., STANDARD, GLACIER)
  • Actions - Quick access icons:
    • Versions - Versions (if multiple versions exist); click to list/download/delete specific versions
    • Info - View detailed object information; set or modify tags and metadata
    • Presigned URL - Generate a time-limited presigned URL for the object
    • Download - Download the object to your local system
    • Delete - Delete the object or specific version

object-explorer-versions

Object versions listing:

list-object-versions

Detailed object information:

object-info

The remaining sections describe the pages backed by the standalone IAM service. They appear whenever the session was given an IAM endpoint the service accepted.

IAM overview

Identity & Access is the landing page of the IAM section and of an IAM-only session, and it names the IAM API endpoint the session is using.

Three stat cards — IAM Users, Roles and OIDC Providers — each load independently, so a permission you lack for one does not blank the others. Each counts only the first page of 100 entries and shows <n>+ with a First page only note when truncated; a denied listing shows - and says so.

The My Identity card is built from STS GetCallerIdentity, the one call every valid credential can make. It shows a Root or IAM User badge, the caller's ARN, the user ID and the account, and fills in Path, Created and an access-key count opportunistically from GetUser and ListAccessKeys, leaving those rows out when they are denied. For an IAM user it also links straight into that user's manage view, deliberately bypassing the users table: listing users is a separate permission that a self-service identity will not hold.

iam-overview

IAM Users

The IAM Users page lists the users held by the standalone IAM service — Path, User Name, ARN, Created, and per-row Manage and delete actions — with a search box over the loaded rows, a path-prefix filter that narrows the server-side listing, and Load More paging through 100 users at a time. If listing is denied the page offers an escape hatch: open a single user by name. Listing users and acting on one are separate permissions.

iam-users-list

Create IAM User asks for a name, an optional set of tags, and a path under Advanced Options.

create-iam-user

The Manage view has four sections, each loaded and authorized independently, so one denial does not blank the rest.

  • Details — ARN, user ID, path and creation date, from GetUser. A denial leaves the fields blank and the rest of the view still loads.
  • Tags — the current tags with an Edit Tags button. They are read with their own permission rather than reused from GetUser, so a denial disables the button in place. See Policy Conditions for reading tags from a policy.
  • Access Keys — a user can hold 2, and the server generates both halves of the pair, so Create Access Key disables itself at two. Creating one opens a one-time dialog whose secret is held only in a JavaScript variable and cannot be retrieved afterwards. Keys can be switched between Active and Inactive or deleted, and Last Used is fetched lazily on demand.
  • Inline Policies — each policy name with its size in bytes, plus an aggregate counter of the bytes used across all of this user's inline policies, shown in red when over quota. Only inline policies exist; there are no managed policies to attach. Add Policy opens the shared policy editor, whose validation is deliberately shallow but does catch the two hard rules: an identity policy must not contain a Principal, and every statement needs a Resource. See Identity Policies.

The Edit Tags dialog is shared by all three IAM pages. It edits the whole tag set at once and applies it as the minimal pair of calls — one untag for the keys that disappeared, one tag for those added or changed, removals first so they free room under the tag cap. It switches to a case-sensitive mode for OIDC providers, whose tag keys are byte-exact where user and role keys fold; see IAM API Reference.

iam-user-tags iam-user-inline-policies

IAM Roles

The IAM Roles page lists roles with Path, Role Name, ARN, Created and Max Session, with the same search box, path-prefix filter and Load More paging as the users list.

iam-roles-list

Create Role is a two-step wizard — role details, then the trust policy in the shared editor — because a role cannot exist without a trust policy. Everything else is fixed at creation: only the trust policy, the tags and the inline policies can be changed afterwards. The Manage Role view then carries read-only details, Tags, the Trust Policy with its own editor, and Inline Policies — the same sections as a user, minus access keys. For trust-policy grammar and the assume-role flow itself, see STS & Web Identity.

role-trust-policy-editor

IAM Providers

The IAM Providers page manages the OIDC identity providers a role's trust policy can federate to. See STS & Web Identity for the token exchange itself.

The list shows the provider host, derived from the ARN without an extra call per row, plus the full ARN. There is no path filter and no paging, because the list call returns provider ARNs only; URL, client IDs and thumbprints load when a provider is opened.

iam-providers-list

Two API asymmetries the UI cannot hide:

  • Client IDs are added and removed one at a time, each its own call, while thumbprints are replaced as a whole list — saving replaces every thumbprint on the provider, and entries not listed are removed.
  • Provider tag keys are compared byte-exactly, so env and ENV are two separate tags here, where user and role tag keys fold. See IAM API Reference.

Leaving the thumbprint list blank on Create Provider makes the server fetch one over a live TLS connection to the URL — unless the service was started with --disable-oidc-thumbprint-autofetch, in which case a blank list is an error. The provider URL cannot be changed after creation.

iam-provider-manage

See Also

Versity Software logo image.

@versitysoftware

linkedin   twitter   facebook   instagram  

Clone this wiki locally