Azure 应用服务和 Azure Functions 中的身份验证和授权,微软azure云虚拟服务器Azure 应用服务和 Azure Functions 中的身份验证和授权Azure应用服务提供内置的身份验证和授权支持。只需在Web应用、RESTful API、移动后端和Azure Functions中编写少量的代......
Azure应用服务提供内置的身份验证和授权支持。只需在Web应用、RESTful API、移动后端和Azure Functions中编写少量的代码或根本无需编写代码,就能让用户登录和访问数据。本文介绍应用服务如何帮助简化应用的身份验证和授权。
安全身份验证和授权需要对安全性(包括联合身份验证、加密、JSON Web令牌(JWT)管理、授权类型等)有深度的了解。应用服务提供这些实用工具,让你将更多的时间和精力花费在为客户提供业务价值上。
重要
你并非必须使用此功能进行身份验证和授权。可以在所选的Web框架中使用捆绑的安全功能,也可以编写自己的实用程序。但请记住,Chrome 80针对Cookie对其实现SameSite的方式进行了中断性变更(发布日期在2020年3月左右);自定义远程身份验证或依赖于跨站点Cookie发布的其他方案可能会在客户端Chrome浏览器更新时中断。解决方法很复杂,因为需要针对不同的浏览器支持不同的SameSite行为。
应用服务托管的ASP.NET Core 2.1及更高版本已针对此中断性变更进行了修补,并且会相应地处理Chrome 80和更低版本的浏览器。此外,我们还在整个2020年1月在应用服务实例上部署了ASP.NET Framework 4.7.2的同一修补程序。有关详细信息,请参阅Azure应用服务SameSite Cookie更新。
备注
“身份验证/授权”功能有时也称为“简单身份验证/授权”。
备注
启用此功能会导致对应用程序的所有非安全HTTP请求自动重定向到HTTPS,而不管强制实施HTTPS所需的应用服务配置设置如何。如果需要,可以通过身份验证/授权设置配置文件中的requireHttps设置禁用此功能,但需注意确保不通过非安全HTTP连接传输安全令牌。
有关特定于本机移动应用的信息,请参阅使用Azure应用服务对移动应用进行用户身份验证和授权。
工作原理
在Windows上
身份验证和授权模块在应用程序代码所在的同一沙盒中运行。启用后,每个传入的HTTP请求将通过此模块,然后由应用程序代码处理。
一个体系结构图,显示请求被站点沙盒中的进程拦截,该进程与标识提供者进行交互,然后再允许流量发往已部署的站点
此模块为应用处理多项操作:
·使用指定的提供程序对用户进行身份验证
·验证、存储和刷新令牌
·管理经过身份验证的会话
·将标识信息插入请求标头
此模块独立于应用程序代码运行,使用应用设置进行配置。不需要任何SDK、特定语言,或者对应用程序代码进行更改。
用户/应用程序声明
对于所有语言框架,应用服务都通过将传入令牌(无论是来自经过身份验证的最终用户还是来自客户端应用程序)中的声明注入请求标头,使其可供代码使用。对于ASP.NET 4.6应用,应用服务会在ClaimsPrincipal.Current中填充经过身份验证的用户声明,使你能够遵循标准的.NET代码模式(包括[Authorize]属性)。同样,对于PHP应用,应用服务会填充_SERVER[REMOTE_USER]变量。对于Java应用,可从Tomcat servlet访问声明。
对于Azure Functions,没有为.NET代码填充ClaimsPrincipal.Current,但你仍然可以在请求标头中找到用户声明,也可通过请求上下文甚至通过绑定参数来获取ClaimsPrincipal对象。有关详细信息,请参阅使用客户端标识。
有关详细信息,请参阅访问用户声明。
备注
目前,ASP.NET Core不支持为当前用户填充身份验证/授权功能。但是,确实存在一些第三方开源中间件组件,可以帮助填补这一空白。
令牌存储
应用服务提供内置的令牌存储,这是与Web应用、API或本机移动应用的用户相关联的令牌存储库。对任何提供程序启用身份验证时,此令牌存储可立即供应用使用。如果应用程序代码需要代表用户访问这些提供程序中的数据,例如:
发布到经过身份验证用户的MicrosoftAccount时间线
使用Microsoft Graph API读取用户的公司数据
通常,必须编写代码才能在应用程序中收集、存储和刷新这些令牌。使用令牌存储,只需在需要令牌时才检索令牌;当令牌失效时,可以告知应用服务刷新令牌。
将为经身份验证的会话缓存ID令牌、访问令牌和刷新令牌,它们只能由关联的用户访问。
如果不需要在应用中使用令牌,可以在应用的“身份验证/授权”页中禁用令牌存储。
日志记录和跟踪
如果启用应用程序日志记录,将在日志文件中直接看到身份验证和授权跟踪。如果出现意外的身份验证错误,查看现有的应用程序日志即可方便找到所有详细信息。如果启用失败请求跟踪,可以确切地查看身份验证和授权模块在失败请求中发挥的作用。在跟踪日志中,找到对名为EasyAuthModule_32/64的模块的引用。
标识提供者
应用服务使用联合标识,在其中,第三方标识提供者会为你管理用户标识和身份验证流。默认提供五个标识提供者:
对其中一个提供程序启用身份验证和授权时,其登录终结点可用于用户身份验证,以及验证来自提供程序的身份验证令牌。可以轻松为用户提供其中任意数量的登录选项。
存在旧版可扩展性路径,用于与其他标识提供者或自定义身份验证/授权解决方案集成,但是不建议使用,而应考虑使用OpenID Connect支持。
身份验证流
身份验证流对于所有提供程序是相同的,但根据是否要使用提供程序的SDK登录而有所差别:
·不使用提供程序SDK:应用程序向应用服务委托联合登录。浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。服务器代码管理登录过程,因此,此流也称为“服务器导向流”或“服务器流”。此方案适用于浏览器应用。它也适用于使用移动应用客户端SDK登录用户的本机应用,因为SDK会打开Web视图,使用应用服务身份验证将用户登录。
·使用提供程序SDK:应用程序手动将用户登录到提供程序,然后将身份验证令牌提交给应用服务进行验证。无浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。应用程序代码管理登录过程,因此,此流也称为“客户端导向流”或“客户端流”。此方案适用于REST API、Azure Functions和JavaScript浏览器客户端,以及在登录过程中需要更高灵活性的浏览器应用。它还适用于使用提供程序SDK登录用户的本机移动应用。
备注
对于应用服务中受信任浏览器应用对应用服务或Azure Functions中另一REST API的调用,可以使用服务器导向流对其进行身份验证。有关详细信息,请参阅在应用服务中自定义身份验证和授权。
下表说明了身份验证流的步骤。
对于客户端浏览器,应用服务可自动将所有未经身份验证的用户定向到/.auth/login/lt;providergt;。还可以向用户提供一个或多个/.auth/login/lt;providergt;链接,让他们使用所选的提供程序登录到你的应用。
授权行为
在Azure门户中,当传入请求未经过身份验证时,可以使用多种行为配置应用服务授权。
一个屏幕截图,显示“请求未通过身份验证时要采取的操作”下拉列表
以下标题介绍了选项。
允许匿名请求(无操作)
此选项将对未经身份验证的流量的授权交给应用程序代码处理。对于经过身份验证的请求,应用服务还会在HTTP标头中一起传递身份验证信息。
使用此选项可以更灵活地处理匿名请求。例如,可以向用户提供多个登录提供程序。但是,必须编写代码。
仅允许经过身份验证的请求
选项是“使用provider登录”。应用服务将所有匿名请求重定向到所选提供程序的/.auth/login/provider。如果匿名请求来自本机移动应用,则返回的响应为HTTP 401 Unauthorized。
使用此选项不需要在应用中编写任何身份验证代码。可以通过检查用户的声明来处理精细授权,例如角色特定的授权(请参阅访问用户声明)。
注意
以这种方式限制访问适用于对应用的所有调用,对于想要主页公开可用的应用程序来说,这可能是不可取的,就像在许多单页应用程序中一样。
备注
默认情况下,Azure AD租户中的任何用户都可以从Azure AD请求应用程序的令牌。若要仅允许一组定义的用户访问应用,可以在Azure AD中配置应用程序。
特别声明:以上文章内容仅代表作者本人观点,不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。
二维码加载中...
使用微信扫一扫登录
使用账号密码登录
平台顾问
微信扫一扫
马上联系在线顾问
小程序
ESG跨境小程序
手机入驻更便捷
返回顶部