I have two asp.net applications on one IIS server and I would like to use the same back end asp_security database and membership provider. I've read that all I have to do is reference the same application name in both web configs as I'm doing now, but I must be doing something wrong
In each applications web.config I have this section.
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="membership"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
minRequiredPasswordLength="5"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
/>
</providers>
</membership>
When I log in from application A and browse to application B application B doesn't seem to know anything about me or my credentials from application A. Anyone have any ideas what I'm doing incorrectly?
Just for closure sake I will answer how I did achieved the goal of what my original question meant to ask for.
I had two asp.net applications on one IIS server. It was my goal to make it so when user logged onto app1 their user credentials would be available in app2. Configuring the asp.net membership provider is only one step of what I was looking for. Even if both apps were using the same back end database and provider I still wouldn't be authenticated when I hit app2. What I was looking for was a Single Sign On solution.
Once you have both apps pointing at your asp_membership database by placing the following in the system.web section of your web config
<authentication mode="Forms" />
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="membership"
applicationName="/"
/>
</providers>
</membership>
<roleManager enabled="true" />
make sure both have the same applicationname property set.
I was using IIS 6 so I configured it to autogenerate a machine key for both applications. Because both of these applications live on the same machine the key would be identical, this is the critical part to making the SSO work. After setting up IIS the following was added to my web.config
<machineKey decryptionKey="AutoGenerate" validation="SHA1" validationKey="AutoGenerate" />
That was all there was to it. Once that was done I could log into app1 and then browse to app2 and keep my security credentials.
Thanks for the push in the right direction.
If my understanding serves me correctly, the users authentication credentails are stored within the HTTP context of each application. So switching between the two applications will not automatically authenticate the user, since a new context will be created when you switch to app B.
What I believe may the correct approach would be to use the DefaultCredentials (or UseDefaultCredentials property to True) of the current user prior to switching to app B.
When you say switch what do you mean eg. open a different browser window and access app B or request a page from appB from appA?
Related
I have a database which is created using Forms authentication in asp.net but now i want to develop an other application which uses the same user names and passwords and should be able to login to the new App which is developed using MVC 5 Aspnet Identity. So i want to be able to authenticate the user in the new App using their old creds.
My old database structure
I know that Asp Identity Individual Authentication mode will generate other set of tables i would also like to stop this default behavior as i don't want Iddentity tables created in the old Db.
PLease guide me how could i achieve this. Thanks
Web Forms and MVC both use ASP.NET Membership by default. If your old application uses a membership provider it should be fairly easy to adapt it to MVC. If not, you have the option of either creating a new membership provider that uses your existing database or replacing the authentication mechanisms of the MVC application.
I recommend this as a starting point for your research: http://weblogs.asp.net/jongalloway/asp-net-mvc-authentication-customizing-authentication-and-authorization-the-right-way
Alternatively, there are a variety of ways you could migrate user accounts from the old application to the new MVC application. If backward-compatibility with the old application is not necessary, this may be your best (simplest) option.
So After the things i have tried. i have got it working.
1) Install the nuget package for web providers
Install-Package Microsoft.AspNet.Providers.Core
2) Cop these web config sections and add them in web config under Section
<profile defaultProvider="DefaultProfileProvider">
<providers>
<add name="DefaultProfileProvider" type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" applicationName="/" />
</providers>
</profile>
<membership defaultProvider="DefaultMembershipProvider">
<providers>
<add name="DefaultMembershipProvider" type="System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="/" />
</providers>
</membership>
<roleManager defaultProvider="DefaultRoleProvider">
<providers>
<add name="DefaultRoleProvider" type="System.Web.Providers.DefaultRoleProvider, System.Web.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" connectionStringName="DefaultConnection" applicationName="/" />
</providers>
</roleManager>
3) Point your default connectionString towards the existing DB which consists users or you can add new connection string and use that name in the above web config sections replacing "DefaultConnection" with "newConnection"
Now you are good to go.
Just verify the Validity of the user by Membership.ValidateUser("username","password")
I have a Sitecore site where I want to have website visitor accounts stored in an external asp.net membership database but keep Sitecore content editors/admins managed via the Sitecore interface (and hence stored in the 'Core' database).
I've read through the following forum post
http://sdn.sitecore.net/SDN5/Forum/ShowPost.aspx?postid=35305
in which the following documents are mentioned
http://sdn.sitecore.net/upload/sitecore6/62/membership_providers_sc62-a4.pdf
http://sdn.sitecore.net/upload/sitecore6/62/security_api_cookbook_sc60-62-a4.pdf
http://sdn.sitecore.net/upload/sdn5/modules/ad/low-level_sitecore_cms_security_and_custom_providers-a4.pdf
but none of these seem to provide a complete picture of what I need to do.
I've currently got the the <membership> section set up to use the 'switcher' provider (with a corresponding provider pointing to my membership DB) and the <roleManager> section also set up to use the switcher provider again with a corresponding provider pointing to said membership DB.
So far I have only succeeded in breaking the user manager in the Sitecore desktop (it throws either the exception Item has already been added. Key in dictionary: 'extranet\Anonymous' Key being added: 'extranet\Anonymous' if Sitecore has created the extranet\Anonymous account, or Object reference not set to an instance of an object. if I've deleted that user account.
As background information I'm using Sitecore 6.5 and the relevant section of my web config is as follows
<membership defaultProvider="switcher">
<providers>
<clear/>
<add name="sitecore"
type="Sitecore.Security.SitecoreMembershipProvider, Sitecore.Kernel"
realProviderName="myProvider"
providerWildcard="%"
raiseEvents="true"/>
<add name="sql"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="core"
applicationName="sitecore"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="256"/>
<add name="switcher"
type="Sitecore.Security.SwitchingMembershipProvider, Sitecore.Kernel"
applicationName="sitecore"
mappings="switchingProviders/membership"/>
<add name="myProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
applicationName="sitecore"
connectionStringName="myDatabase"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="10" />
</providers>
</membership>
<roleManager defaultProvider="switcher" enabled="true">
<providers>
<clear/>
<add name="sitecore"
type="Sitecore.Security.SitecoreRoleProvider, Sitecore.Kernel"
realProviderName="myProvider"
raiseEvents="true"/>
<add name="sql"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="core"
applicationName="sitecore"/>
<add name="switcher"
type="Sitecore.Security.SwitchingRoleProvider, Sitecore.Kernel"
applicationName="sitecore"
mappings="switchingProviders/roleManager"/>
<add name="myProvider"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
applicationName="sitecore"
connectionStringName="myDatabase" />
</providers>
</roleManager>
The idea you should follow in the case of custom membership/role providers is similar to what AD module lists in its setup instructions. The entire process can be split into several steps:
Adding a connection string to connectionstrings.config
Adding membership/role provider definitions to the system.web section of web.config
Activating switchers
Creating a new domain for the users/roles from custom provider
Adding domain/provider mappings
Adding a connection string
This is pretty straightforward and it seems this is what you've done already. The point is to have a connection string to the database you can then reference from the custom providers.
Adding membership/role provider definitions
Another simple step - just add a membership provider definition (myProvider in your case) under system.web/membership/providers section in web.config, and add a role provider definition under system.web/roleManager/providers section. The order is not important. At this point, you do not modify any other provider definitions in the mentioned sections.
Activating switchers
This is where it becomes complicated. First off, DON'T CHANGE the #defaultProvider attribute value. It is 'sitecore' by default and it should stay as is. Instead, find the provider called "sitecore", and change its #realProviderName attribute value from 'sql' to 'switcher'.
The provider named "switcher" is responsible for all the magic behind switching the providers and combining the results of GetAll/Find methods.
Create a new domain
You should create a new domain for the users/role you'll take from your custom DB through your custom providers. Something like this:
<domain name="myDomain" ensureAnonymousUser="false"/>
The #ensureAnonymousUser attribute being set to false means that Sitecore won't add an anonymous user to your domain, so there won't be myDomain\Anonymous. This is usually the desired behavior for the custom domains.
Adding domain/provider mappings
This is the last step to let Sitecore know which domain is served with each provider. One provider can handle multiple domains (default Sitecore SQL provider stores the users from 'sitecore' and 'extranet' domains), but not vice versa.
So, open the main web.config file and browse to the configuration/sitecore/switchingProviders section. Add something like this for memberhip subsection:
<provider providerName="myProvider" storeFullNames="false" wildcard="%"
domains="myDomain" />
and the similar thing for roleManager subsection:
<provider providerName="myProvider" storeFullNames="false" wildcard="%"
domains="myDomain" />
After this, the users from your DB will be visible as 'myDomain\user' in UserManager, the same is true for roles. The #storeFullNames='false' means that your DB stores the users/roles without domain prefixes, just the local names. Wildcard should be the default value in case your custom source is SQL (which obviously is).
That's it, and now it should work! :-) The details of the steps above are described in this article.
I am just wondering
why did asp.net team choose / as the default value of Membership Role application name rather than the project name that makes sense?
In addition, the application might not be deployed as the root application. It means that / is no longer appropriate.
Edit 1:
For example: I create a project A first and deploy it. Later I create another project B and deploy it. If both projects use the default, they still work but it will be difficult to know which users come from each project.
For me, it is better if the default is set to the project name.
Edit 2:
I am talking about the applicationName attribute generated by Visual Studio in Web.config.
Why don't use the project name instead of / by default ?
<membership>
<providers>
<clear />
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="ApplicationServices"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
applicationName="/" />
</providers>
</membership>
<profile>
<providers>
<clear />
<add name="AspNetSqlProfileProvider"
type="System.Web.Profile.SqlProfileProvider"
connectionStringName="ApplicationServices"
applicationName="/" />
</providers>
</profile>
<roleManager enabled="false">
<providers>
<clear />
<add name="AspNetSqlRoleProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="ApplicationServices"
applicationName="/" />
<add name="AspNetWindowsTokenRoleProvider"
type="System.Web.Security.WindowsTokenRoleProvider"
applicationName="/" />
</providers>
</roleManager>
EDIT 3:
After creating two applications (i.e., one as the root and the other one as the child app) and both have the same applicationName set to /, both application use the same ApplicationID. It means the slash has nothing to do with site domain tree. My confusion has been answered. So... why did Visual Studio set it to / (that makes confusion for me) by default?
EDIT 4:
I have two applications. One as the root application and the other one as the sub application under the former. Both use applicationName = "/". I got the result as follow in database: So what is the meaning of /? If no meaning, why did VS choose this confusing name rather than the project name?
EDIT 5:
From this article, I will make the summary:
If we remove applicationName attribute from web.config for both applications, the ApplicationName generated in database for the root will be "/" and the ApplicationName generated in database for the sub app will be "/subappvirtualdir".
If we leave the applicationName to its default value of "/" for both applications, both root app and sub app will get the same ApplicatonName of "/" generated in database.
If we change the applicationName to "any name you want" for both applications, the ApplicationName generated in database will be set to "any name you want" for both applications.
Thanks Rockin for the link above !
I'd say that the default name is / because your DB is not supposed to know anything about your app. Therefore it doesn't know the project name. They have to have some sort of starting point, and since they're not mind readers, you get a /.
Remember, since you can use Aspnet_regsql.exe to create your ASP.NET Membership Scheme in your database completely independent from Visual Studio, the database can't just "fix" the application name all on it's own. You can of course edit the app name in the database immediately after creating the db, then it doesn't matter anymore.
EDIT
I see in your edit that you're talking about the applicationName in the web.config, and not the one in the database. Please read this blog article (not mine) for some more insights
http://dotnettipoftheday.org/tips/applicationName_attribute.aspx
An application does not generally know or care what 'project' it came from. So that context likely would not be present.
And if your app isn't at the root, then rename it...
I'm trying to plan a series of websites that all share many of the resources such as css/jscript/images/content etc. For this reason I wanted to run all of the websites under the same application and IIS profile, but depending on the URL being used change the masterpage and theme/skin.
The ASP.NET membership database seems as if it was designed with this goal in mind because it allows you to setup multiple applications, however I believe the purpose for which this was built was to allow applications to be run under virtual directories/folders, not on separate URLs.
Is it possible to map a url to a particular application?
Thanks in advance
Al
Yes it is possible to do this. In your configuration, use the applicationName for your providers. This way, all of the data will be saved in the same database, but kept separate by the Application Id that you will find in most of the tables.
One possibility for your shared resources can be to put them in just one location and you can point to that location from your other site by using a full url to the file in the first location.
Another possibility is to host one app in a virtual directory in the same domain, although you can get into some interesting issues with web.config inheritance doing this. It would help if you show your intended domain naming for the two applications.
In one application:
web.config 1:
<roleManager enabled="true">
<providers>
<clear/>
<add name="AspNetSqlRoleProvider" applicationName="/ApplicationOne"
...add other properties here as standard
/>
</providers>
</roleManager>
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider" applicationName="/ApplicationOne"
...add other properties here as standard
/>
</providers>
</membership>
In your other application:
web.config 2:
<roleManager enabled="true">
<providers>
<clear/>
<add name="AspNetSqlRoleProvider" applicationName="/ApplicationTwo"
...add other properties here as standard
/>
</providers>
</roleManager>
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider" applicationName="/ApplicationTwo"
... add other properties here as standard
/>
</providers>
</membership>
The easiest solution would be to include the style sheet depending on what URL the page is being executed on, using:
Request.ServerVariables("SERVER_NAME")
IE (pseudo):
if Request.ServerVariables("SERVER_NAME") = "http://www.domain1.com" then
include stylesheet1
else
include stylesheet2
end if
You would need to find a function to extract the domain name from the URL so it works well.
I'm new to User Roles Management. I was reading my Wrox Programming book on asp.net 3.5 user role management...but it was hard to follow along, as I do not have a local server set up to test on (I do...but...thats a separate question), but rather currently test on a remote server (where the website is hosted, theres not enough hits where I can get away with testing on a live server).
Any ways...Where do I begin in user role management. I'm not necessarily asking to be given a 30 pg hard description, but more of a summary. My GoDaddy hosting account seems to offer asp.net schemea SQL database set up for user role management, but I have yet to learn how to integrate it into my development.
Any input would be appreciated.
I would open up Visual Studio, create a new ASP.NET Web Application project, and click the "Configure ASP.NET" button on the top-right hand corner of the Solution Explorer. If you navigate to the Security section, you can start creating Users and Roles. The tool basically describes exactly how they work to you.
Here's the first place I'd go:
http://www.asp.net/Learn/Security/
Check out tutorials 9 through 11.
You can use SqlRoleProviders and SqlMembershipProviders with the .NET default management, or you can write your own providers.
http://www.odetocode.com/Articles/427.aspx
http://msdn.microsoft.com/en-us/library/aa478949.aspx
Then these are used in conjunction with asp .net forms authentication.
<authentication mode="Forms">
<forms name=".ASPXFORMSAUTH" loginUrl="~/Common/Login.aspx" timeout="450" />
</authentication>
<authorization>
<deny users="?" />
<allow roles="Admin" />
</authorization>
The configuration of all of this is via the web.config your membership and roles may be similar to this if you use the out of the box aspnetdb.
<membership defaultProvider="IDTSqlMembershipProvider" userIsOnlineTimeWindow="15">
<providers>
<clear />
<add
name="IDTSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="SqlMembershipConnectionString"
applicationName="ConsumerSynergy"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="true"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="20"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0" />
</providers>
</membership>
<roleManager enabled="true" defaultProvider="IDTSqlRoleProvider" cacheRolesInCookie="true" cookieProtection="All">
<providers>
<clear/>
<add
name="IDTSqlRoleProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="SqlMembershipConnectionString"
applicationName="ConsumerSynergy"/>
</providers>
</roleManager>
My personal favorite about roles.
Examining ASP.NET's Membership, Roles, and Profile - Part 2
https://web.archive.org/web/20210417083524/https://www.4guysfromrolla.com/articles/121405-1.aspx