Hi Michael, We primarily followed the GitLab documentation from the following links:
1. http://doc.gitlab.com/ce/integration/omniauth.html 2. http://doc.gitlab.com/ce/integration/saml.html Both of the links describe configuration settings that we applied by editing the gitlab.rb file, as we are using an omnibus installation. The first link describes general OmniAuth settings that apply regardless of the OmniAuth provider being used. The second link describes settings specific to SAML OmniAuth providers. For the SAML-specific configuration, we worked with an Active Directory (AD) administrator to identify the values for the idp_cert_fingerprint and idp_sso_target_url configuration settings. We also provided the AD admin with the "metadata URL for the application to provide configuration information to the IdP" (described in the documentation), and I believe that he used this to import GitLab configuration data into AD. However, exactly what the AD admin did on his side remains unclear to me, so I'm not sure that this point is accurate. Our initial attempts to login to the GitLab UI using the SAML sign-in button failed, so we proceeded via trial and error, working with the AD admin and adjusting the configuration on both sides. We ultimately settled on a name_identifier_format configuration value of 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', but I'm not sure how significant that setting is - I think that the configuration that ultimately did the trick was when the AD admin specifically configured AD to "provide a claim containing the user's email address, using claim name 'email' or 'mail'". I'm obviously hazy on how this all works, so all of the above should be taken with a grain of salt. Nevertheless, the links above may be where you want to start. Josh On Monday, September 21, 2015 at 12:02:57 PM UTC-4, Michael wrote: > > Hi Josh, > > Can you provide any details on how you managed to get SAML working with > GitLab. > > On Thursday, September 10, 2015 at 7:47:21 AM UTC-5, jjw.n...@gmail.com > wrote: >> >> Hi, >> >> I'm in the process of altering a 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 have a question, however, on 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. >> clone, push, ...) using their LDAP usernames and passwords, but users with >> accounts created via a SAML sign-in cannot. >> >> Based on a bit of exploration, it looks like we might need to set a >> separate GitLab account password after the SAML interaction which causes >> the GitLab account to be created - we've deduced this from a message that >> appears 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'. >> >> My question is whether setting and maintaining this separate password is >> truly necessary, or if we have instead misconfigured the SAML integration. >> >> I'm very hazy on precisely what's going on behind the scenes with respect >> to account management and synchronization, so any pointers or >> clarifications would be appreciated. >> >> Thanks, >> Josh >> >> -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to gitlabhq+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/47aa9e1d-fd0d-4cfd-944c-cfadb6e005d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
