I am in the process of altering an existing GitLab
installation to use SAML
rather than LDAP
for authentication.
At this point, users can successfully sign into the Web application using the 'Sign in with Saml' button. I am unclear, however, about what seems to be a difference between the LDAP and SAML approaches: users with accounts created via an LDAP sign-in can then access Git repositories (e.g. using clone, push, ...) using their LDAP usernames and passwords, but users with accounts created via a SAML sign-in cannot.
Through experimentation, I’ve found that users can access the Git repositories if they use the GitLab UI to set a separate GitLab account password on the account that is created during the initial SAML
interaction. I was pointed in this direction by a GitLab message that appeared after creating a project under one of the new user accounts: 'You won't be able to pull or push project code via HTTPS until you set a password on your account'.
It seems possible that this separate password configuration is only necessary because I’ve misconfigured the SAML integration somehow. So, my question is whether I am wrong to expect that authenticating access to the GitLab-hosted Git repositories would work the same regardless of whether SAML
or LDAP
is used? If not, does anyone know of relevant SAML configuration settings that I should review?
In case it’s of interest: I have posted a similar question to the GitLab Google
group, but I have not received any responses there yet.
In Windows Active Directory (AD) environments, SAML SSO can allow employees to access a wide range of applications using only their AD credentials. On-premises AD users can continue to use a centralized identity source (AD) for access to cloud apps like Microsoft 365.
GitLab can be configured to act as a SAML 2.0 Service Provider (SP). This allows GitLab to consume assertions from a SAML 2.0 Identity Provider (which is Advanced Authentication here). First configure SAML 2.0 support in GitLab, then register the GitLab application in the Identity Provider (IdP).
SAML is an XML-based authentication protocol in which Identity Providers (IdP) -- entities that manage and store user credentials -- exchange digitally signed XML documents (SAML Assertions) allowing an end-user to access a Service Provider (SP), such as the collection of apps that you use every day at work or a web ...
SAML itself doesn't perform the authentication but rather communicates the assertion data. It works in conjunction with LDAP, Active Directory, or another authentication authority, facilitating the link between access authorization and LDAP authentication.
This is an old question, but I'm responding anyway in hopes it helps someone else who stumbles upon this question.
An important distinction between LDAP and SAML is that SAML is a web-based single sign on technology. Part of the SAML sign in process happens between the user's client (browser) and the SAML server directly and then GitLab verifies that information on the backend. In contrast, when given a user's LDAP password GitLab can connect directly to the LDAP server and verify the identity.
Many GitLab users utilize a combination of LDAP and SAML. SAML provides seamless single sign-on for the web side while LDAP allows Git over HTTPS to accept passwords and also opens the door to advanced features like LDAP Group Sync in Enterprise Edition.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With