问题描述
情况
我有一个使用Azure AD B2C作为其身份验证的Web应用程序.我们正在使用OWIN OpenIdConnect来处理此过程.会话超时设置为15分钟(web.config和AzureADB2C登录策略中的sessionState),并且在策略级别的策略中启用了SSO.该会话设置为滚动. OWIN CookieAuthentication还使用了15m的滑动到期时间.
I have a web application that is using Azure AD B2C as its authentication. We're using OWIN OpenIdConnect to handle this process. The session timeouts are set to 15 minutes (sessionState in web.config and on our AzureADB2C signin policy) and we have SSO enabled in the policy on the policy level. The session is set to be rolling. The OWIN CookieAuthentication is also using a 15m sliding expiry.
该Web应用程序分为多个部分(虚拟文件夹),但是都共享同一个Azure AD B2C实例.但是,每个人在AD中都有自己的应用程序注册. (这些基本上是国家/地区,因此我们有www.site.com/nl和www.site.com/de).这是为了确保登录时也能正确定向到您所在的国家/地区.使我们可以将一个国家链接到另一个AD实例.
The web application is split into multiple parts (virtual folders) but are all sharing the same Azure AD B2C instance. However each has its own application registration in the AD. (These are basically the countries so we have www.site.com/nl and www.site.com/de for example) This to ensure that when you login you are also directed properly back to the country you were operating in. Additionally this enables us to link a country to a different AD instance should this be required.
问题
当用户登录到应用程序,然后随后在其会话中注销时,登录过程将正常运行而不会出现问题,并且在尝试再次登录时,要求他/她再次登录.没关系,而且符合预期.
When a user logs into the application and then subsequently logs out within his/her session the login process runs properly without issue and upon trying to login again he/she is requested to login again. This is OK and as expected.
但是,当用户登录并让他/她的会话到期时,我们会显示一个弹出窗口,询问您是要继续(链接到登录页面)还是退出(链接到注销页面).两种情况下,用户都不需要提供他/她的凭据,这也不是我们所希望的行为(这意味着如果有人将其帐户保持打开状态并且发生超时,则任何人都仍可以登录到该帐户而无需提供凭据)
However when a user logs in and lets his/her session expire we display a popup that asks whether you'd like to continue (links to the login page) or quit (links to the logout page). Both cases the user does not need to provide his/her credentials and this is not our desired behaviour (as this would mean if someone leaves their account open and timeout occurs anyone can still login to this account without needing to present credentials)
预订
- 如果用户在会话超时后访问注销页面,则该URL称为
https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_mypolicyname&post_logout_redirect_uri=https%3a%2f%2fwww.site.com%2fbe&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554
,与用户在会话期间注销时的URL完全相同.但是,在此调用中,我在Azure端看到了两种不同的行为.
- If a user hits up the logout page after session timeout the exact same url is called
https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_mypolicyname&post_logout_redirect_uri=https%3a%2f%2fwww.site.com%2fbe&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554
as when a user would logout during his/her session. However I see 2 different behaviours on the Azure side on this call.
A)当会话未到期时,此呼叫将先呼叫https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout
,然后再重定向到我的重定向uri.
A) When the session did not expire this call first calls into https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout
before redirecting to my redirect uri.
B)会话期满后,此调用将直接重定向到我的重定向uri,而不会在情况A下通过uri.
B) When the session expired this call directly redirects to my redirect uri without passing over the uri in situation A.
-
情况A和情况B之间存在1个cookie差异,称为
x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname
,它仅存在于情况A中,这使我相信这会导致不同的行为.但是,这是login.microsoftonline.com域上的Microsoft cookie,因此我对此没有控制或影响.
There is 1 cookie difference between situation A and B called
x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname
it only exists in situation A which leads me to believe that this causes the different behaviour. However this is a Microsoft cookie on the login.microsoftonline.com domain so I have no control or influence over this.
在会话超时后初始化登录时,我看到呼叫通过包含与我的任何应用程序都不匹配的clientid来传递:https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/authorize?client_id=bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4&redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fte%2fmyazuread.onmicrosoft.com%2foauth2%2fauthresp&response_type=id_token&scope=email+openid&response_mode=query&nonce=nonce&nux=1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties
这为我提出了一个问题,该应用程序是什么,为什么?在我的身份验证流程中使用过,导致我的用户不需要重新身份验证?
When the login is initialized after session timeout I see calls pass by containing a clientid that does not match with any of my applications: https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/authorize?client_id=bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4&redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fte%2fmyazuread.onmicrosoft.com%2foauth2%2fauthresp&response_type=id_token&scope=email+openid&response_mode=query&nonce=nonce&nux=1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties
this begs the question for me what is this application and why is it being used in my auth flow causing my user not needing to re-authenticate?
问题:如何确保用户在每次会话超时后都需要进行身份验证?
Question:How do I ensure that users will need to authenticate after each session timeout?
推荐答案
更新04-09-2020:以下信息已弃用.请注意Microsoft的通知:
UPDATE 04-09-2020:The information below is deprecated. Please take note of the notice by Microsoft:
我相信可以利用用户登录频率"现在,由于浏览器会话的持久性"现在已正确完成.遗憾的是,我无法对此进行测试,因此如果有人可以确认,请在此问题的新答案中描述您如何成功解决此问题,我将更改答案并将此消息定向到您的答案.
I believe that it may be possible to utilize the "User Signin Frequency" setting now thanks to the fact the "Persistance for Browser Sessions" is now properly done. Sadly I cannot test this so if anyone can confirm please describe in a new answer to this question how you've successfully managed this issue and I'll change the answer and direct this message to your answer.
旧信息:
因此,在与Microsoft支持团队合作几周之后,我们终于有了一个明确的答案和明确的解决方案:
So after a few weeks of cooperation with the Microsoft Support team we finally have a closing answer and definite solution:
我的问题的解决方案的确是使用指示令牌生存期的策略来限制Azure AD本身的会话超时.这是我设置的策略,通常在租户的所有会话上都将其过期至15分钟(这是我们的愿望,如果您仅想针对特定应用程序设置此策略,请阅读本文)
The solution to my question was indeed to limit the session timeout of Azure AD itself using policies that dictate token lifetimes. Here's the policy I set to expire in general all session on the tenant to 15 minutes (which was our desire, read the article if you want to set this policy only for specific applications etc)
Connect-AzureAD
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSessionSingleFactor":"0.00:15:00","MaxAgeSessionMultiFactor":"0.00:15:00"}}') -DisplayName "TokenLifetimeDefaultPolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
Disconnect-AzureAD
感谢Microsoft支持.
Thanks to Microsoft Support.
这篇关于会话超时后,Azure AD B2C注销的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!