0

現在、Microsoft Graph API を使用して、テナント ドメインのメンバーの Office 365 の「メタデータ」を監視および分析するマルチテナント Azure AD アプリケーションを実装しようとしています。たとえば、アプリケーションは One Drive のユーザー スペースを経時的に監視する場合があります。アプリケーションのアーキテクチャには、AngularJS SPA クライアントと Web アプリケーション バックエンドが含まれます。Web アプリケーションは、Azure AD 認証に加えて、ローカル登録 (電子メール アドレスとパスワードを使用した従来のサインアップなど) の両方を可能にするという考えです。たとえば、ローカル登録の場合、ユーザーは将来、Azure AD テナンシーをローカル アカウントに関連付けることができる可能性があります。

さまざまな認証メカニズムがどのように機能するかを理解するのに苦労しています。たとえば、Azure AD の場合、認証には 2 つのレベルが必要だと思います。1 つはクライアント SPA のユーザー用の認証であり、もう 1 つはバックエンドが Microsoft API を継続的に呼び出して更新を要求するために使用する認証です。トークンなど

  • Microsoft が既に例を提供しているさまざまな Azure AD 認証シナリオを使用して、このアーキテクチャをどのように実装できますか?
  • 2 つのアプリケーションを Azure AD に登録する (たとえば、ネイティブ アプリケーションとして登録された SPA と、それ自体で登録された Web アプリケーションなど) という私の最初の傾向がある場合、ユーザーはそれらの両方へのアクセスをどのように許可し、何を許可しますか?このワークフローはどのように見えますか? さらに、ユーザー リクエストの流れはどのようになりますか? SPA は Azure AD トークンを使用してバックエンドに要求を行いますが、バックエンドは認証トークンを受け取り、Microsoft API を呼び出すために何をするのでしょうか?
  • ローカル登録と共に Azure AD 認証をアプリケーションに組み込むにはどうすればよいでしょうか?
4

1 に答える 1

0

一般的に言えば、バックエンド サーバー/データベースの Azure AD テナントで、各ユーザーを自分のエンティティに関連付けることができます。Azure AD のすべてのユーザーは、エンティティ オブジェクトにいくつかの一意のプロパティを持っているためです。Azure AD セキュリティ トークンのクレームで説明されているように、ユーザーのemailまたはをユーザー テーブルの外部列として使用できます。objectId

ユーザーが 経由でサイトを認証すると、ヘッダーADAL.JS経由でバックエンド サーバーのアクセス トークンを取得できます。Authenticationアクセス トークンを使用して、Azure AD によって保護されているリソースを要求できます。また、アクセス トークンはJWTトークンであり、前述のように直接デコードしてユーザーの基本的なクレームを取得できます。ユーザーテーブルに保存したクレームを取得し、自分で保護されたリソースを要求するためにサーバーに登録されている特別なユーザーと一致させることができます。

于 2016-09-12T02:56:24.363 に答える