Gluu works with your existing identity provider from day one — no setup required. This guide explains how to tighten access control, connect Microsoft Azure AD or Google Workspace, manage permissions, and keep user data in sync.
What works out of the box #
Every Gluu account comes with four login paths enabled by default. Users can sign in with email and a one-time passcode, email and password, Microsoft account, or Google account — all on the Core plan, with no configuration needed.
So why configure SSO at all? Because the real value comes when you restrict access. Locking users to Microsoft or Google sign-in means Gluu automatically inherits your identity provider’s MFA, conditional access, and offboarding rules. Your IT team stays in control without touching Gluu settings.
Restricting who can log in #
The Authentication panel in your account settings gives you three checkboxes: Gluu login/password, Google auth, and Microsoft auth. Uncheck any method to disable it. Most security-conscious customers uncheck “Gluu login / password” entirely, so every user must authenticate through Microsoft or Google.
This means your IdP’s MFA and conditional-access policies apply automatically. You manage access through your own security stack — Gluu simply honors the decision your identity provider returns.
Lock Microsoft login to your Azure AD tenant #
By default, any Microsoft account can sign in. To restrict login to your own organization, enter your Azure AD Tenant ID in the Authentication panel. This single step also unlocks Office 365 and SharePoint integrations, and enables optional auto-provisioning for new users.
Azure AD App Role gating #
Need an extra layer of control? Gluu supports up to three App Role checkboxes, each mapped to a role you define on the Gluu Enterprise App in your Azure AD tenant. Check more than one and they become AND-combined — a user must hold all checked roles to sign in. This lets you require compound membership like “Gluu Users” AND “Finance Department”.
Per-user login provider overrides #
Running a mixed account with internal employees and external partners? The Custom Authentication Providers panel lets you pin a specific login provider to individual users. Internal staff sign in through Microsoft; external consultants through Google. Besides that, Gluu also supports Okta for organizations standardized on it — contact Customer Success to enable it.
Connecting with Microsoft Azure Active Directory #
Gluu is a 100% Azure-native SaaS application. Therefore, the Azure AD integration is the most natural fit for organizations in the Microsoft ecosystem. When a user clicks “Sign in with Microsoft,” Gluu redirects them to the Microsoft login page. After Microsoft verifies their identity — including any MFA your tenant requires — Gluu trusts the returned token and signs them in.
Most importantly, no separate Gluu password is needed. The user’s existing corporate credentials do the work.
Optional: restricted tenant registration #
Some IT teams prefer to register Gluu as an Enterprise Application in their own Azure AD tenant. This gives direct control over consent, conditional-access policies, and app roles. The process involves registering the app in the Azure Portal, configuring the redirect URI, granting User.Read permissions, and sharing the Tenant ID and Client ID with Gluu’s Customer Success team.
Gluu also supports SAML, available on request for organizations that require it alongside OIDC.
Connecting with Google Workspace #
For organizations on Google Workspace, the flow mirrors Microsoft. Users click “Sign in with Google,” authenticate through their existing corporate account, and Gluu accepts the verified token. No pre-configuration is needed.
Want to prevent personal Google accounts from signing in? Contact Customer Success with your verified domain. Gluu can restrict access to employees with an @yourcompany.com account only — a recommended step for any organization that standardizes on Google Workspace.
Controlling permissions inside Gluu #
Login restriction and permissions inside Gluu are two separate layers. Your identity provider controls who gets in at the door. Gluu permission groups control what those users can see and do once inside.
Gluu offers two complementary access models. Process-based access grants users or groups access to specific processes only — ideal for process owners. Role-based permission groups give fine-grained control across the entire platform for every user type from Admin to Read-Only Viewer.
Because these are assigned inside Gluu by an administrator (or in bulk via the REST API), they are not synced live from Azure AD or Google. The best practice is to use Azure AD app roles as a first-pass access gate, then use Gluu permission groups to set the right level of access once users are inside.
How users get created #
By default, a user must exist in Gluu before they can sign in. There are three standard ways to create users: an admin invites them one-by-one (Core plan), a bulk invite from the Gluu UI (Essential plan), or a Customer Success bulk import using a structured data template — the fastest option for large organizations.
When the Azure AD Tenant ID is configured, Gluu can also auto-create a user record on first Microsoft login. Name and email are taken from the Microsoft profile. Combine this with App Role gating to limit auto-creation to a specific group — for example, only members of the “Gluu Users” AD group are auto-provisioned.
How offboarded users are blocked #
Offboarding is handled at the identity provider level. When an employee leaves, your IT team disables or deletes their account in Azure AD or Google Workspace. From that moment, their authentication token is no longer valid, and Gluu rejects any login attempt automatically. No action is needed inside Gluu.
This is the core security advantage of SSO over standalone credentials. One offboarding action in your HR or IT system cascades to every connected application immediately. Gluu administrators can also manually deactivate users directly, and when a user is deleted from the Gluu account, their personal data is anonymized in line with GDPR.
Importing and maintaining user data via the API #
Gluu exposes an open REST API for programmatically managing users and profile fields. This is especially useful during initial rollout and for keeping Gluu in sync with your HR system on an ongoing basis.
Common patterns include a nightly sync from your HR database that updates job titles and departments, a webhook triggered when an employee joins or moves internally, and periodic imports from a CMDB to keep roles current. The API is token-based and works alongside Azure Logic Apps, Power Automate, or any REST-capable middleware.
SCIM support for standards-based provisioning from Azure AD or any SCIM-capable directory is on the Gluu roadmap. Contact Customer Success for current availability.
FAQ – Single Sign-On (SSO) Configuration Guide for Gluu #
No. Microsoft and Google sign-in buttons are available in every Gluu account from day one. Configuration is only needed when you want to restrict who can log in or make Gluu inherit your IdP’s MFA and conditional-access policies.
Enter your Azure AD Tenant ID in the Authentication panel under your Gluu account settings. This locks Microsoft sign-in to accounts within your tenant and also unlocks integrations like Office 365 and SharePoint.
Azure AD app roles control who is allowed to sign in — they act as a login gate. Gluu permission groups control what users can see and do once they are inside Gluu. They are complementary layers, not substitutes for each other.
Gluu automatically blocks the user from signing in because their authentication token from the identity provider is no longer valid. No action is required inside Gluu itself — offboarding in your IdP immediately cascades to Gluu access.
Yes, when an Azure AD Tenant ID is configured on your account, Gluu can auto-create a user record on first Microsoft login using the person’s name and email from their Microsoft profile. This behavior is off by default and can be combined with App Role gating to limit auto-provisioning to specific groups.
