Azure環境でWebアプリケーションの新しいインスタンスを作成するプロセスを自動化する一連のPowershellスクリプトを作成しました。これらのスクリプトの一部は、Graph APIを使用して、いくつかのAzure ADオブジェクトと、Single Sign-Onに使用するAuth0の対応するオブジェクトを作成します。これまでは、AADアプリケーション用に新しいキーをプログラムで作成することに成功していませんでした。私たちはいくつかの方法を試しましたが、結果として得られるアプリケーションにはキーがあることがわかりますが(Auth0の接続オブジェクトにはClient Secretフィールドにそのキーがあります)、認証しようとすると常にこのエラーが発生します:この時点までAzure AD Web App Keyの自動作成
、我々はすでにシングルサインオンへのアプリへのアクセスを許可しているし、AADにディレクトリデータを読み取るために。 (編集:私たちは、手動で接続オブジェクトを作成するためにAuth0 API呼び出しによって返されたオブジェクトの一部であるprovisioning_ticket_URLを以下を通じてこれを行う。このURLは、Azureの資格情報のための私達を促し、その後、このページが表示されます。
)
このエラーは、Azureポータルからアプリケーションの新しいキーを手動で作成し、アプリケーションを保存し、新しく作成したキーをAuth0接続にコピーするまで続きます。そうすることで問題は解決しますが、この余分なステップを避けたいと思います。これらの値については
"passwordCredentials":
[
{
"startDate": "2016-10-28T20:40:32Z",
"endDate": "2017-10-29T20:40:32Z",
"keyId": "(a GUID)",
"value": "(a Base64 string)"
}
],
、我々はそれらを生成しようとしました:私たちは、APIの呼び出しで作成している、我々はキーを定義し、このセクションを持ってAADアプリケーションの本体内に
API PUT呼び出しの値を受け入れますが、ログインしようとすると同じエラーが表示されます。例として、$ appKeyGUIDの値をプラグインする方法がありました$ appKeyValueは次のとおりです。
$appKeyGUID = [guid]::NewGuid()
$guidBytes = [System.Text.Encoding]::UTF8.GetBytes($appKeyGUID)
$appKeyValue = [System.Convert]::ToBase64String($guidBytes);
にkeyIDとvalue、respe ctively。私は値が44文字でなければならないということを他のところで読んだことがありますが、これはそうではありません。
しかし、値そのものが問題ではないようです。私はAzureポータルを介してキーを生成しようとしましたが、KeyIdを取得するためにGraph API GET呼び出しを使用して、アプリケーション本体にこれら2つの正確な値をハードコーディングしましたが、ログインすると同じエラーが発生します。
どこが間違っているのですか?
EDIT:Per Philippeの提案によれば、私はADアプリケーションの表示名のみをポータルから変更しようとしましたが、実際に問題を解決しました。これにより、ポータルを介して保存する際に修正されていたアプリケーション本体内の別の場所で何かが間違っていた可能性があると考えられました。 (私はここhttp://www.cloudidentity.com/blog/2015/09/01/azure-ad-permissions-summary-table/、ここhttps://www.microsoftpressstore.com/articles/article.aspx?p=2473127&seqNum=2から学んだの)RequiredResourceAccessセクション内で、私はこれを持っていた:
{
"id": "5778995a-e1bf-45b8-affa-663a9f3f4d04",
"type": "Role"
},
{
"id": "5778995a-e1bf-45b8-affa-663a9f3f4d04",
"type": "Scope"
}
の代わりに私が保存し、一つの小さな違いが確かにあった前に、そのマニュアルをやった後、マニフェストをチェックしますポータルがこれを変更します
{
"id": "5778995a-e1bf-45b8-affa-663a9f3f4d04",
"type": "Role,Scope"
},
私は2番目の形式に一致するように送信する本文を変更しました。残念ながら、この変更では同じエラーが発生しています。さらに、アプリケーションでAPI GET呼び出しによって返される本体と同じように、マニフェストがポータルでの保存の前後で同じであることを確認しました。 以外のは、ポータルの保存がアプリケーションの定義以外に変更されている必要があります。
その後、グラフAPIを使用して2つのPATCH呼び出しを実行して、表示名を何かに更新してから、ポータルを介して同様に動作し、問題を修正することを期待して戻しました。私はポータルを通じて、PATCH呼び出しが実際にアプリの表示名を変更していることを確認しました。残念ながら、これらの編集では問題が解決されなかったようですが、私はまだ元のエラーを受けています。
私たちは、このようなグラフAPI呼び出しでアプリケーションを作成します。
$uri = "https://graph.windows.net/$waadTenant/applications?api-version=1.6"
$newADApp = (Invoke-RestMethod –Uri $uri –Headers $authHeader –Method POST -Body $newappbody –Verbose)
そして、ここでは、我々はアプリケーションを定義するために使用して終了の$ newappbodyです。私はハードトラブルシューティングの目的のためにコード化されたいくつかのことを残してきた:それはここでは、アプリケーションの同意に関連している究極の問題のように思える
{
"odata.type": "Microsoft.DirectoryServices.Application",
"displayName": "customer1",
"homepage": "https://customer1.(our tenant).com",
"identifierUris":
[
"https://customer1.(our tenant).com"
],
"replyUrls":
[
"https://(our tenant).auth0.com/login/callback"
],
"passwordCredentials":
[
{
"startDate": "(a hardcoded date)",
"endDate": "(a hardcoded date)",
"keyId": "(hardcoded GUID that was previously generated by the portal and extracted through an API GET)",
"value": "(hardcoded Base64 like above)"
}
],
"requiredResourceAccess":
[
{
"resourceAppId": "00000002-0000-0000-c000-000000000000",
"resourceAccess":
[
{
"id": "5778995a-e1bf-45b8-affa-663a9f3f4d04",
"type": "Role,Scope"
},
{
"id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6",
"type": "Scope"
},
{
"id": "6234d376-f627-4f0f-90e0-dff25c5211a3",
"type": "Scope"
}
]
}
]
}
表示名だけを変更し、新しいキーを作成せずにアプリを保存してみてください。これも問題を解決しますか? Azure ADでオブジェクトを作成するために使用しているコードを共有できますか?既にログインしてディレクトリを読み取るためにアプリに "許可"されていると言われていますが、どうしていますか? –
@PhilippeSignoretフィリップ・リプライに時間を割いてくれてありがとう。私はそれに応じて質問を更新しました - 上の編集セクションをご覧ください。 – MGS