CASの利用
CAS は、複数の Web アプリケーションのためのシングルサインオン (SSO) プロトコルです。 CASのユーザアカウントは、ユーザがサインインするまでシートを消費しません。
使用しているアイデンティティプロバイダに追加せずにユーザを認証したい場合、ビルトイン認証を設定できます。詳細は「アイデンティティプロバイダ外のユーザに対するビルトイン認証を許可する」を参照してください。
このガイドの内容は以下のとおりです。
CASでのユーザ名についての考慮
GitHub Enterprise Server のユーザ名には、英数字文字とダッシュ (-) のみが利用できます。GitHub Enterprise Server はアカウントのユーザ名内の非英数字文字をダッシュに正規化します。たとえば gregory.st.john のユーザ名は gregory-st-john に正規化されます。正規化されたユーザ名の先頭や末尾はダッシュにする事ができません。また、2 つ連続でダッシュを含むこともできません。
メールアドレスから生成されたユーザ名は、@ 文字の前の正規化された文字から生成されます。
複数のアカウントが正規化されて同一の GitHub Enterprise Server ユーザ名になる場合、1 つめのユーザアカウントだけが作成されます。同じユーザ名のそれ以降のユーザは、サインインできなくなります。
以下の表は、ユーザ名が GitHub Enterprise Server でどのように正規化されるかの例です。
| ユーザ名 | 正規化されたユーザ名 | 結果 |
|---|---|---|
| Ms.Bubbles | ms-bubbles |
このユーザ名は問題なく生成されました。 |
| !Ms.Bubbles | -ms-bubbles |
このユーザ名はダッシュから始まるので生成されません。 |
| Ms.Bubbles! | ms-bubbles- |
このユーザ名はダッシュで終わるので生成されません。 |
| Ms!!Bubbles | ms--bubbles |
このユーザ名は2つの連続したダッシュを含むので生成されません。 |
| Ms!Bubbles | ms-bubbles |
このユーザ名は生成されません。正規化されたユーザ名は正当ですが、既存のユーザ名です。 |
| Ms.Bubbles@example.com | ms-bubbles |
このユーザ名は生成されません。正規化されたユーザ名は正当ですが、既存のユーザ名です。 |
2要素認証
SAML あるいは CAS を利用する場合、2要素認証は GitHub Enterprise Server アプライアンス上ではサポートあるいは管理されませんが、外部の認証プロバイダによってサポートされることはあります。Organization での 2 要素認証の強制はできません。Organization での 2 要素認証の強制に関する詳しい情報については、「Organization で 2 要素認証を要求する」を参照してください。
CASの属性
以下の属性が利用できます。
| 属性名 | 種類 | 説明 |
|---|---|---|
ユーザ名 |
必須 | GitHub Enterprise Server のユーザ名 |
CASの設定
警告：GitHub Enterprise Server インスタンスでCASを設定するまでは、ユーザはCASのユーザ名とパスワードをAPIリクエストの認証やHTTP/HTTPS経由のGit操作に使えないことに注意してください。 その代わりに、ユーザはアクセストークンを作成しなければなりません。
-
任意のページの右上の隅で をクリックしてください。
-
左サイドバーで [Management Console] をクリックします。
左サイドバーで [Authentication] をクリックします。
- CASを選択してください。
- あるいは、ユーザがGitHub Enterprise Server インスタンスのアイデンティティプロバイダに属していないなら、Allow built-in authentication（ビルトイン認証の許可）を選択して、ビルトイン認証を使うように招待することもできます。
- Server URL（サーバのURL）フィールドにCASサーバの完全なURLを入力してください。 CAS サーバが GitHub Enterprise Server が検証できない証明書を使っているなら、
ghe-ssl-ca-certificate-installを使えばその証明書を信頼済みの証明書としてインストールできます。