简体   繁体   English

在Azure上使用SqlMembership Provider和Forms身份验证连接ASP.NET Web应用程序

[英]Wiring up ASP.NET Web Application using Forms Authentication with SqlMembership Provider on Azure

I'm experimenting with the Microsoft Azure portal in order to see how my legacy application performs with the least amount of rewrite. 我正在尝试使用Microsoft Azure门户,以查看我的旧应用程序如何以最少的重写量执行。 Authentication is a problem. 身份验证是一个问题。

Background: this ASP.NET web application currently uses the SqlMembership Provider for Users, Roles, Profiles and Personalization. 背景:该ASP.NET Web应用程序当前使用SqlMembership Provider用于用户,角色,配置文件和个性化。 Yep, there has been a lot of blogging about the ASP.NET Identity, Simple Membership, Universal Providers and that the asp.net SqlMembership Provider is being phased out. 是的,已经有很多关于ASP.NET身份,简单成员资格,通用提供程序的博客,并且正在逐步淘汰asp.net SqlMembership Provider。 But, if possible I'd still rather use the legacy asp.net membership on Azure. 但是,如果可能的话,我还是宁愿使用Azure上的旧版asp.net成员身份。

Currently, I am able to publish my VS.NET 2013 solution to Azure but I am not able to login. 当前,我可以将VS.NET 2013解决方案发布到Azure,但无法登录。 As soon as I navigate to the url, it auto-logs me in as the Azure Portal user. 一旦导航到该URL,它将自动以Azure Portal用户身份登录。 It almost appears that Windows Authentication is active, rather than forms. Windows身份验证似乎是活动的,而不是形式的。 Here's how I got here: 这是我到达这里的方式:

I created the sql membership tables on Sql Azure using special Azure-friendly scripts for Sql Azure (here: https://support.microsoft.com/kb/2006191 ). 我使用适用于Sql Azure的特殊Azure友好脚本在Sql Azure上创建了sql成员资格表(此处: https : //support.microsoft.com/kb/2006191 )。

However, when I run my application on the azure site vs. when I run it locally I see different behavior. 但是,当我在azure站点上运行应用程序与在本地运行它时,我看到了不同的行为。 On azure a different authentication mechanism takes hold: first, I'm prompted to login with my organizational ID (this is my msdn email), then after I enter my login for Azure, I automatically get logged into my application as live.com#myazureid@domain.com and I am not redirected to default.aspx but login.aspx and none of the web.sitemap menus appear other than the ones available to non-authenticated users. 毫无疑问,采用了另一种身份验证机制:首先,系统提示我使用组织ID(这是我的msdn电子邮件)登录,然后在我输入Azure的登录名后,我自动以live.com#身份登录到我的应用程序中myazureid@domain.com,但我没有重定向到default.aspx,但是login.aspx和web.sitemap菜单中的任何一个都没有出现,但未经身份验证的用户可以使用。 I also created a second user in the portal jeff@mydomain.onmicrosoft.com and I am prompted to login thru live then I am autologged into the application. 我还在门户网站jeff@mydomain.onmicrosoft.com中创建了第二个用户,并提示我通过实时登录,然后自动登录到该应用程序。 Basically it acts like windows authentication is active, not forms auth. 基本上,它的行为就像Windows身份验证处于活动状态,而不是表单身份验证。 (Clarification: I found out later that this behavior is Azure Active Directory.) (澄清:稍后我发现此行为是Azure Active Directory。)

In contrast, when my application runs locally (vs.NET 2013) with my connection strings pointing to the same sql azure data source (the membership tables) I login as I'd expect: I enter my membership username/password and I see my default page and pages tied to my roles are accessible, the user exists in users table, etc.. Obviously my local runtime environment and azure are different and it seems that Azure is somehow overriding my web.config provider settings and using its own mechanism. 相反,当我的应用程序在本地运行(vs.NET 2013)时,我的连接字符串指向相同的sql azure数据源(成员资格表),我按预期登录:输入成员资格用户名/密码,然后看到我的默认页面和与我的角色相关的页面都可以访问,用户存在于users表中,依此类推。显然,我的本地运行时环境和azure不同,Azure似乎在某种程度上覆盖了我的web.config提供程序设置并使用了自己的机制。

My web.config: 我的web.config:

<authentication mode="Forms">
   <forms cookieless="UseCookies" defaultUrl="~/Default.aspx" loginUrl="~/PagesAnon/userLogin.aspx" requireSSL="false" slidingExpiration="true" timeout="45" />
</authentication>
<membership defaultProvider="AspNetSqlMembershipProvider" userIsOnlineTimeWindow="2">
 <providers>
    <clear />
    <remove name="AspNetSqlMembershipProvider" />
    <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="LocalSqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed" maxInvalidPasswordAttempts="4" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
  </providers>
</membership>
<roleManager defaultProvider="AspNetSqlRoleProvider" enabled="true" cacheRolesInCookie="true">
  <providers>
    <clear />
    <remove name="AspNetSqlRoleProvider" />
    <add name="AspNetSqlRoleProvider" connectionStringName="LocalSqlServer" applicationName="/" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</roleManager>

Thanks to Simon W above, I found my problem. 感谢上面的Simon W,我找到了我的问题。 In the Azure Portal, there is a setting that controls "Azure Websites Authentication / Authorization". 在Azure门户中,有一个设置可控制“ Azure网站身份验证/授权”。 Its found under Websites, then Configure, then scroll down a bit to "Azure Websites Authentication / Authorization". 在“网站”下找到它,然后进行“配置”,然后向下滚动到“ Azure网站认证/授权”。 In my case there was an entry there: my website was tied into the "Directory" for my account and the "application" was set to my "tenant" (I think that's the Azure term). 在我的情况下,有一个条目:我的网站绑定到我帐户的“目录”中,“应用程序”设置为我的“租户”(我认为这是Azure术语)。

To fix this, I simply removed the entry in the portal and I am able to login to my web application perfectly. 为了解决这个问题,我只需要删除门户中的条目,就可以完美地登录到我的Web应用程序。 Forms authentication wired up to Membership is working as I'd expect. 连接到成员资格的表单身份验证正在按预期工作。

I believe that I published the original website using VS.NET 2013 Publish (using Server Explorer with the Azure SDK tools installed) and maybe there is a default setting that enables Azure AD in that scenario. 我相信我使用VS.NET 2013 Publish(使用安装了Azure SDK工具的Server Explorer)发布了原始网站,并且也许有一个默认设置可以在这种情况下启用Azure AD。 I won't know until I retrace my steps and confirm this later. 直到我重新跟踪步骤并稍后确认时,我才知道。 When I create a new website using the Portal, it does not default to this scheme. 当我使用门户网站创建新网站时,它不默认为该方案。

Simon, I don't know how to give you credit for the answer... you basically got my head pointed in the right direction (just the use of "Azure AD authentication" got be googling the right terms) and facilitated the fix. 西蒙,我不知道该如何给您答案。您基本上已经将我的头脑指向了正确的方向(只是使用“ Azure AD身份验证”来搜索正确的术语)并简化了修复过程。

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

相关问题 Asp.net Web窗体Web应用程序中的Azure AD身份验证 - Azure AD Authentication in Asp.net web forms web application 使用Azure AD在ASP.NET Web应用程序中进行身份验证 - Authentication in an ASP.NET web application using Azure AD ASP.Net Forms身份验证提供程序问题 - ASP.Net Forms authentication provider issue 如何在 ASP.NET Web 应用程序中实现 MS Azure AD 认证? - How to Implement MS Azure AD Authentication in ASP.NET Web application through Forms? Asp.net Web Forms(非 MVC)azure 活动目录身份验证 - Asp.net Web Forms (NOT MVC) azure active directory authentication Forms身份验证应用程序中的ASP.NET Web服务 - ASP.NET Web Service inside Forms Authentication Application 使用表单身份验证为ASP.NET应用程序创建默认用户 - Create A Default User for an ASP.NET Application Using Forms Authentication 具有表单身份验证的ASP .NET Web窗体的MFA提供程序 - MFA Provider for ASP .NET Web Forms with Forms Authentication 在ASP.NET Web应用程序中使用自定义生成提供程序 - Using a custom build provider in an ASP.NET Web Application 使用 Azure AD 验证返回 401 - Sending a GET request to an ASP.NET Core Web Application API using Azure AD Authentication returns 401
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM