--- title: サインインと identity description: OpenLM Platform でのサインインの仕組み、サインインが依存する設定、サインインの問題を診断する方法について説明します。 product: OpenLM Platform --- ## サインインの仕組み OpenLM Platform には独自のサインインサービス **identity** があり、`https:///identity` で提供されます。これは OpenID Connect プロバイダーで、ユーザーをサインインさせ、UI がすべての要求に付けて送信するトークンを発行します。要求は次の手順で処理されます。 ```text 1. User opens https://DOMAIN/licenses 2. The UI sends the user to https://DOMAIN/identity (sign-in page) 3. Identity checks the user's password (or your directory) and issues a token 4. The UI calls https://DOMAIN/api/... with the token 5. The gateway passes the call to a service 6. The service asks identity: is this token valid? → https://DOMAIN/identity 7. Valid: the service answers. Not valid: 401. ``` 手順 6 があるため、OpenLM Platform のアドレスは [クラスター内から](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/networking#クラスター内からプラットフォームのアドレスに到達する) 利用でき、かつ [信頼された証明書](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/tls-certificates) を使用している必要があります。 ## 依存する設定 すべてのトークンには発行者の名前が含まれており、各サービスはその名前を自身の設定と比較します。values ファイルは、これらの設定をすべて `DOMAIN` から設定します（[ステップ 4](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-4-values)）。 | 設定 | 値 | |---|---| | `AUTHORITY_URL`, `INFRASTRUCTURE__AUTHORITYURL` | `https://DOMAIN/identity` | | `IssuerUri`, `UI_OAUTH_ISSUER_URL`, `UI_BASE_HREF_URL` | `https://DOMAIN/identity` | | `INFRASTRUCTURE__USESECURITY` | `true` | | `OLM__K8s__ServiceNamespace` | `openlm` | これらの設定には、次のルールに従います。 - **どこでもまったく同じ文字列にする**: サービスにとって、`https://openlm.example.com/identity` と `https://openlm.example.com/identity/` は別の発行者です。 - **常に `https://` を使う**: ブラウザーは HTTPS にリダイレクトされるため、`http://` で発行されたトークンは一致しません。 - **後から `DOMAIN` を変更する場合**: これらの設定を変更してから、最初に identity サービスを、その後にほかのすべてのサービスを再起動します。 ## 初回起動 identity は初回起動時に、データベースのテーブルを作成し、プラットフォームのアプリケーションを登録します。これには数分かかります。identity の準備が整う前に起動したサービスは失敗せず、待機して再試行します。ただし、identity に **到達できない** 間に起動したサービスは、セキュリティをまったく確認しないモードにフォールバックすることがあります。[ステップ 7](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-7-verify) の確認 3 でこれを検出できます（`401` ではなく `404` が返ります）。identity が正常になったら、サービスを再起動します。 ## ディレクトリでサインインする identity は、OpenLM Platform のディレクトリ同期サービス（DSS）を通じて、Active Directory または LDAP に対してユーザーをサインインさせることもできます。これは Helm ではなく、インストール後に OpenLM Platform の管理画面で設定します。 ## サインインの問題を診断する 次の表で症状を探します。 | 症状 | 考えられる原因 | 確認内容 | |---|---|---| | サインインページが読み込まれない（`/identity` が 404/502/503 を返す） | identity が実行されていない | `kubectl -n openlm get pods \| grep identity` を実行し、そのログを確認します | | サインインはできるが、すべての画面でデータを読み込めないと表示される | サービスが `https://DOMAIN/identity` に到達できない、または信頼していない | 任意のバックエンドのログ: `IdentityUnavailable`、`SSL`、`certificate` | | UI とサインインページの間でリダイレクトが繰り返される | 発行者の設定がブラウザーのアドレスと異なる、またはどこかで `http://` が使われている | [依存する設定](#依存する設定) の表とブラウザーのアドレスバーを比較します | | 新しくサインインしたユーザーに `401` が返る | 時刻のずれ、またはサービスが古い構成をキャッシュしている | ノードの時刻（NTP）を確認してから、サービスを再起動します | | `/api/licensemanager/bff/user` で `401` ではなく `404` が返る | サービスがセキュリティなしで起動した（identity が停止していた） | サービスを再起動します | まず identity サービス自体のログから確認します。 ```bash kubectl -n openlm logs deploy/openlm-identity --since=30m | grep -iE "error|exception|issuer" | tail -20 ```