简体   繁体   English

Azure CDN 阻止存储帐户 Static 使用 Active Directory 进行站点身份验证

[英]Azure CDN preventing Storage Account Static Site Authentication with Active Directory

I currently have an Azure Blob Storage Account setup with Azure CDN to host a Static Site.我目前有一个 Azure Blob 存储帐户设置和 Azure CDN 来托管 Static 站点。 This Static Site is connected to an App Service backend and uses frontend-based authentication using Active Directory baked into the application code with MSAL .此 Static 站点连接到应用服务后端,并使用基于前端的身份验证,该身份验证使用通过 MSAL 烘焙到应用程序代码中的Active Directory。

When it was initially deployed and running off of the Static Site's URL alone, I was able to authenticate without fail.当它最初在 Static 站点的 URL 单独部署和运行时,我能够成功地进行身份验证。 The auth popup would present itself, I would provide credentials, and the Active Directory sent back a token that I then confirmed with the backend and successfully redirected to the post-auth landing page. auth 弹出窗口会出现,我会提供凭据,Active Directory 会发回一个令牌,然后我与后端确认并成功重定向到 post-auth 登录页面。

The Problem I'm having now is that when I proceed to the URL provided by the Azure CDN (rather than the Storage Site's URL), the popup for authentication opens and allows me to provide credentials, but instead of closing and redirecting upon token reception, the popup simply hangs there.我现在遇到的问题是,当我继续访问由 Azure CDN(而不是存储站点的 URL)提供的 URL 时,身份验证弹出窗口打开并允许我提供凭据,而不是在收到令牌时关闭和重定向,弹出窗口只是挂在那里。 It's also interesting to note that the popup's URL is listed as the Static Site URL and not the CDN URL. It's also interesting to note that the popup's URL is listed as the Static Site URL and not the CDN URL. The token comes back and is present in later portions of the URL, so it must be a mis-match between the URLs that's causing the issue.令牌返回并出现在 URL 的后续部分中,因此它一定是导致问题的 URL 之间的不匹配。

I've Tried changing out the Static Site's configured Reply URLs to match the CDN, and it didn't make a difference.我尝试更改 Static 站点配置的回复 URL 以匹配 CDN,但没有任何区别。 I've also added the CDN URLs (both the custom one and the endpoint .azureedge.net one) to the Active Directory list of Reply URLs.我还将 CDN URL(自定义 URL 和端点.azureedge.net一个)添加到 Active Directory 回复 URL 列表中。

The CDN is providing a certificate for the custom URLs to use, so we need that in order for the custom URLs to work properly. CDN 为要使用的自定义 URL 提供证书,因此我们需要它才能使自定义 URL 正常工作。 To be clear as well, the authentication works when using the Static Site URL, but not the CDN URL.同样需要说明的是,使用 Static 站点 URL 时,身份验证有效,但 CDN URL 无效。

Has anyone else run into an issue of this nature?有没有其他人遇到过这种性质的问题? If so, have you solved it?如果有,你解决了吗?

For anyone who may come across this, the solution was much more simple than I had anticipated.对于任何可能遇到此问题的人来说,解决方案比我预期的要简单得多。 The MSAL configs for the frontend needed to be using the new CDN URL (which I figured), but the CDN itself needed to be purged and the changes picked up from the Blob storage.前端的 MSAL 配置需要使用新的 CDN URL(我认为),但需要清除 CDN 本身并从 Blob 存储中获取更改。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 Azure Active Directory对Azure网站的身份验证 - Azure Active Directory Authentication to Azure Web Site 如何在 Azure Blob 存储上的静态网站中启用 Azure AD(天蓝色活动目录)身份验证 - How to enable Azure AD (azure active directory) Authentication in a Static website on Azure Blob Storage Azure 存储帐户身份验证 - Azure storage account authentication Azure Devops set max-age on index.html in Azure storage with Azure CDN on static web site - Azure Devops set max-age on index.html in Azure storage with Azure CDN on static web site 如何使用Active Directory身份验证和来宾帐户导出Azure数据库 - How to export Azure Database using Active Directory authentication and guest account Azure CDN over Storage Account 的 DR - DR for Azure CDN over Storage Account Azure CDN 与存储帐户专用终结点 - Azure CDN with storage account private endpoint Azure Active Directory身份验证 - Azure Active Directory Authentication Azure CDN的后备存储帐户(或多个存储帐户) - Fallback storage account (or multiple storage accounts) for Azure CDN 从 Azure Active Directory (Azure AD) 身份验证访问 Azure Blob 存储 blob - Azure Blob Storage blob access from Azure Active Directory (Azure AD) authentication
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM