Let users sign in to GlobalForms with your organization's identity provider using OpenID Connect (OIDC). Users select a sign-in button, authenticate with the provider, and return to GlobalForms signed in.
This feature requires GlobalForms version 10.17.1 or greater.
Supported identity providers
GlobalForms works with identity providers that support the OpenID Connect authorization code flow. Step-by-step guides are available for:
Each GlobalForms server connects to one identity provider.
How it works
-
The user selects the single sign-on button on the GlobalForms sign-in page.
-
GlobalForms sends the user to the identity provider to sign in.
-
The provider returns the user to GlobalForms at
/oidc/callback. -
GlobalForms reads the user's email address from the provider and finds the GlobalForms user record with the same email. The match ignores upper and lower case.
-
GlobalForms signs the user in with that account's roles and permissions.
Single sign-on does not create GlobalForms accounts. Each person needs an existing GlobalForms user record whose email matches their identity provider account. Users without a match cannot sign in.
Before you begin
-
Administrator access to your identity provider.
-
GlobalForms running over HTTPS, with its public address set in
domain. See Configuring HTTPS. -
Access to
config\local.jsonon the GlobalForms server. -
A GlobalForms user resource containing your users' email addresses.
Step 1: Register GlobalForms with your identity provider
In your identity provider's admin console, create an application with these settings. The provider guides above show the exact steps.
|
Setting |
Value |
|---|---|
|
Application type |
OpenID Connect, Web application |
|
Sign-in redirect URI |
|
|
Scopes |
|
When the application is created, record its client ID, client secret and issuer URL.
Issuer URL by provider
|
Provider |
Issuer URL |
|---|---|
|
Microsoft Entra ID |
|
|
Okta |
|
|
Duo |
Shown in the application's Metadata section in the Duo Admin Panel |
|
|
|
Step 2: Configure GlobalForms
-
Add an
oidcsection toconfig\local.json:JSON{ "oidc": { "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0", "clientId": "<Client ID>", "clientSecret": "<Client secret>", "redirectUrl": "https://forms.example.com/oidc/callback" } } -
Restart the GlobalForms service.
|
Setting |
Default |
Description |
|---|---|---|
|
|
(blank) |
Required. The provider's issuer URL. Single sign-on is off while this is blank. |
|
|
(blank) |
Required. The client ID from your provider |
|
|
(blank) |
The client secret from your provider |
|
|
|
Required. Must exactly match the redirect URI registered with the provider |
|
|
|
Scopes requested from the provider |
|
|
|
The value from the provider used to identify the user. If the provider doesn't send it, GlobalForms uses the provider's username ( |
|
|
|
The field in your GlobalForms user records that must match |
|
|
(blank) |
Optional. For example, |
|
|
(blank) |
Optional. Where to send users after sign-in. If blank, users return to GlobalForms. |
|
|
|
Seconds a user has to finish signing in at the provider (minimum 60) |
|
|
|
How the provider returns results. Leave as |
Step 3: Add the sign-on button to the sign-in page
The GlobalForms sign-in page shows the User Login form (path user/login). Add the single sign-on button to that form. A sign-on button on any other form doesn't start sign-in; to start sign-in from elsewhere, use a link (see Starting sign-in from a link).
-
Open the User Login form and select the Edit Form tab.
-
Add a Button component labeled, for example, Sign in with Microsoft.
-
On the button's Display tab, set Action to Submit, and in Button Custom Logic enter:
data.name="oidc"; data.password="oidc"; data.oidc=trueThis fills the required Name and Password fields with placeholders, so the button can submit, and marks the submission as a single sign-on request.
-
On the button's API tab, set Property Name to
oidc. Save the component, then save the form. -
Select the Form Actions tab and add the OIDC Login action:
-
Resources: the user resource or resources that hold your users.
-
Trigger this action only if field: choose your sign-on button, then Equals, and enter
true.
-
-
Edit the existing Login action. Under Trigger this action only if field, choose the sign-on button, then Not Equal, and enter
true. This keeps name-and-password sign-in working alongside single sign-on. -
Save each action.
Test in a private browser window before signing out. If the Login action's condition is wrong, users, including administrators, may be unable to sign in with a name and password.
Step 4: Test
-
Open the GlobalForms sign-in page in a private browser window.
-
Select the single sign-on button and sign in at your provider.
-
Confirm you return to GlobalForms signed in as the matching user.
-
Also confirm that signing in with a name and password still works.
Starting sign-in from a link
You can also start single sign-on from a link, for example on a portal page:
https://forms.example.com/oidc?returnUrl=https://forms.example.com/view/%23!/form/<form ID>
|
Parameter |
Description |
|---|---|
|
|
Optional. Comma-separated IDs of the user resources to search. If omitted, GlobalForms uses the |
|
|
Optional. Where to go after sign-in. GlobalForms adds the sign-in token to this address. Encode |
|
|
Optional. The user's email, to pre-fill the provider's sign-in page |
Troubleshooting
|
Message or symptom |
Cause and fix |
|---|---|
|
Selecting the sign-on button shows "Submission was created." or a name/password error |
The button isn't on the User Login form, its property name isn't |
|
|
|
|
The provider shows a redirect URI error |
|
|
|
No GlobalForms user record has that email in the selected resources. Create or correct the user record, or check |
|
|
No user resource is selected in the OIDC Login action, and none could be found otherwise. |
|
|
The user took longer than |
|
|
The provider did not return an email address. Make sure the |
Each provider guide has a troubleshooting table for that provider's own error messages.