ラベル saml の投稿を表示しています。 すべての投稿を表示
ラベル saml の投稿を表示しています。 すべての投稿を表示

2023年3月2日木曜日

GitlabでOneloginとSAML連携する際のポイント

GitlabでOneloginとSAML連携する際のポイント

概要

Gitlab + Onelogin で SAML 認証連携する際のいくつかのポイントを紹介します

環境

  • Gitlab-ee 15.6.7
  • Onelogin 2023/03/01 時点

Onelogin 側の設定

Configuration

ここでは gitlab 側の設定を記載します

  • Audience・・・Onelogin 側が払い出す Issuer の URL を記載します
  • Recipient・・・Gitlab の URL + SAML 用のコールバック URL を記載します
  • ACS URL Validator・・・Recipient で指定した Gitlab の URL の正規表現版を記載します
  • ACS URL・・・Recipient で指定した Gitlab の URL を記載します
  • Login URL・・・Gitlab のログイン URL を記載します

上記以外はすべてデフォルトのままで OK です

SSO

gitlab.rb に記載する情報を確認できます
使用する情報は

  • X.509 Certificates の SHA1 フィンガープリント情報 (View Details から確認可能)
  • Issuer URL
  • SAML 2.0 Endpoint

になります

Parameters

SAML 認証時にメールアドレスの情報を送信するようにします
プラスボタンから追加しましょう

  • name・・・email
  • value・・・Email

その際に「Include in SAML assertion」には必ずチェックするようにしてください

これのチェックがないと「422 Email can't be blank, Notification email can't be blank」のエラーになります

user の追加

作成した SAML アプリにログインを許可するユーザを追加しましょう
ロールを追加しても OK です

gitlab.rb

上記の情報を含めて gitlab.rb の内容を記載します

記載する情報は以下の通りです

  • assertion_consumer_service_url・・・Gitlab の URL + コールバック URL
  • idp_cert_fingerprint・・・SSO で確認した X.509 Certificates の SHA1 フィンガープリント情報
  • idp_sso_target_url・・・SSO で確認した SAML 2.0 Endpoint
  • issuer・・・SSO で確認した Issuer URL
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml_3']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = false
gitlab_rails['omniauth_providers'] = [
  {
    name: 'saml_3',
    label: 'Onelogin',
    args: {
      name: 'saml_3',
      assertion_consumer_service_url: 'https://your.gitlab.com/users/auth/saml_3/callback',
      idp_cert_fingerprint: 'xxxxxxxxxxxxxxx',
      idp_sso_target_url: 'https://xxxxxxx.onelogin.com/trust/saml2/http-post/sso/xxxxxxxxxxx',
      strategy_class: 'OmniAuth::Strategies::SAML',
      issuer: 'https://app.onelogin.com/saml/metadata/xxxxxxxxxxxxx',
      name_identifier_format: 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
    }
  },
]

動作確認

あとは reconfigure してログインページから onelogin のユーザでログインできるか確認すれば OK です

最後に

Gitlab + Onelogin の情報があまりネット上にはないのでこの記事が他の人の役に立てばいいかなと思います

2023年2月15日水曜日

Gitlab に複数の SAML プロバイダを設定する際の注意事項

Gitlab に複数の SAML プロバイダを設定する際の注意事項

概要

ハマりポイントをメモしておきます

環境

  • Gitlab-ee 15.5.9

ハマリポイント

  • omniauth_auto_sign_in_with_provider に saml, saml_2 という感じで別の識別文字名を設定する
  • omniauth_providers_saml_name に saml, saml_2 といった感じで omniauth_auto_sign_in_with_provider に設定した識別文字列を設定する
  • args.name に omniauth_providers_saml_name と同じ値を設定する
  • args.strategy_class に OmniAuth::Strategies::SAML を設定する
  • assertion_consumer_service_url に omniauth_providers_saml_name が含まれるように設定する (/users/auth/saml_2/callback)
    • IdP 側のコールバックURLも変更するように

2021年12月10日金曜日

Gitlab の SAML Groups 機能を試してみた

Gitlab の SAML Groups 機能を試してみた

概要

Gitlab の SAML Groups 機能は SAML Idp 側から送信される Groups 情報を元にログインの許可やユーザ属性の自動付与を行うことができます

今回は AzureAD を使って試してみました

環境

  • Gitlab 14.3.4-ee
  • AzureAD (20211126 時点)

Required Groups

Required Groups 機能はリスト内に含まれるグループ情報でなければログインできなくする機能です

gitlab.rb では以下のように設定します

gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "AzureAdTest",
    groups_attribute: 'Groups',
    required_groups: ['Developers', 'Freelancers', 'Admins', 'Auditors'],
    args: {
      assertion_consumer_service_url: "https://your.gitlab.example.com/users/auth/saml/callback",
      idp_cert_fingerprint: "xxxx",
      idp_sso_target_url: "https://login.microsoftonline.com/xxxxxx/saml2",
      issuer: "https://your.gitlab.example.com",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

まず groups_attribute で AzureAD 側から送信される「属性とクレーム」のクレーム名を指定します
そして required_groups を使って必須のグループ名を指定します
ここで指定されるグループ名が AzureAD から送信されない場合はログインエラーになります

AzureAD 側のクレーム設定は以下のとおりです
例えば Admins という属性を持っている場合はログインできます
ここで注意してほしいのは例え AzureAD 側で Admins を設定していても Gitlab 側の管理者グループに所属するわけではないという点です

もし管理者グループに自動で登録したい場合は required_groups ではなく admin_groups を使います

これで再度ログインしてみるとちゃんとログインできるのが確認できます
またどのグループにも属していないのが確認できると思います

External Groups

external_groups はリスト内に記載されているグループだった場合に Gitlab の External user フラグを自動的にオンにしてくれる機能です

gitlab.rb は以下のように記載します
先程 required_groups と記載していたところを external_groups に変更します

gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "AzureAdTest",
    groups_attribute: 'Groups',
    external_groups: ['Freelancers'],
    args: {
      assertion_consumer_service_url: "https://your.gitlab.example.com/users/auth/saml/callback",
      idp_cert_fingerprint: "xxxx",
      idp_sso_target_url: "https://login.microsoftonline.com/xxxxxx/saml2",
      issuer: "https://your.gitlab.example.com",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

AzureAD 側のクレームは Admins ではなく Freelancers が送信されるようにします

これでログインすると Gitlab の External user フラグが自動でオンになっているの確認できます

External user フラグがオンになっている場合はプロジェクトが作成できなかったり Public なプロジェクトしか見れなくなります

最後に

他には Administrator groups と Auditor groups があります
前者は自動で Gitlab の管理者グループに登録する機能で後者はリードオンリーユーザとして登録する機能になります

それぞれの機能は And 条件として使うことができます
なので必須のグループ名かつこのグループ名は Admin として登録するということが可能です

自動で特定の属性を付与したい場合には便利かもしれません

参考サイト