在Azure上使用SqlMembership Provider和Forms身份验证连接ASP.NET Web应用程序 [英] Wiring up ASP.NET Web Application using Forms Authentication with SqlMembership Provider on Azure

问题描述

我正在尝试使用Microsoft Azure门户，以查看我的旧应用程序如何以最少的重写量执行.身份验证是个问题.

I'm experimenting with the Microsoft Azure portal in order to see how my legacy application performs with the least amount of rewrite. Authentication is a problem.

背景:此ASP.NET Web应用程序当前使用SqlMembership Provider用于用户，角色，配置文件和个性化.是的，关于ASP.NET身份，简单成员资格，通用提供程序的博客很多，而asp.net SqlMembership Provider也正在逐步淘汰.但是，如果可能的话，我还是宁愿在Azure上使用旧版asp.net成员身份.

Background: this ASP.NET web application currently uses the SqlMembership Provider for Users, Roles, Profiles and Personalization. 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. But, if possible I'd still rather use the legacy asp.net membership on Azure.

当前，我可以将VS.NET 2013解决方案发布到Azure，但无法登录.导航到该URL后，它将自动以Azure门户用户身份登录. Windows身份验证似乎是活动的，而不是形式的.这是我到达这里的方式:

Currently, I am able to publish my VS.NET 2013 solution to Azure but I am not able to login. As soon as I navigate to the url, it auto-logs me in as the Azure Portal user. It almost appears that Windows Authentication is active, rather than forms. Here's how I got here:

我使用适用于Sql Azure的特殊Azure友好脚本在Sql Azure上创建了sql成员资格表(此处: https ://support.microsoft.com/kb/2006191 ).

I created the sql membership tables on Sql Azure using special Azure-friendly scripts for Sql Azure (here: https://support.microsoft.com/kb/2006191).

但是，当我在azure站点上运行应用程序与在本地运行它时，我看到了不同的行为.毫无疑问，采用了另一种身份验证机制:首先，提示我使用组织ID(这是我的msdn电子邮件)登录，然后在输入Azure的登录名后，我自动以live.com#身份登录到我的应用程序中[e-mail]，但我没有重定向到default.aspx，但login.aspx和web.sitemap菜单中的任何一个都没有出现，但非身份验证用户可以使用.我还在门户网站[e-mail]中创建了第二个用户，并提示我通过实时登录，然后自动登录到该应用程序.基本上，它的行为类似于Windows身份验证处于活动状态，而不是表单身份验证. (澄清:我后来发现这种行为是Azure Active Directory.)

However, when I run my application on the azure site vs. when I run it locally I see different behavior. 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#[e-mail] 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. I also created a second user in the portal [e-mail] and I am prompted to login thru live then I am autologged into the application. Basically it acts like windows authentication is active, not forms auth. (Clarification: I found out later that this behavior is Azure Active Directory.)

相反，当我的应用程序在本地运行(vs.NET 2013)时，我的连接字符串指向相同的sql azure数据源(成员资格表)，我按期望的方式登录:输入我的成员资格用户名/密码，然后我看到我的默认页面和与角色相关的页面都可以访问，用户存在于users表中，依此类推.显然，我的本地运行时环境和azure不同，Azure似乎以某种方式覆盖了我的web.config提供程序设置并使用了它.自己的机制.

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.

我的web.config:

My 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>

推荐答案

感谢上面的Simon W，我发现了我的问题.在Azure门户中，有一个设置可控制"Azure网站身份验证/授权".在网站"下找到它，然后进行配置"，然后向下滚动到"Azure网站认证/授权".以我为例，那里有一个条目:我的网站绑定到我帐户的目录"中，应用程序"设置为我的租户"(我认为这是Azure术语).

Thanks to Simon W above, I found my problem. In the Azure Portal, there is a setting that controls "Azure Websites Authentication / Authorization". Its found under Websites, then Configure, then scroll down a bit to "Azure Websites Authentication / Authorization". 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).

要解决此问题，我只是删除了门户中的条目，并且能够完美登录到我的Web应用程序.连接到成员资格的表单身份验证正在按预期工作.

To fix this, I simply removed the entry in the portal and I am able to login to my web application perfectly. Forms authentication wired up to Membership is working as I'd expect.

我相信我使用VS.NET 2013 Publish(使用安装了Azure SDK工具的Server Explorer)发布了原始网站，并且也许有一个默认设置可以在这种情况下启用Azure AD.直到我退后一步并稍后再确认时，我才知道.当我使用门户网站创建新网站时，它不是默认使用此方案.

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. 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)，我不知道该如何给您答案....您基本上是将我的头脑指向了正确的方向(只是使用"Azure AD身份验证"来搜索正确的术语)并为您提供了便利解决方法.

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上使用SqlMembership Provider和Forms身份验证连接ASP.NET Web应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！