組織階層
インスタンスにはトップレベルの組織が含まれます。組織には 1 つのレベルの SubOrg を含めることができます。各組織には、ポリシー、メンバーシップ、ブランディング、RBAC、および分離境界が残ります。
OrgUnit は、1 つの組織内の部門またはチームです。 TenantContext、発行者、トークン要求、または 1 レベルの SubOrg 制限は決して変更されません。
- OrgUnit ツリーは最大深さ 8 をサポートします。
- 各メンバーは 1 つのプライマリ OrgUnit と追加の配置を持つことができます。
- OrgUnit 祖先チェーン内で最も近いアクティブなマネージャーが、最初のアクセス要求承認者の候補になります。
プロジェクトとアクセスポリシー
プロジェクトは、アプリケーションと承認ロールをグループ化します。プロジェクトごとの access_policy は、有効な UserGrant を持たない同じ組織のユーザーのみを制御します。組織間の ProjectGrant 承認は影響を受けません。
| プロジェクト方針 | 同一組織の行動 | セルフサービスパス |
|---|---|---|
| 開く | UserGrant なしで許可されます。 | アクセス要求は必要ありません。 |
| 制限付き | 拒否されました;管理者が直接アクセスを許可します。 | セルフサービスリクエストは利用できません。 |
| 承認が必要です | AccessRequest が承認されるまで拒否されます。 | ユーザーがアクセス要求を送信します。 |
アクセスリクエストのライフサイクル
AccessRequest は、保留中から承認、拒否、キャンセル、または期限切れに移行します。すべての結果は最終的なものであり、保留中のリクエストは 14 日後に期限切れになります。
承認により、同じトランザクション内に追跡可能な UserGrant が作成されます。要求者は自分の要求を承認することはできません。解決策は、OrgUnit マネージャーからプロジェクトおよび組織マネージャーに伝わります。
| 方式 | パス | 目的 | 必要な範囲 |
|---|---|---|---|
GET, POST |
/auth/access-requests |
現在のユーザーのリクエストを作成してリストします。 | session |
POST |
/auth/access-requests/:id/cancel |
現在のユーザーの保留中のリクエストをキャンセルします。 | session |
GET |
/auth/access-approvals |
現在のユーザーの承認を待っているリクエストをリストします。 | session |
POST |
/auth/access-approvals/:id/{approve|deny} |
現在のユーザーに割り当てられている保留中のリクエストを承認または拒否します。 | session |
GET |
/v1/organizations/:orgId/access-requests |
1 つの組織内のリクエストをリストします。 | access-requests:read |
GET |
/v1/organizations/:orgId/units |
組織単位ツリーを読み取ります。 | org-units:read |
POST, PATCH, DELETE, PUT |
/v1/organizations/:orgId/units/* |
ユニットのメンバーを作成、更新、移動、アーカイブ、および管理します。 | org-units:write |
セキュリティ境界
- すべての OrgUnit クエリと AccessRequest クエリは、
tenant_idとorg_idによってスコープされます。組織間またはテナント間の識別子は、存在を明らかにせずに 404 を返します。 - メンバーシップとプロジェクト アクセスは別個です。招待は組織に参加しますが、AccessRequest は既存のアクティブなメンバーに 1 つのプロジェクトへのアクセスを許可します。
- SCIM はユーザーとメンバーシップをプロビジョニングしますが、現在の実装ではディレクトリ グループを OrgUnits またはプロジェクトのロールにマップしません。
- Management API は、カーソル ページネーションと共有 API キーまたは組織マネージャー ガードを使用します。エンドユーザーのビジネスルートを再利用しません。