> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.
# システムアーキテクチャ
> ID、サインイン、プロビジョニングが Iru Identity をどのように流れるか、およびデータを保護しテナントを分離するアーキテクチャ上の保証について説明します。
Iru Identity は、ユーザー、ユーザーについて把握しているシステム、およびユーザーが使用するアプリケーションの間にある ID レイヤーです。以下では、サインイン、プロビジョニング、アクセスの決定がそのレイヤーをどのように流れるかを説明します。
## ID レイヤー
```mermaid theme={null}
flowchart LR
subgraph people["ユーザー"]
emp["従業員と契約者"]
end
hr["HR システム
(存在するユーザー)"]
idp["既存のプロバイダー
(オプション · 移行)"]
subgraph iru["Iru Identity"]
dir["ディレクトリ"]
engine["ポリシーエンジン"]
prov["プロビジョニング"]
end
subgraph apps["ユーザーの作業場所"]
saas["アプリケーション"]
end
hr -->|"ユーザーを同期"| dir
emp -->|"パスキーでサインイン"| engine
idp -. "オプションのサインイン" .-> engine
dir --> engine
engine -->|"許可されたアクセス"| saas
dir --> prov
prov -->|"アカウント"| saas
```
Iru Identity は **ID プロバイダー**です。ユーザーは通常、パスキーまたは Iru Access アプリを使用して Iru に直接サインインし、Iru は接続されたすべてのアプリに対してユーザーの身元を保証します。各アプリがサポートする SAML または OIDC 標準を使用して、署名付きの ID ステートメントを送信します。
Iru は、すでに運用している ID プロバイダーに対する**証明書利用者としても機能**できます。サインインをそのプロバイダーに引き渡し、プロバイダーがユーザーを確認するとセッションを続行します。これは副次的な経路で、次の 2 つの状況を想定しています。
* **既存のプロバイダーで Iru プラットフォームにサインインする。** すべての Iru テナントは管理者の管理とユーザーの同期に Iru Identity を使用しますが、すべての組織が完全な ID プロバイダーとして使用しているわけではありません。Iru Identity が Iru とその製品への認証レイヤーである場合、ユーザーはすでに運用しているプロバイダーでサインインできます。
* **移行を容易にする。** ID プロバイダーとしての Iru Identity に移行する間、ユーザーは移行期間中も現在のプロバイダーを通じてサインインし続けることができます。
## サインインの仕組み
```mermaid theme={null}
sequenceDiagram
participant U as ユーザー
participant A as アプリケーション
participant I as Iru Identity
participant P as 接続されたプロバイダー
U->>A: アプリを開く
A->>I: Iru に認証を依頼
alt 直接サインイン (デフォルト)
I->>U: パスキーまたは Iru Access を要求
U-->>I: ID を証明
else フェデレーションサインイン (認証レイヤーまたは移行)
I->>P: 既存のプロバイダーに引き渡す
P-->>I: ユーザーを確認
end
I->>I: 認証ポリシーを評価
alt ポリシーに合格
I-->>A: シングルサインオンを発行
A-->>U: アクセスを許可
else ポリシーに不合格
I-->>U: 拒否して理由を説明
end
```
接続されたアプリへのすべてのサインインは、そのアプリの認証ポリシーに照らしてチェックされます。強力な認証器は常に必須で、ポリシーはアクセスを許可する前にデバイストラストを評価します。Iru は決定を[アクティビティログ](/ja/identity/administration/activity-log)に記録します。
## プロビジョニングの仕組み
プロビジョニングは、ディレクトリとアプリを 2 つの方向で実態に合わせて維持します。
ユーザーは信頼できる情報源からディレクトリに取り込まれます。
```mermaid theme={null}
flowchart LR
hr["HR システム"] -->|"スケジュール同期"| dir["ディレクトリ"]
file["ユーザーインポート"] -->|"アップロード時"| dir
manual["手動入力"] --> dir
dir -->|"属性が駆動"| groups["グループメンバーシップ"]
```
接続された HR システムはスケジュールに従ってユーザーを同期し、ファイルインポートは一度にバッチを取り込み、いつでも手動でユーザーを追加できます。プロファイルが到着すると、[Auto Groups](/ja/identity/directory/auto-groups) がメンバーシップを自動的に更新します。
アクセスの変更は接続されたアプリケーションに流れます。
```mermaid theme={null}
flowchart LR
dir["ディレクトリ"] -->|"割り当てられたアクセス"| prov["プロビジョニング"]
prov -->|"作成または更新"| app["アプリのアカウント"]
prov -->|"オフボーディング時に削除"| app
```
プロビジョニングをサポートするアプリにユーザーを割り当てると、Iru はそこでユーザーのアカウントを作成および更新します。アクセスが削除されると、Iru はアカウントを削除できます。Iru はこれらの同期の履歴を保持するため、何が起こったかを確認できます。[プロビジョニング](/ja/identity/applications/provisioning)を参照してください。
## Iru Access
**Iru Access** は、ユーザーがコンピューターまたはモバイルデバイスにインストールする Iru アプリです。同時に 2 つの役割を果たします。
* **認証器:** ユーザーがサインインに使用する、デバイスにバインドされたパスキー形式の資格情報を保持し、デバイスの生体認証または画面ロックでロック解除されます。
* **デバイスエージェント:** デバイスの健全性シグナルを Iru に報告し、[デバイストラスト](/ja/identity/authentication/device-trust)ポリシーでそれを要求できます。
両方の役割を果たすため、1 つのアプリでユーザーに高速でフィッシング耐性のあるサインインを提供し、アクセスの決定のためのデバイスの状態を提供します。別のエージェントを展開する必要はありません。
## デバイストラストシグナル
各デバイスの Iru Access エージェントは、デバイスの健全性 (デバイスが暗号化されていて正常かどうかなど) を Iru に報告し、認証ポリシーでそれを使用できます。これにより、ポリシーはアクセスを許可する前に既知の正常なデバイスを要求できます。[Device trust](/ja/identity/authentication/device-trust) を参照してください。
## テナントを保護する保証
認証は信頼できる状態を保つ必要があります。Iru がそれを保護するために行っていることは次のとおりです。
ディレクトリ、アプリ、設定は独自のテナントに存在します。ある組織のデータが別の組織に見えることはありません。
Iru がアプリに送信する ID ステートメントは署名されているため、各アプリはそれが本当に Iru から送信され、転送中に改ざんされていないことを確認できます。
パスキーなどの認証器は、サインインに必要な秘密情報を使用するアプリと共有する必要がないように保存および検証されます。
情報は、ユーザー、Iru、アプリ間の転送中および保存中に保護されます。
資格情報とセッションの保護方法、およびデータとプライバシーに関する考え方については、[セキュリティとプライバシー](/ja/identity/security/security-and-privacy)を参照してください。
## 次のステップ
上記で参照したオブジェクトとその関係を確認します。
ユーザーがすでにサインインに使用している ID プロバイダーを接続します。
各アプリにサインインできるユーザーと、証明する必要がある内容を決定します。
ユーザーがサインインするアプリを接続します。