I've read somewhere that ApplicationID is a unique id for a website (IIS site path). But I'm still confused.
When and why do I need this?
I'm trying to implement asp.net membership for a website and I'll create some additional SQL tables (such as Companies, Services, etc) other than asp.net membership tables. So; do I need to include an ApplicationID column to these custom tables? Why?
The application ID is stored in a the aspnet_Applications table in your membership database. When you first enable the ASP Memebership provider, the application name that you set in your web.config is entered into this table. From then on, the membership provider uses your application name to determine which users can login for user authentication in your app.
To answer your second question, no, unless you have a unique need/requirement to do so. Reason: The asp.net membership is setup so that you can host multiple possibly distinct applications using one membership database. This is nice in that you do not have to create a different database for each one of your sites for authentication. Unless you will have multiple/distinct applications hitting these other tables that you have mentioned, you do not need to worry about assigning the appID to them as your users are already logged in.
Related
I have an ASP.NET application that uses ASP.NET Identity 2.2. This was migrated from SQL Membership. In addition to using the AspNetUsers, AspNetRoles, etc tables the application also contains application-specific SQL Server tables which link back to Identity tables. For example, the SavedSearch table has a UserId column which contains values from AspNetUsers.Id.
Some customers now want the option to use their on-premises Active Directory (not Azure Active Directory or ADFS) for authentication. So the plan is to use Active Directory for authentication and Role membership etc will continue to be stored in SQL Server.
What is the best way to achieve this?
Authenticate with AD using DirectoryService Class. The following link will help to achieve this.
Active Directory With C#
A common field such as email of user from Active Directory can be used to map with Membership related table for Handling the Role scanario. Email may not be available for some AD Users , you may ensure both sides (AD & Membership) has same email
I created a DbContext connection using Entity Framework and have "DbContext" connection string in my web.config file.
Then, I tried to log in, and my website required me to have another "defaultConnection" string for creating user tables.
In this case, do I need to have two connections? Or should I have one connection by somehow combining the two?
Which is better performance-wise? I started building my project using Internet Application template.
By default for membership and roles, the ASP.net infrastructure uses the default membership and role providers that stores that membership and roles data in different database. Run your application and if you register for a user from login page you can see the database at location "App_Data" folder created. The database is different hence the connection string is different. You are using entity framework so there are 2 ways to go from here.
1) Change the connection string and use the same default asp.net membership and role providers to store data in the database that your entity framework configuration is using. By this I mean the default membership and role providers use the database that you EF configuration points to.
2) Use EF to manage the membership and roles data. So the users and groups would be entities manages by the DBcontext as other entities.
I have recently implemented the second approach. The ASP.net membership provides hooks (extensibility) to implement your own providers and register them in the web.config file. Then create the User and Role entity and include them in DBContext. Of-course before registering the providers you need to implement them first by deriving from MembershipProvider and RoleProvider abstract classes. These classes are in `System.Web.Security' namespace.
You can follow this project for more details http://codefirstmembership.codeplex.com/
I believe the connections to separate database will not have any impact on the performance. As in the web model even if you use same database for incoming requests we have to make connections to database separately and the incoming requests can come concurrent. In fact keeping the database separate will take to database load to another server. But now you have 2 servers to back up and maintain. This will not be maintainable unless you want your membership data to be separate for some reasons like it is shared by other applications also.
I would suggest combining the two, since at some point you will probably want foreign key's from various tables to the Users table.
I would have one connection in the web.config, "DefaultConnection".
Then when you initialize your DbContext, use the DbContext(string) overload to use the DefaultConnection, like so: var context = new YourDbContext("DefaultConnection");
That way your data and Users/Roles tables live together, happily ever after.
I have multiple websites and a Windows app that share the same database. Is there a way that I can manage the database username and password across all web.configs and app.configs? I'd like to be able to change the username and password, and then have all websites and apps use the new name. Is there something that I can use that will automate this? I currently store the username and password in a connection string.
You may have to write some custom code in your Windows app to support it, but ASP.NET Membership will let you share usernames and passwords among multiple apps.
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting
data) in Microsoft SQL Server, Active Directory, or an alternative
data store.
Authenticating users who visit your site. You can authenticate users
programmatically, or you can use the ASP.NET login controls to create
a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting
them . Depending on membership options you choose, the membership
system can also provide an automated password-reset system that takes
a user-supplied question and response.
Exposing a unique identification for authenticated users that you can
use in your own applications and that also integrates with the ASP.NET
personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to
substitute your own code to manage membership and maintain membership
data in a custom data store
Also, see this SO question for some additional info.
Keep the user name and password in the registry.
Build the connection string on the fly using a class
All web sites and Apps should have the same class
By the way, the registry is more secure than the web config.
I'm using the out of the box Asp.Net Membership functionality to handle my user management and role management.
My application consists of a single database for each client and each database has its own Membership provider and role provider.
However, there are some users who work for more than one of the clients and I want to be use a single login and let them choose which client to view. I have everything setup to facilitate this "client switching" by using an intermediate database that stores all usernames and a relation to which clients they have access to. I also have it setup so any updates to a user in one database will update all of the corresponding users in the other databases. All of this logic is working very well, except that I can't seem to figure out how to tell ASP.Net to change to a specific MembershipProvider and use that one.
The process I thought I should use is as follows (when the user switches the client in the clients dropdown):
Log the current user out
Tell ASP.Net which Membership provider to use (selected based on the client chosen in the dropdown)
Log the current user in using the selected client's membership provider and refresh/redirect to the page they were viewing when they changed the dropdown
I know how to get a reference to the specific membership provider (Membership.Providers[MembershipProviderName]), but I can't find any information on how to tell ASP.Net to change its membership provider. I'm not really even sure how the asp.net Login control does this in the background either - something that would probably help me out in all of this.
I've been searching SO and the web for awhile and can't seem to find much about doing this other than a few threads where people are trying to modify the DefaultProvider attribute of the Providers element in their Web.config.
This MSDN tutorial may help you.
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.