ユーザー管理アクセス2.0（「UMA 2」）認可サーバー（AS）
OpenID Connectを補完するOAuth 2.0のプロファイルとして、UMA 2では、APIとWebリソースの保護を調整するためのRESTful、JSONベースの標準化されたフローと構造を定義しています。
UMA 2は、Gluuのような認可サーバー（AS）と、サービスの提供、監査、ポリシー管理、アカウンタビリティの向上を目的とした一元的なポリシー決定を可能にするリソースサーバー（RS） との間のインタフェースを定義します。
UMA 2は、ポリシー表現言語を標準化せずに、XACML、その他の宣言ポリシー言語、条件によって保証される手続き型コードによるポリシーの表現と評価の柔軟性を実現しています。
UMA 2は、OAuthからの認証の不可知を継承し、認証ではなく認可に重点を置いています。 OpenID Connectと連携して、アクセスしようとしている誰からでもアイデンティティ要求を収集し、グループベースまたはロールベースのポリシーを持つ自然ベースのサブセットである属性ベースの（OAuth2における “claim”）認可を有効にするようにプロファイルされています。
用語
UMA 2では、OAuth用語定義の新しい用語と拡張が導入されています。 いくつかの重要な用語があります：
| リソース所有者（RO）： | 保護されたリソース（ユーザー管理アクセスの「ユーザー」）へのアクセスを許可できるエンティティ。 これは一般的にエンドユーザーですが、会社など限定的な法的目的で扱われる人以外のエンティティでもかまいません。 |
| リソース・サーバー（RS）： | リソース所有者に代わってリソースをホストし、許可サーバーで保護するためのリソースを登録し、保護されたリソースに対する要求を受け入れて応答できるサーバー。 |
| Authorization Server（AS）*： | リソース・オーナーに代わって、リソース・サーバーで管理されるリソースを保護するサーバー。* Gluu はUMA ASとしての役割を持っています。 |
UAMエンドポイント
GluuサーバーのUMAエンドポイントは、以下にあります。
https：// <hostname> /.well-known/uma2-configuration
スコープ
UMA 2スコープは、クライアントに保護されたリソースに対するアクションを実行する権限を与えるために使用されます。 スコープが異なると、同じアクションへのアクセスを許可できます。 例えば、 “read”アクションはスコープ “read”または “all”で許可することができます。
いくつかのアクションでは、Resource Server（RS）は複数のスコープを同時に必要とすることがあります。 たとえば、「読み取り」アクションは、認可リクエストに「読み取り」スコープと「すべて」スコープが含まれている場合にのみ許可する必要があります。 UMA 2スコープはリソースにバインドされ、指定されたユーザーまたはクライアントがリソースにアクセスする必要があるかどうかをチェックするポリシーをフェッチするために使用されます。
UMA RPT認可ポリシー
UMA RPT認可ポリシーはUMAスコープに関連付けられています。 承認要求には、resource_idとスコープがあります。 各スコープは1つ以上のポリシーを指すことができます。 すべてのスコープに関連付けられたすべてのポリシーがtrueを返すと、アクセスが許可されます。
たとえば、GET / photoというリソースがあるとします。 それにアクセスするために、リソースサーバ（RS）は、読み取り範囲が存在することを要求する。 常にtrueを返すポリシーがある場合、/ scopeに含まれる/ photoへの承認リクエストはアクセスを許可します。
たとえば、特定のクライアントにのみアクセスを許可するなど、より洗練されたロジックを使用する場合は、client_id = “@ 1111″のようなものをポリシーに追加できます。 つまり、スコープに読み取りが含まれていて、client_id = “@ 1111″からのものである場合にのみ、/ photoへの承認要求が許可されます。
ポリシーには主に3つのプロパティがあります。
- スコープ：ポリシーはスコープごとにリソースを保護します。
- 認証スクリプト：アクセスを許可/拒否するために評価されるスクリプト。
- name：UMAポリシーに対する人間が判読可能な名前。