1

システムにトークンベースの認証を実装するプロジェクトに取り組んでいます。SAMLまたはOAuthのいずれかを使用することを考えていました。

トークン内で実際のポリシー（システムのACLベース）を表すことができるかどうかを知りたいと思いました。現在の設計では、すべてのリソースと許可された役割を含むトークンをユーザーに提供することを考えていました。ユーザーの要求に応じて、このトークンをチェックして、ユーザーが関連するリソースに対して必要な権限を持っているかどうかを確認するサービス。

SAML / OAuthトークンのいずれかを使用して表すことは可能ですか？両方で可能な場合は、どちらを使用する必要があります。私が見たほとんどの例から、SAMLはSSOソリューションに使用され、OAuthは実際の承認ポリシーの定義に使用されます。ただし、デモ/例からは、OAuthを使用して特定のリソースへの制限付きアクセスを許可できるかどうかは明確ではありませんでした。

たとえば、FacebookアプリがOAuthを使用して写真にアクセスしたい場合、特定のアルバムのみにアクセスを制限することはできますか？それとも、オールオアナッシングアプローチのようなものですか。詳細情報を入手するために読むことができるリソースはありますか？

4

1 に答える 1

1

ほとんどのアーキテクチャ (SAML と OAuth の両方) は、証明書利用者 (または受信 API) が解釈して独自のポリシー (ACL) を適用する属性を含むトークンを使用します。

OAuth の場合、アクセス トークンが表すアクセス許可を指定するためにスコープが使用されます。範囲は好きなだけ細かく設定できます (単一の写真アルバムの制限などのケースをカバーするため)。これらは、特定の OAuth フローでユーザーによって承認されている場合があります。トークン自体は OAuth 2.0 仕様では定義されていませんが、フォーマットを自己完結型 (おそらくトークン発行者によってデジタル署名されたもの) にすることができるため、スコープはその中に保持されます。一部のモデルは、発行者へのコールバック (おそらくバック チャネル) を介して検証する必要がある不透明なトークンを使用し、スコープは依拠当事者に返されます。

SAML では、同様の目的でアサーション内に属性ステートメントを含めることができます。依拠当事者は、個々の属性を解釈して、ユーザーが何を行うことが許可されているかを判断します。属性ステートメントは、SSO の一部として取得される場合もあれば、後で (認証後に) AttributeQuery を介して取得される場合もあります。

于 2012-06-15T16:19:53.823 に答える