1
votes

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.

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.

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:

I created the sql membership tables on Sql Azure using special Azure-friendly scripts for Sql Azure (here: 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. 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. 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. Basically it acts like windows authentication is active, not forms auth. (Clarification: I found out later that this behavior is 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.

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>
1
Websites and Web Roles are just standard web servers so there is nothing special going on at the server level. You should check that you aren't doing a web.config transformation on build / package / publish that is adding in claims authentication in place of your existing forms authentication. - Simon W
Simon, thanks for the reply. I am indeed doing web.config transforms but I've double checked them and its only setting things like customErrors, debug, etc. I'm not changing authentication schemes during transforms and I'm looking at the web.config out on the azure site now and it contains authentication mode="Forms". Would there be some setting in the portal that controls the authentication mechanism? I've been scouring the azure portal for something like this but to no avail. - Jeff Mergler
Any use of System.IdentityModel nodes in your published web.config? Have you tried on more than one browser from more than one location? Has the URL you're using been used for other things in the past in your organisation? Have you tried publishing to a different URL? - Simon W
Hi Simon, no, unf a search in the web.config of IdentityModel finds no hits. I've tried IE, FF and Chrome on my workstation here at home and IE and FF from one of my servers that is 3 time zones away from my current location and the all exhibit the same behavior: first a prompt for my azure login followed by a redirect to the application and auto-login using the azure id. The url is brand new to me since I only published to Azure the other day. Sure, I can try re-publishing to another site in a bit. - Jeff Mergler
I would work backwards and start with a basic site with no authentication built in. The behaviour you describe is using Azure AD authentication which requires the application to be configured and registered for it. This is claims-based authentication and is different to traditional integrated Windows auth. Can you check for nested web.config files and if you have any make sure they aren't configured to use claims authentication (system.IdentityModel). - Simon W

1 Answers

2
votes

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).

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.

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, 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.