自動創建Azure AD Web應用程序密鑰

我們編寫了一套Powershell腳本，以便在Azure環境中自動創建我們的Web應用程序的新實例。這些腳本的一部分使用Graph API創建一些Azure AD對象，以及Auth0中的對應對象，我們將它們用於單點登錄。到目前爲止，我們還沒有成功地以編程方式爲AAD應用程序創建新密鑰。我們已經嘗試了很多方法，雖然我們可以看到生成的應用程序確實有一個密鑰（並且Auth0中的連接對象在其「客戶機密鑰」字段中具有該密鑰），但我們在嘗試進行身份驗證時總是收到此錯誤：自動創建Azure AD Web應用程序密鑰

通過這一點，我們已經獲准進入該應用的單點登錄和AAD讀取目錄數據。（編輯：我們通過手動繼provisioning_ticket_URL是由Auth0 API調用返回創建Connection對象對象的一部分做這個網址提示我們選擇Azure的憑據，然後顯示此頁：

）

直到我們通過Azure門戶爲應用程序手動創建新的密鑰，保存應用程序並將新創建的密鑰複製到Auth0連接之後，此錯誤仍然存在。這樣做總能解決問題，但我們希望避免這一額外步驟。

內，我們正在創建的API調用的應用程序AAD的身上，我們有這樣的節定義鍵：

"passwordCredentials": 
    [ 
    { 
     "startDate": "2016-10-28T20:40:32Z", 
     "endDate": "2017-10-29T20:40:32Z", 
     "keyId": "(a GUID)", 
     "value": "(a Base64 string)" 
    } 
    ],

至於那些價值，我們試圖產生它們有很多不同的方法，它接受API PUT調用的值，但當我們嘗試登錄時，它們仍然會給我們提供同樣的錯誤。作爲一個例子，我們嘗試的一種方法是插入$ appKeyGUID中的值和$ appKeyValue from：

$appKeyGUID = [guid]::NewGuid() 
$guidBytes = [System.Text.Encoding]::UTF8.GetBytes($appKeyGUID) 
$appKeyValue = [System.Convert]::ToBase64String($guidBytes);

into keyID and value，respe沉着應對。我已經在其他地方看過，值應該是44個字符長，但這不是。

但似乎價值本身可能不是問題。我嘗試通過Azure門戶生成密鑰，使用Graph API GET調用來檢索keyId，然後將這兩個確切值硬編碼到應用程序正文中，但登錄仍然會產生相同的錯誤。

任何想法，我要去哪裏錯了？

編輯：根據Philippe的建議，我試圖通過門戶只更改AD應用程序的顯示名稱，並且確實解決了問題。這導致我認爲，應用程序正文中的其他地方可能存在錯誤，這些錯誤在通過門戶進行保存時正在解決。我查了清單之前，做的是手動保存後，並確實有一個小的區別：RequiredResourceAccess部分（其中我從這裏http://www.cloudidentity.com/blog/2015/09/01/azure-ad-permissions-summary-table/這裏https://www.microsoftpressstore.com/articles/article.aspx?p=2473127&seqNum=2學會）中，我有這樣的：

{ 
    "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" 
},

所以我改變了我們發送的身體以匹配第二種格式。不幸的是，我們仍然在這個變化中遇到同樣的錯誤。此外，我驗證了在門戶上進行保存之前和之後清單現在是相同的，就像在應用程序上通過API GET調用返回的正文一樣。必須有其他其他門戶保存更改除應用程序的定義之外。

之後，我嘗試使用Graph API執行兩個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" 
     } 
     ] 
    } 
    ] 
}

來源

2016-10-28 MGS

嘗試更改只顯示名稱，並保存應用程序（無需創建一個新的密鑰）。這是否也解決了這個問題？你能分享你用來在Azure AD中創建對象的代碼嗎？你提到你已經「授予」應用登錄和閱讀目錄的權限 - 你是如何做到這一點的？ –

@PhilippeSignoret感謝您花時間回覆，Philippe。我已經更新了相應的問題 - 請參閱上面編輯的部分。 – MGS

看起來這裏的最終問題與應用程序同意有關。我將進入更多的細節在這裏，但隨時通過這個文件，該文件描述了我們同意框架迅速採取讀： https://azure.microsoft.com/en-us/documentation/articles/active-directory-integrating-applications/

你是顯示在您的應用程序清單的東西都涉及到你的應用程序的配置，但是，您的應用程序的同意記錄將不會在那裏找到，因此我認爲您的'a/b'測試不會有收穫。

我想你在這裏真正發現的是，如果你是管理員並保存應用程序，Azure門戶在後臺會有一些「魔術」，它會同意你的應用程序。當您在門戶網站中開始註冊應用程序（再次以管理員身份註冊）時，我們會在您保存應用程序後自動爲您記錄同意書。這種情況發生在後臺，產生的「對象」是：租戶中的應用程序的服務主體，以及您作爲用戶和服務主體之間的同意鏈接。創建的鏈接具體爲「管理員租戶範圍的同意」對象，如果您將「prompt = admin_consent」作爲查詢字符串添加到您的登錄網址，您將得到同樣的結果。

當您使用其他方法（如Graph API或AAD PowerShell）創建應用程序時，不會創建這些對象，這會導致您在嘗試和驗證時看到的那種錯誤。

這裏的解決方案是，您需要擁有與租戶的管理員一次的交互式登錄體驗，然後才能讓其他人登錄到該應用程序。在此登錄體驗期間，您必須獲得管理員同意您的應用程序及其所需的權限。在獲得了一次同意的經歷之後，以後對你申請的電話不需要同意，你也不會遇到你遇到的問題。

因此，在總結：

使用你想
然後使用你的應用程序信息的任何方法自動創建一個應用程序，並創建一個管理員交互式登錄，使用查詢字符串「提示= admin_consent」
然後使用你的應用程序，但是你期望它的工作

謝謝！ Shawn Tabrizi

來源

2016-11-09 22:28:03

自動創建Azure AD Web應用程序密鑰

回答

相關問題