• 지원되는 제공 업체
• 일반 설정 구성
  • 초기 설정 구성
  • 공급자별 구성
  • OmniAuth를 통해 생성된 사용자의 비밀번호
• 기존 사용자를 위해 OmniAuth 활성화
• OmniAuth 공급자로의 로그인을 활성화 또는 비활성화하십시오
• OmniAuth를 비활성화
• 기존 사용자와 OmniAuth 사용자 연결
• 외부 제공자 목록 작성
• 사용자 정의 OmniAuth 제공자 사용
  • 사용자 정의 OmniAuth 제공자 예시
• OmniAuth 사용자 프로필 최신 유지
• 이중 인증 우회
• 제공자 자동 로그인
• 커스텀 OmniAuth 제공업체 아이콘 사용
• 앱 또는 구성 변경
• 알려진 문제

OmniAuth

사용자는 Twitter, GitHub 및 기타 인기있는 서비스의 자격 증명을 사용하여 GitLab에 로그인할 수 있습니다. OmniAuth는 GitLab이 이 인증을 제공하기 위해 사용하는 Rack 프레임워크입니다.

구성된 경우 로그인 페이지에 추가 로그인 옵션이 표시됩니다.

지원되는 제공 업체

GitLab은 다음 OmniAuth 제공 업체를 지원합니다.

일반 설정 구성

OmniAuth 제공 엷을 구성하기 전에, 모든 제공 엷에 대해 공통으로 설정해야 하는 값을 구성하십시오.

초기 설정 구성

OmniAuth 설정을 변경하려면:

이러한 설정을 구성한 후 선택한 제공 엷을 구성할 수 있습니다.

공급자별 구성

• GitLab 15.3에서 소개되었습니다.

allow_single_sign_on이 설정된 경우 GitLab은 사용자가 로그인할 때 OmniAuth auth_hash에서 반환된 다음 필드 중 하나를 사용하여 GitLab의 사용자 이름을 설정합니다. 그 중에서도 먼저 존재하는 것을 선택합니다: - username. - nickname. - email.

당신은 args를 사용하여 공급자별로 GitLab 구성을 생성할 수 있으며, 이는 지원되는 공급자에 supplier를 사용하여 제공됩니다. 공급자에 대한args 변수에서 gitlab_username_claim를 설정하면 GitLab 사용자 이름을 사용할 다른 클레임을 선택할 수 있습니다. 충돌을 피하기 위해 선택한 클레임은 고유해야 합니다.

gitlab_rails['omniauth_providers'] = [

  # 공급자 이름이 PROVIDER_NAME인 공급자를 구성하는 일반적인 패턴

  gitlab_rails['omniauth_providers'] = {
    name: "PROVIDER_NAME"
    ...
    args: { gitlab_username_claim: 'sub' } # 공급자로 로그인하는 사용자를 위해 GitLab 사용자 이름은 공급자에서받은 "sub"로 설정됩니다
  },

  # GitHub 및 Kerberos에 대한 예제

  gitlab_rails['omniauth_providers'] = {
    name: "github"
    ...
    args: { gitlab_username_claim: 'name' } # GitHub로 로그인한 사용자의 경우, GitLab 사용자 이름은 GitHub에서 받은 "name"으로 설정됩니다.
  },
  {
    name: "kerberos"
    ...
    args: { gitlab_username_claim: 'uid' } # Kerberos로 로그인한 사용자의 경우, GitLab 사용자 이름은 Kerberos에서 받은 "uid"으로 설정됩니다.
  },
]

- { name: 'PROVIDER_NAME',
  ...
  args: { gitlab_username_claim: 'sub' }
}
- { name: 'github',
  ...
  args: { gitlab_username_claim: 'name' }
}
- { name: 'kerberos',
  ...
  args: { gitlab_username_claim: 'uid' }
}

OmniAuth를 통해 생성된 사용자의 비밀번호

통합 인증 방법으로 생성된 사용자의 생성된 패스워드 가이드를 통해 GitLab이 OmniAuth로 생성된 사용자를 위해 어떻게 비밀번호를 생성하고 설정하는지 알아볼 수 있습니다.

기존 사용자를 위해 OmniAuth 활성화

기존 사용자라면 GitLab 계정이 생성된 후 OmniAuth 공급자를 활성화할 수 있습니다. 예를 들어, 원래 LDAP로 로그인 했다면 Twitter와 같은 OmniAuth 공급자를 활성화할 수 있습니다.

1. GitLab 계정으로 로그인하십시오. (GitLab 자격 증명, LDAP 또는 다른 OmniAuth 공급자로)
2. 왼쪽 사이드바에서 아바타를 선택하십시오.
3. 프로필 편집을 선택하십시오.
4. 왼쪽 사이드바에서 계정을 선택하십시오.
5. 연결된 계정 섹션에서 Twitter와 같은 OmniAuth 공급자를 선택하십시오.
6. 해당 공급자로 리디렉션됩니다. GitLab을 인가한 후에 GitLab으로 리디렉션됩니다.

이제 선택한 OmniAuth 공급자를 사용하여 GitLab에 로그인할 수 있습니다.

OmniAuth 공급자로의 로그인을 활성화 또는 비활성화하십시오

관리자는 특정 OmniAuth 공급자에 대해 로그인을 활성화 또는 비활성화할 수 있습니다.

참고: 기본적으로 config/gitlab.yml에서 구성된 모든 OAuth 공급자를 위해 로그인이 활성화되어 있습니다.

OmniAuth 공급자를 활성화 또는 비활성화하려면:

1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택하십시오.
2. 설정 > 일반을 선택하십시오.
3. 로그인 제한을 확장하십시오.
4. 활성화된 OAuth 인증 공급원 섹션에서 각 공급자에 대한 확인란을 선택 또는 선택해제하십시오.

OmniAuth를 비활성화

OmniAuth는 기본적으로 활성화되어 있습니다. 그러나, OmniAuth는 공급자가 구성되어 있고 활성화되어 있는 경우에만 작동합니다.

개별적으로 비활성화되어도 OmniAuth 공급자가 문제를 발생시킬 경우, 구성 파일을 수정하여 전체 OmniAuth 서브시스템을 비활성화할 수 있습니다.

gitlab_rails['omniauth_enabled'] = false

omniauth:
  enabled: false

기존 사용자와 OmniAuth 사용자 연결

• GitLab 13.4에서 소개되었습니다.

이메일 주소가 일치하는 경우 OmniAuth 사용자를 기존 GitLab 사용자와 자동으로 연결할 수 있습니다.

다음 예제는 OpenID Connect 공급자 및 Twitter OAuth 공급자를 위해 자동 연결을 활성화합니다.

gitlab_rails['omniauth_auto_link_user'] = ["openid_connect", "twitter"]

omniauth:
  auto_link_user: ["openid_connect", "twitter"]

자동 연결을 활성화하는 이 방법은 모든 공급자에 대해 작동하지만, SAML을 제외한 모든 공급자에 대해 작동합니다. SAML에 대한 자동 연결을 활성화하려면 SAML 설정 지침을 참조하십시오.

외부 제공자 목록 작성

외부 OmniAuth 제공자 목록을 정의할 수 있습니다. 나열된 제공자를 통해 GitLab에 계정을 생성하거나 로그인하는 사용자들은 내부 프로젝트에 액세스할 수 없으며 외부 사용자로 표시됩니다.

외부 제공자 목록을 정의하려면 제공자의 전체 이름을 사용하세요. 예를 들어 Google의 경우 google_oauth2를 사용합니다. 제공자 이름은 지원되는 제공자 테이블의 OmniAuth 제공자 이름 열을 참조하세요.

참고: 외부 OmniAuth 제공자 목록에서 OmniAuth 제공자를 제거하는 경우 이 로그인 방법을 사용하는 사용자의 계정을 수동으로 업그레이드하여야 합니다.

gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']

omniauth:
  external_providers: ['twitter', 'google_oauth2']

사용자 정의 OmniAuth 제공자 사용

참고: 다음 정보는 자체 컴파일된 설치에만 적용됩니다.

GitLab에 포함된 OmniAuth 제공자 이외의 인증 솔루션과 통합해야 하는 경우 사용자 정의 OmniAuth 제공자를 사용할 수 있습니다.

이 단계들은 일반적인 단계입니다. 구체적인 구현 세부 정보는 OmniAuth 제공자의 문서를 참조하세요.

1. GitLab을 중지합니다:

   sudo service gitlab stop
   

2. Gemfile에 젬을 추가합니다:

   gem "omniauth-your-auth-provider"
   

3. 새로운 OmniAuth 제공자 젬을 설치합니다:

   sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
   

   이 명령어들은 --path vendor/bundle --no-deployment 대신에 --deployment를 사용하여 초기 설치 시 젬 설치 명령어와 동일합니다.

4. GitLab을 시작합니다:

   sudo service gitlab start
   

사용자 정의 OmniAuth 제공자 예시

이미 GitLab에 통합되어 있지 않은 제공자를 성공적으로 설정한 경우 알려주세요.

우리는 모든 가능한 인증 메커니즘을 공식적으로 지원할 수는 없지만, 특정한 요구사항을 가진 사용자들에게는 도움을 주고 싶습니다.

OmniAuth 사용자 프로필 최신 유지

선택한 OmniAuth 제공자로부터 프로필 동기화를 활성화할 수 있습니다. 다음과 같은 사용자 속성들 중에서 어떤 조합이든 동기화할 수 있습니다:

• name
• email
• location

LDAP을 사용하여 인증하는 경우 사용자 이름과 이메일은 항상 동기화됩니다.

gitlab_rails['omniauth_sync_profile_from_provider'] = ['twitter', 'google_oauth2']
gitlab_rails['omniauth_sync_profile_attributes'] = ['name', 'email', 'location']

omniauth:
  sync_profile_from_provider: ['twitter', 'google_oauth2']
  sync_profile_attributes: ['email', 'location']

이중 인증 우회

• GitLab 12.3에서 소개되었습니다.

특정 OmniAuth 제공자를 통해 사용자는 이중 인증을 사용하지 않고 로그인할 수 있습니다.

알려진 문제 때문에 사용자는 GitLab에 로그인할 때 이중 인증 설정을 해야 합니다. 그렇지 않으면 GitLab에 로그인할 때 이중 인증 설정을 하라는 메시지가 표시됩니다.

이중 인증 우회를 위해 다음 중 하나를 수행할 수 있습니다:

• 배열을 사용하여 허용된 제공자를 정의합니다 (예: ['twitter', 'google_oauth2']).
• 모든 제공자를 허용하려면 true를, 허용하지 않으려면 false를 지정하세요.

이 옵션은 이미 2FA를 적용한 제공자에 대해서만 구성해야 합니다. 기본값은 false입니다.

이 설정은 SAML에는 적용되지 않습니다.

gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']

omniauth:
  allow_bypass_two_factor: ['twitter', 'google_oauth2']

제공자 자동 로그인

GitLab 구성에 auto_sign_in_with_provider 설정을 추가하여 로그인 요청을 OmniAuth 제공자로 리디렉트하여 인증합니다. 이를 통해 로그인하기 전에 제공자를 선택할 필요가 없어집니다.

예를 들어, Azure v2 통합의 자동 로그인을 활성화하려면:

gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'azure_activedirectory_v2'

omniauth:
  auto_sign_in_with_provider: azure_activedirectory_v2

매 로그인 시도는 OmniAuth 제공자로 리디렉트되므로 로컬 자격 증명을 사용하여 로그인할 수 없습니다. OmniAuth 사용자 중 적어도 하나는 관리자임을 확인하세요.

또한 https://gitlab.example.com/users/sign_in?auto_sign_in=false로 이동하여 자동 로그인을 우회할 수 있습니다.

커스텀 OmniAuth 제공업체 아이콘 사용

대부분의 지원되는 제공업체에는 렌더링된 로그인 버튼을 위한 기본 아이콘이 포함되어 있습니다.

자체 아이콘을 사용하려면 이미지가 64 x 64 픽셀에서 렌더링하도록 최적화되었는지 확인한 다음, 다음 두 가지 방법 중 한 가지로 아이콘을 덮어씁니다.

• 사용자 정의 이미지 경로 제공:

  1. 이미지를 GitLab 서버 도메인 외부에 호스팅하는 경우 콘텐츠 보안 정책이 이미지 파일에 액세스를 허용하도록 구성합니다.
  2. GitLab 설치 방법에 따라 GitLab 구성 파일에 사용자 정의 icon 매개변수를 추가합니다. OpenID Connect 제공업체에 대한 예제는 OpenID Connect OmniAuth 제공자를 확인하세요.

• 구성 파일에 이미지 직접 포함: 이 예제는 이미지의 Base64로 인코딩된 버전을 생성하여 데이터 URL을 통해 제공할 수 있습니다:

  1. 이미지 파일을 GNU base64 명령으로 인코딩합니다(예: base64 -w 0 <logo.png>), 이렇게 하면 단일 라인의 <base64-data> 문자열이 반환됩니다.

  2. Base64로 인코딩된 데이터를 GitLab 구성 파일의 사용자 정의 icon 매개변수에 추가합니다:

     omniauth:
       providers:
         - { name: '...'
             icon: 'data:image/png;base64,<base64-data>'
             ...
           }
     

앱 또는 구성 변경

GitLab의 OAuth는 동일한 외부 인증 및 인가 제공자를 여러 제공업체로 설정하는 것을 지원하지 않기 때문에, 제공자 또는 앱을 변경하는 경우 GitLab 구성 및 사용자 식별을 동시에 업데이트해야 합니다. 예를 들어, saml 및 azure_activedirectory_v2를 설정할 수 있지만, 동일한 구성에 두 번째 azure_activedirectory_v2를 추가할 수는 없습니다.

이 지침은 GitLab이 extern_uid를 저장하고 사용자 식별에 사용하는 유일한 데이터인 모든 인증 방법에 적용됩니다.

제공업체 내에서 앱을 변경하는 경우, 사용자의 extern_uid가 변경되지 않으면 GitLab 구성만 업데이트해야 합니다.

구성을 바꾸려면:

1. gitlab.rb 파일에서 제공자 구성을 변경합니다.
2. 이전 제공자에 대해 GitLab에 식별을 가진 모든 사용자의 extern_uid를 업데이트합니다.

extern_uid를 찾으려면 현재 제공업체에 대해 동일한 사용자의 현재 extern_uid를 확인하세요.

extern_uid를 업데이트하는 두 가지 방법이 있습니다:

• 사용자 API를 사용합니다. 제공자 이름과 새 extern_uid를 전달합니다.

• 레일스 콘솔를 사용합니다:

  Identity.where(extern_uid: 'old-id').update!(extern_uid: 'new-id')`
  

알려진 문제

대부분의 지원되는 OmniAuth 제공업체는 Git을 통한 HTTP 암호 인증을 지원하지 않습니다. 이를 해결하기 위해 개인 접근 토큰을 사용하여 인증할 수 있습니다.