How Keycloak and GitLab SSO integration works for self-managed instances
For a self-managed GitLab instance, the supported method for signing in with Keycloak is OpenID Connect, with Keycloak as the identity provider and GitLab as the relying party. The goal is for developers to authenticate with the identity provider your organization already operates, without maintaining a separate GitLab password for each person. Keycloak keeps ownership of credentials, multi-factor methods and account disablement, so someone removed from the directory loses the sign-in path. GitLab still decides what each signed-in account can do inside groups and projects. Plan roles with that split in mind, because a successful login does not by itself grant access to any repository.
The sign-in flow has four steps that matter to your planning. A developer selects the Keycloak option on the GitLab sign-in page, and the browser is redirected to the authorization endpoint of the Keycloak realm you configured. Keycloak authenticates the user with whatever methods that realm requires, then sends the browser back to GitLab's callback address with a short-lived authorization code. GitLab then calls the Keycloak token endpoint directly from the server, receives an ID token, and verifies its signature and claims before it creates or matches the local account. Because the code exchange happens server to server, the client secret and the callback address are the two values that most often break a first attempt.
This page centers on the GitLab-side configuration: the OpenID Connect provider block in GitLab's configuration, the issuer and client values copied from Keycloak, the callback address, and how GitLab maps the claims it receives to a user identity. The Keycloak side is a confidential client in the realm used for workforce sign-in, with its redirect URI registered exactly as GitLab expects it. Two GitLab requirements shape that work. GitLab documents HTTPS for the instance and for the identity provider endpoints, and it documents RS256 as the signing algorithm for the tokens it validates. Confirm both against GitLab's current documentation for your installed version before you change anything, because requirements of this kind can change between releases.
Do not confuse this integration with the Keycloak social provider for GitLab. That feature lets Keycloak accept GitLab accounts as a login source for users held in Keycloak. It runs in the opposite direction and does not make GitLab sign users in. If your goal is developers signing in to GitLab, the provider configuration belongs on the GitLab instance and the client belongs in Keycloak. Before you schedule the work, decide which realm holds developer accounts, who owns the client secret, and how you will test sign-in with a non-administrator account, because the first failure often appears only when an ordinary user tries it.
What to prepare before connecting Keycloak to GitLab
Most failed GitLab sign-in attempts trace back to a gap in one of these six areas before the OpenID Connect settings are even reached. Work through them on both sides before anyone edits configuration, and record the hostnames, versions and owners you confirm so the integration can be repeated and audited.
Supported Keycloak release on TLS
Start with a Keycloak release you can keep patched. The current release is 26.8.1, and its upgrade notes should be read before deployment. Serve Keycloak over TLS on a dedicated hostname that both the user's browser and GitLab's back-channel requests can reach. Confirm that this hostname matches the issuer URL you will give GitLab, because a mismatch causes token validation to fail.
Self-managed GitLab version and HTTPS
This integration targets a self-managed GitLab instance that your team controls. Record the exact GitLab version you run and confirm the OpenID Connect settings for that version in GitLab's documentation, since option names and behavior can change between releases. Check that the instance is served over HTTPS with a correct external URL, and plan upgrades so a later GitLab release does not silently break sign-in.
Certificate trust between both services
GitLab must trust the certificate that Keycloak presents, and Keycloak must trust the certificate GitLab presents on its callback URL. If either service uses an internal certificate authority, install that root certificate on the GitLab host and in the Keycloak trust configuration, then confirm the full chain is complete. Expired certificates and untrusted self-signed certificates are a common cause of failed token exchanges during the first test.
Network paths to the discovery endpoint
GitLab fetches Keycloak's OpenID Connect discovery document from the realm's well-known configuration URL, then calls the token and key endpoints directly from its server. Confirm that the GitLab host can resolve and reach that hostname over HTTPS, and that firewalls, proxies and DNS views allow these back-channel calls. Test the browser path separately from a user workstation, since the login redirect depends on it.
Administrator access on both sides
Configuring the client requires a Keycloak realm administrator who can create a client, define client scopes and mappers, and read the client secret. Editing GitLab's OpenID Connect provider settings requires GitLab administrator access, and file-based changes need server access plus a reconfigure step after they are applied. Agree who holds each role and who approves changes, because the two administrators must exchange the client ID, client secret and redirect URI.
Test user with known group membership
Create a dedicated test user in Keycloak and add it to at least one group you plan to map to GitLab access, plus one group you expect to be denied. Record each group name exactly as it will appear in the token, because mapping errors often come from case or path differences. Keep this account separate from production users and remove it after acceptance testing. Group-based access in GitLab depends on subscription tier, so confirm that feature in GitLab's documentation for your version.
Which Keycloak client and token settings GitLab needs
The first decision is to create a dedicated OpenID Connect client in the Keycloak realm that GitLab will use, and to make it a confidential client. A confidential client has client authentication turned on and holds a client secret, which GitLab stores in its own configuration and presents when it exchanges the authorization code for tokens on the server side. Keep the client separate from other applications so that its secret can be rotated without affecting them, and leave options such as direct access grants off unless GitLab's current documentation requires them. Confirm the client type, the authentication method and the standard flow settings against GitLab's current OpenID Connect documentation before you finalize the client, because GitLab changes how it configures providers across releases. Redirect URI: Keycloak compares the redirect URI that GitLab sends with the valid redirect URIs on the client as an exact match, so a small mismatch produces a login error that looks like a configuration problem elsewhere. Enter the callback path that GitLab's documentation specifies for its OpenID Connect provider, built from the external URL that users actually type in the browser, including the HTTPS scheme, host name and any non-default port. Avoid broad wildcards in production. Use the same host name in GitLab's external URL setting, because a mismatch between the two is one of the most common sources of failed sign-ins.
Scopes control which claims Keycloak places in the tokens that GitLab receives. The openid scope is required for OpenID Connect, and the profile and email scopes supply the name and address attributes GitLab uses to create or match accounts. Keep the default client scopes that GitLab needs assigned to the client and remove any optional scopes that carry data GitLab will not use. Confirm the exact scope list in GitLab's documentation for the version you run, since the set GitLab expects is the authority here, not what Keycloak assigns by default. Group membership is not included in tokens by default. The Keycloak server administration guide documents how protocol mappers attach values to tokens and how client scopes group those mappers, and you can use either approach. A Group Membership mapper that adds a groups claim to the ID token and the userinfo response is the usual choice. Decide whether the claim carries full group paths or short group names, because that choice determines how you match groups to GitLab groups later. Confirm the claim name and the expected format with GitLab's current documentation before you test.
The signing algorithm is a decision point, not a default you can assume. GitLab validates the signature on the ID token, and the documented expectation is RS256, so the team should confirm the algorithm the Keycloak realm uses to sign tokens in the realm's keys and token settings. Confirm which key GitLab validates against as well: GitLab can read the realm's published keys through the discovery document, or it can be configured with a specific public key. If you use discovery, the key set must contain the RS256 key that signs the tokens, and any key rotation in the realm must be reflected in what GitLab fetches. If you pin a key, a rotation will break sign-in until the configuration is updated. Verify these decisions before users depend on the integration. In a test realm, sign in once, inspect the ID token header and confirm the algorithm, then check that the groups claim appears with the name and format you chose. Record the client settings, mapper configuration and key source in your change records so that a later Keycloak upgrade or key rotation can be checked against them.
Configuring Keycloak and GitLab SSO step by step
This sequence takes a self-managed GitLab instance from a Keycloak realm with no GitLab client to a tested sign-in path that creates the user account and identity link. Each step ends with a check you can run before moving on, so problems surface in the step that caused them. Use separate test accounts for every check, and keep them out of production groups.
Confirm Keycloak is reachable over HTTPS
The integration requires Keycloak served over HTTPS at the hostname GitLab will use to reach it. The platform team owns this step. Open the realm's OpenID discovery document, the well-known configuration endpoint for the realm, from a machine on the GitLab network and from a browser. Confirm it loads without certificate warnings and that the issuer value in the document matches the issuer URL you plan to give GitLab. Do not proceed until both checks pass, because a hostname or certificate mismatch causes many later sign-in failures.
Create a confidential client for GitLab
In the Keycloak admin console, create an OpenID Connect client in the target realm and turn client authentication on so the client is confidential. Register the exact callback URI for your GitLab instance, including the scheme, hostname and path that GitLab's current documentation specifies. Store the client secret in your secrets manager and keep it out of tickets and chat. Check that the client settings show the callback URI you entered and that an administrator can retrieve the secret from the secrets manager.
Add a groups mapper and check the token
Add a mapper to the client that places the user's group memberships into a groups claim, and confirm the claim name matches what GitLab's documentation expects for group handling. Sign in to the realm as a test user who belongs to at least one group, then request a token for the client through the admin console's client evaluation tools or an OAuth test request. Decode the token and confirm the groups claim lists the expected group paths. If the claim is absent, review the mapper's token claim settings before continuing.
Confirm the token signing algorithm is RS256
GitLab's documented OpenID Connect setup expects tokens signed with RS256, so set the client's signing algorithm to match and confirm the realm has an active RSA key for signing. Decode the test token header and check that the alg value reads RS256. Also confirm the discovery document lists RS256 among its supported signing algorithms. If the header shows another algorithm, correct the client setting and request a new token, since an older token keeps the previous algorithm.
Add the OpenID Connect provider block to GitLab
On the GitLab host, open the instance configuration file where OmniAuth providers are defined and add an OpenID Connect provider block. Enter the Keycloak issuer URL for the realm, the client ID, the client secret and the redirect settings described in GitLab's documentation. Copy the exact key names from GitLab's current documentation for your version, since older examples online may use outdated keys. Keep the secret out of version control and confirm the file is readable only by the account that runs GitLab.
Reconfigure GitLab using its documented procedure
Apply the change with the reconfigure procedure GitLab documents for your installation method, such as the Omnibus reconfigure command or the equivalent for your deployment. Watch the command output for errors about the provider block, and review the GitLab logs if the run finishes with warnings. Then open the GitLab sign-in page and confirm a Keycloak option appears alongside the standard login form. The step is done when the option is visible and the reconfigure run reports no errors.
Test sign-in and the identity link
Sign in through Keycloak with a test user who has never signed in to this GitLab instance. Confirm GitLab creates the user account with the expected username and email, and that the account's identity settings show a link to the Keycloak provider. Check the group membership you planned, and confirm which group-based features your edition supports by reading GitLab's current feature documentation, since some group features depend on GitLab Premium. Sign out, sign in again, and confirm the same account is reused and no duplicate is created.
Mapping Keycloak users, groups and claims to GitLab access
This table compares each Keycloak field GitLab reads at sign-in with the GitLab account attribute or access level it drives. Read each row as a decision point: the token claim you configure in Keycloak determines what GitLab sees. The main takeaway is that the group model you choose up front decides how much manual administration remains after go-live, so confirm each row against GitLab's current group sync documentation for your installed tier before you build.
| Keycloak source | GitLab account attribute or access | Decision and confirmation point |
|---|---|---|
| Username or email claim | GitLab username and primary email used to match or create the account | Choose one stable claim and confirm the attribute GitLab expects for your OIDC setup and whether email-based account linking is enabled |
| Display name claim | GitLab full name shown on profile, commits and review activity | Map from the name claim in the ID token; confirm which claims GitLab reads for name fields in its OmniAuth OIDC documentation |
| Groups claim (group membership) | Membership in GitLab groups at a chosen access level, if group sync is enabled | Add a groups mapper to the client; confirm the claim format and path GitLab expects for group sync on your tier |
| Keycloak group named one per GitLab group | One-to-one membership; each Keycloak group maps to one GitLab group and role | Lowest design effort but creates many groups to maintain as teams change; confirm sync behavior for nested groups |
| Role model (client or realm roles) | Access level assigned from a small set of roles such as developer or maintainer | Fewer Keycloak objects to administer; confirm how GitLab maps role-like claims to access levels and which features need Premium |
| Realm roles (if used) | Only relevant if your mapping uses them as a claim source; GitLab does not read them directly | Include them only if they feed the groups claim through a mapper; confirm the claim path before relying on them |
| Account lifecycle in Keycloak | Account blocked or removed when the user is disabled or leaves the group | Test disable and removal flows; confirm how GitLab handles sync removals and existing users created before SSO |
Which GitLab group features need GitLab Premium
Some group-based access features in GitLab depend on the subscription tier, and the source requirement for this integration is that certain group features need GitLab Premium. Before you design the Keycloak to GitLab group mapping, confirm the exact feature list against GitLab's current feature and pricing pages for your deployment type. Tiers and feature placement change between releases, so check the pages on the day you make the decision, not from memory or from an earlier project.
The design consequence is direct. If your tier does not include the group features you need, Keycloak can still send a groups claim at sign-in, but GitLab may not turn that claim into group membership automatically. In that case, group membership has to be managed by hand or through a scripted process that calls the GitLab API. Each joiner, mover and leaver then needs an administrative step, and a missed step leaves someone with access they should not have or without access they need.
Map the decision to your access model before you commit. List the access outcomes the business needs, such as who can administer a group, who can approve merges into protected projects, and how quickly removing a Keycloak group must remove GitLab access. For each outcome, note whether the tier supports it natively or whether a script must cover it. Ask the GitLab account team or your reseller to confirm any feature you cannot verify on the public pages, and get that answer in writing.
Record the tier decision in the scope document. Name the GitLab tier, the features checked, the date of the check, and the person who owns the manual or scripted process after go-live. Include the admin effort that process creates, and ask for it to be priced in any quote, because it recurs for as long as the tier stays the same. Add a review trigger for tier changes, GitLab pricing changes and any Keycloak group model change, so the decision is revisited before it quietly stops matching the platform.
Hardening the Keycloak to GitLab sign-in path
This section covers the controls that protect the sign-in path between Keycloak and GitLab, from transport security to who can reach the admin console and who can sign in. Each card names a decision or check your team can record before go-live and repeat after upgrades, certificate changes or hostname changes.
TLS on every hop
Keycloak's production guide calls for TLS on all communication, so the browser, the reverse proxy, Keycloak and the GitLab server each need certificates that their clients trust. Check the issuer URL GitLab uses for discovery, along with the token and JWKS endpoints, because GitLab fetches these over HTTPS and fails when a certificate chain is untrusted. Confirm that any internal CA bundle is installed where GitLab can read it, and confirm that no hop falls back to plain HTTP.
Separate admin and public endpoints
Keycloak's production guide recommends exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Configure the reverse proxy to serve only the paths that sign-in needs for the GitLab client, and block the admin paths from outside your network. Test this with a request from outside the network to an admin path, which should fail, and confirm that GitLab's redirect and discovery URLs point only at the public hostname.
Client secret storage and rotation
GitLab's Keycloak client uses a client secret during the code exchange, so the secret belongs in a secrets store or a protected configuration file on the GitLab host and stays out of version control. Record who holds the secret and set a rotation schedule that your security policy requires. Rehearse the change in a test environment, because the new secret must reach GitLab before the old one stops working, or sign-in fails for every user. Confirm with your team how long that window takes in your setup.
Tight redirect URI lists
Register each exact GitLab callback URL in the Keycloak client, and avoid wildcard patterns that match other paths or hosts on the same domain. Keep only the production URL and any staging URL you actively run, and remove leftover entries from earlier test installs. Review the list after every GitLab hostname change, because a stale entry is a location where an authorization code could be sent to a host you do not control.
Backchannel logout token validation
The Keycloak 26.8 upgrade notes make signature validation mandatory for backchannel logout tokens from external providers. If your realm brokers an external identity provider, confirm that its signing keys are configured in Keycloak before you upgrade, and test logout across the applications that share that broker. Also confirm whether your GitLab sign-in path depends on backchannel logout at all, so you know which tests the upgrade changes.
Limit and verify sign-in access
Restrict GitLab sign-in to a named Keycloak group so that users outside it cannot complete the OpenID Connect flow, even with valid credentials. Review who holds GitLab administrator rights against the same group list, and remove administrator access left over from earlier setups. Then test the result: disable a test user in Keycloak, confirm that GitLab sign-in fails for that user, and confirm how long an existing GitLab session stays active under your settings.
Common Keycloak GitLab SSO failures and their causes
This table lists the failures teams most often hit when wiring Keycloak to self-managed GitLab over OpenID Connect, with the likely cause and a check that confirms it. Work through the rows in order, starting with the Keycloak and GitLab logs, because most failures show a clear message there before the browser shows a generic error. Each check is a test you can run without changing production settings first.
| Failure | Likely cause | Check that confirms it |
|---|---|---|
| Redirect URI mismatch | The redirect URI registered in the Keycloak client does not exactly match the callback GitLab sends, often because of http versus https, a missing port, or a trailing slash. | Compare the redirect_uri parameter in the browser's authorization request with the Valid redirect URIs list on the Keycloak client. Check the GitLab log for the callback host it built from external_url. |
| Discovery endpoint unreachable from GitLab | GitLab's server cannot reach the Keycloak realm's .well-known/openid-configuration URL because of DNS, firewall rules, a proxy or a wrong hostname in the issuer setting. | Run curl against the discovery URL from the GitLab host, not from your workstation. Confirm the issuer value in the returned JSON matches the issuer GitLab is configured with. |
| Certificate trust errors on HTTPS | Keycloak is served with a certificate from an internal CA that GitLab's system or Omnibus trust store does not include, or the chain is incomplete. | Run openssl s_client against the Keycloak host from the GitLab server and check the verify return code. Look for x509 or SSL verification errors in the GitLab log. |
| Missing groups claim | The Keycloak client has no groups mapper, or the mapper is not added to the ID token or userinfo response that GitLab reads. | Decode the ID token or call the userinfo endpoint with a test login and check for a groups claim. Confirm the mapper's token claim name matches the claim GitLab expects. |
| Signature validation fails because the algorithm or key does not match | The client or realm signs tokens with an algorithm other than RS256, or GitLab fetched a stale JWKS key set after a key rotation. | Check the token header alg value and the realm's active RS256 key in the Keycloak keys tab. Review the GitLab log for signature or JWKS errors, then confirm the JWKS URI in the discovery document is reachable. |
| Users created without the expected username | The username claim GitLab maps to is absent or uses a different attribute, so GitLab falls back to a generated or email-based name. | Inspect the claims in a test login and confirm the preferred_username or configured claim is present and not empty. Compare the created GitLab account with the Keycloak user's username field. |
| Group access not updating after a Keycloak change | GitLab applies group membership at sign-in, so changes made in Keycloak appear only after the user signs in again, or the group sync feature is unavailable on the GitLab tier in use. | Ask the user to sign out and sign in again, then check whether the groups claim in the new token reflects the change. Confirm group sync is supported on your GitLab edition and plan in GitLab's documentation. |
How to verify Keycloak GitLab SSO before users depend on it
Test the integration end to end before any user is told to sign in with Keycloak. The test plan should be written as part of the change, with each case named, the expected result stated in advance, and the actual result recorded. The expected results should come from the team's written scope and from the GitLab and Keycloak documentation that applies to the versions you have installed. Confirm those versions first, because GitLab's OpenID Connect settings and Keycloak's client and mapper behavior are version dependent, and a result that matches an older document is not proof for the current build. Start with the sign-in paths. Run a first-time sign-in by a Keycloak user who has never had a GitLab account, and confirm that GitLab creates the account with the expected username, email and name, and that it does not create a duplicate. Then run a sign-in by a user who already has a local GitLab account with the same email address, and confirm how GitLab links or refuses the link under your settings. Repeat the sign-in for one user in each target group, confirming that the GitLab group membership and access level match the mapping in your design. Test at least one user who belongs to several groups, since that is where precedence and conflicts show up. Next, test change events. Remove a user from a mapped Keycloak group and sign in again, then confirm that GitLab access is reduced at the next sign-in or sync. Disable the Keycloak account and confirm that new sign-ins fail, and check what happens to an existing GitLab session and to any personal access tokens the user holds. Change the user's password or enroll or replace a passkey in Keycloak, then confirm the sign-in path still works and that the old credential no longer does. If Keycloak runs as a cluster, restart one node and then fail over the service while a sign-in is in progress, and confirm that users see a retry rather than a broken GitLab login. Record each result, the timestamp, the versions tested and the person who ran the test, and store that evidence with the change record so the approver and any later auditor can see what was checked.
Questions teams ask before connecting Keycloak to GitLab
What drives the cost of connecting Keycloak to GitLab?
Scope drives most of the cost. The main inputs are the number of GitLab groups that need their own access levels, the GitLab tier decision, the identity sources Keycloak already federates, and the number of environments that must be configured and tested. Each group adds mapping rules to design, test and document. Existing LDAP or Active Directory federation adds questions about attributes and group claims that must be settled before configuration. Upgrade cadence matters because both Keycloak and GitLab change between releases, so whoever maintains the setup later needs a documented procedure. Design, build and test are one-time costs. Upgrades, testing after changes and support are recurring costs whether you staff them internally or retain a partner. Ask any quote to separate these components and to name who performs each task.
Can our own team connect Keycloak to GitLab without a partner?
Yes, if your team holds Keycloak realm admin rights, has GitLab administrator skills and has a non-production environment to test in. The work touches both sides: a confidential OpenID Connect client in Keycloak, a GitLab configuration that uses OpenID Connect for sign-in, and group mapping on each side. Confirm that GitLab is served over HTTPS with a certificate both systems trust, and that Keycloak signs tokens with RS256, which is the signing algorithm GitLab documents. Most problems appear during testing, usually as redirect URI mismatches, missing group claims or certificate chain errors. Teams without a test environment should build one first. If any of these skills are thin, a fixed-scope engagement can cover the build while your staff learn the configuration.
How long does a Keycloak and GitLab SSO integration take?
The duration depends on scope, and the timeline should be agreed in writing before work starts. The variables are the number of environments, the number of groups that need mapping, the current state of your Keycloak realm, whether users come from LDAP or Active Directory federation, and how quickly your team can approve test users and a change window. A single environment with a small group model is simpler than several environments with a detailed group design. Testing time depends on how many sign-in journeys you need to verify, such as first sign-in, group changes and sign-out. Ask for the phases, the entry and exit criteria for each phase, and the dependencies on your side. Most DeployOpen engagements are fixed-scope, so the written scope sets the timeline.
What does our team need to provide before the integration starts?
Plan to provide access, people and decisions before the build starts. Access means a Keycloak account with realm admin rights for the target realm, a GitLab administrator account, and access to the DNS, certificate and reverse proxy settings for both hostnames. People means a few test users in each group that will receive GitLab access, plus someone who can confirm results on each test. Decisions include which Keycloak groups map to which GitLab access levels, how group names are formatted in the token, and who approves changes to either system. You also need a change window in which configuration can be applied and rolled back, and a named contact for Keycloak and for GitLab. Missing any of these usually stalls the work at the testing stage.
Does a GitLab Premium tier decision change the Keycloak design?
It can, so make the tier decision before group mapping is finalized. GitLab documents which group-based features require Premium, and the tier you run determines whether those features are available to your users. Confirm the current list against GitLab's tier comparison and the documentation for your version, because feature placement changes over time. If you stay on a tier without the features you need, design group access with the controls that tier supports and document the gap for your security reviewers. If you upgrade later, plan a configuration review, since group-related settings may need changes. Record the tier decision and its reasons in the scope document so that auditors and future administrators can see why the design looks the way it does.
Which GitLab requirements most often break Keycloak sign-in?
Several requirements can break sign-in even when the Keycloak configuration looks correct. GitLab must be reached over HTTPS, and the redirect URI registered in Keycloak must match the GitLab external URL exactly, including the path and port. The token signing algorithm must be one GitLab accepts, and the requirement GitLab documents is RS256. Clock drift between servers can make tokens appear expired. An internal certificate authority that GitLab does not trust will fail the connection, often with an unclear error in the user interface. The groups claim must be present in the token or the userinfo response, and its values must match the group names expected in GitLab. Check each item in a test environment, and read the logs on both systems when sign-in fails. Confirm current requirements against GitLab's documentation for your version.
How much ongoing work follows go-live for this integration?
Expect recurring work after go-live, driven by release cadence on both sides. Keycloak plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release will be opt-in. Each upgrade still needs testing against your client and mapper configuration. GitLab upgrades need planned upgrade stops and a check that the OpenID Connect settings still work afterward. Set a review cycle, keep the configuration in version control or in a documented export, and retest sign-in and group mapping after each change. Ask whether a support or upgrade retainer would cover these checks, and what it would exclude. DeployOpen offers retainers for ongoing support, upgrades and continuous testing.
What should a quote for this integration list?
A quote should follow from a written scope and state what is included, what is excluded and what you must provide. Ask for the environments covered, the GitLab version and tier assumed, the Keycloak realm and client design, the group mapping rules, and the test cases used to accept the work. List the deliverables, such as configuration, test results, a runbook and a handover session. Separate one-time work from recurring support, and state who performs each task. Include the approach to the change window, the assumptions about existing identity sources, and the dependencies on your team. Confirm how changes to scope are handled during the work and how they affect price and timeline. DeployOpen quotes follow from the written scope, so a precise scope produces a precise quote.
How DeployOpen scopes and delivers Keycloak GitLab SSO
DeployOpen plans, configures and hands over Keycloak and GitLab SSO integration inside your own infrastructure, so GitLab sign-in and group access follow the identity rules your organization already uses. Each engagement starts with a written, fixed scope, and the sign-in flow is verified in a test environment before handover.
How we scope
- A written scope names the GitLab edition, Keycloak realm, client type and group-to-role mappings in scope.
- Scope records which group features need GitLab Premium, so licensing decisions are made before build starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Configure the Keycloak client for OpenID Connect with TLS and the redirect URIs your GitLab hostname uses.
- Set up RS256 token signing and a groups claim, then map Keycloak groups to GitLab access levels.
- Test sign-in, group sync and account linking for existing GitLab users in a non-production instance first.
How we hand over
- Handover documents the Keycloak client settings, claim mappings and GitLab configuration as deployed.
- Runbooks cover certificate renewal, client secret rotation and adding a new group to GitLab access.
- Your team receives a sign-in test checklist to rerun after Keycloak or GitLab upgrades.
How we support
- Ongoing support, upgrades and testing are available as a retainer after handover.
- Keycloak minor upgrades are reviewed against breaking-change notes before the GitLab sign-in flow is retested.
- Confirm during scoping who owns GitLab upgrades, since sign-in breaks if either side changes unnoticed.
