shadcn.io is not affiliated with official shadcn/ui
Identity Provider Settings Block for React
An identity provider settings panel with a protocol picker, an https-only issuer, a masked client secret, a claim mapping table that shows what each claim resolves to in a sample token tree, and a provisioning rule.
Installation
Overview
Map what your identity provider sends onto the fields your app uses, and see the result for a sample person, with this identity provider settings panel for React with Base UI. A hairline frame with a plus mark on each corner starts with the connection: a Segment Group for the protocol (OpenID Connect or SAML 2.0), an issuer that has to be an https address, a client ID and a client secret in a Password Input. Then the claim mapping, a native table with a row for each of our fields (email, first name, last name, groups), a Native Select of the claims the provider sends and, beside it, the value that claim holds in a typed sample token, which is drawn beside the table as a JSON Tree View. A required field that maps to nothing, to an empty claim or, for email, to something that isn't an address is named in its row. A last band decides whether a first sign-in creates an account, with a default role, and spells out what would happen for the sample person. The action foot counts unsaved changes beside a Shine Button that saves them and an outline button that discards them. It's built from Segment Group, Password Input, JSON Tree View, Native Select, Switch, Field, Button, Shine Button and Guides, with a CSS entrance only. Nothing connects to a provider.
FAQ
How do I use my own claims?
Edit OIDC_TOKEN and SAML_TOKEN at the top: they are the sample person's claims for each protocol, with a few arrays and an empty value to show how those resolve, and OIDC_MAPS and SAML_MAPS are the claims each field reads by default. The menus list the claims of the token, the resolved values, the problems and the provisioning sentence are worked out from it, and TARGETS is the list of our fields with which are required. In your app, the token would be a real one from a test sign-in.
What counts as a missing field?
A required field is named in its row when it maps to nothing, when the claim it maps to is empty in the sample token, or, for email, when the value isn't shaped like an address, so mapping email to a name claim is caught. Save refuses while a problem remains, says which field, and puts focus on its menu. Optional fields can stay unmapped or empty, and the resolved column says "Not mapped" or "No value". Switching the protocol resets the claims to that protocol's usual names and says so.
Why must the issuer be https?
An identity provider's issuer address is where your app fetches keys and where tokens are checked, so a plain http address would let anyone on the path change them. Save refuses an empty issuer, one that doesn't start with https:// and one that isn't a valid address, says why under the field and puts focus on it; once Save has found something, the message follows your typing. The secret is masked with a show button and is fictional.
What stays local, and how do I make it real?
Everything. Nothing connects to a provider or fetches a token: the connection, the mapping and the switch live in this page's state, and Save only says what it kept. To make it real, store the connection, keep the secret on the server and never send it back to the browser, read the claims from the provider's real tokens and apply the mapping and the default role when an account is created.
How does it look on a phone, and is it accessible?
The connection fields stack, each table row becomes a card with the field, its menu and what it resolves to, the token tree sits under the cards in a scroller of its own and the action foot is pinned to the bottom of the screen. The table has a caption and column headers on a large screen, each menu is named for its field ("Claim for Email") and described by what it resolves to and any problem, and the status line is a polite live region present from the start.
Related
- Pro
SAML Setup Settings
Sign-in and securityA SAML single sign-on setup sheet shown open over a drawn security page: copy two values, paste the provider's metadata and see what is found (including the certificate's end day read from the certificate), run a local test, then enforce.
- Pro
Sign-in Methods Settings
Sign-in and securityA sign-in methods settings panel with five methods you can switch and reorder, a drawn sign-in card that is redrawn from them, a last-method guard and a lockout rule that restates itself.
- Pro
Multi-Factor Authentication Settings
Sign-in and securityA multi-factor policy settings panel with choice cells for who must use it, allowed methods with a keep-one guard, a grace period that prints the start day, and a coverage meter that draws the people who have not set one up.
- Pro
Role Permissions Settings
Team and rolesA roles window with a rail of five roles and a detail of grouped permissions: mixed-state group boxes, a Compare with select that marks each permission with a plus or a minus, read-only system roles and Duplicate to edit.
- Pro
SSO Config Account
Sign-in methodsMove your account to company sign-in: what changes as a list of terms, three things to tick, a Shine Button that wakes when all hold and a dialog that asks for the company domain, then a Switch back until the password stops.
- Pro
Access Token Hygiene Settings
Sign-in and securityAn access token settings panel that flags risky tokens (no end date, unused for 90 days, the admin scope, ending soon), gives a token an end date from a menu, and revokes the ticked ones after an alert dialog lists them.