I have these roles:Admin, Doctor and Patient. But login information is stored in different table. Admin's username and password are stored in User_TABle(They are two items). Patient's Login information is stored in Patient_TABLE: PatientID, Year and DocumentID(They are three items). I want to use SQLRoleProvider and SQLProfileProvider. How can I design different login page with loginView?
Sincerely yours
I think a better setup would be this:
Use the standard MembershipProvider shipped with ASP.NET to use in conjunction with RoleProvider. Once this is setup and you have the roles you can store personal information for each either by:
Using ProfileProvider (not a bad method but requires a bit of work as you have polymorphic data (you would store it using XML in text field of the provider or write your own custom profile provider)
OR
Add a table similar to your schema but with a foreign key to the aspnet_Users PK. In code then you could do Roles.IsUserInRole("Whatever") and change the loginView appropriately. It would also mean you could just drag and drop the remaining LoginControl etc and have it just work with the standard membership provider
SqlRoleProvider, SqlProfileProvider and SqlMembershipProvider come with default Aspnetdb.
To create the database used by these providers, run the aspnet_regsql.exe executable found in the C:\WINDOWS\Microsoft.NET\Framework\ versionNumber folder. Otherwise, you have to create CustomRoleProvider, CustomProfileProvider and CustomMembershipProvider.
http://msdn.microsoft.com/en-us/library/system.web.security.sqlroleprovider.aspx
Related
I use .net membership but everything what i work i want to be custom.
What i want to do is:
Create custom data table [Users] with custom fields
Import current data into new table
Create custom classes and functions about everything what i need for [Users]
I`m not sure how .net membership works, but maybe it send encrypted cookie then when i use
var user = Membership.GetUser();
.Net decrypt user cookie and know which user is.
Here is a screenshot how .net create user AUTH cookie http://prntscr.com/97043
But everytime user logout-login, this value is different.
So what i want to know is:
Lets say i want to make 100% custom website, how i can make custom login?
Can you tell me all security issues about going for custom membership?
None of this is necessary. You can create your own users table without the need to alter anything related to Membership or authentication. You just make sure that your users table has a column called AspNetUserID or similar of type uniqueidentifier (a guid) . You put the ProviderUserKey from the MembershipUser in this table and lookup any user in your Users table simply by getting the ProviderUserKey from Membership.
So, for example, you might do this:
var userid = Membership.GetUser().ProviderUserKey;
// lookup your record in users based on userid above
Implementing a custom backend isn't difficult. You simply implement a custom MembershipProvider that stores and retrieves the data from your users table as you see fit. see MSDN. Also, you don't have to entirely rewrite SqlMembershipProvider, you can subclass it and add the functionality you're looking for.
If you really want to start from scratch on the backend, here are some issues to note:
Don't store passwords in plaintext anywhere; hash them.
Salt your passwords
Log & monitor password resets
Also, you don't have to entirely rewrite SqlMembershipProvider, you can subclass it and add the functionality you're looking for, and most of the issues you might run into will be covered by the default implementation. You'd probably just have slightly modify the data access calls or stored procedures to map to your table structure. You can also subclass the SqlRoleProvider to provide role-based authorization for your site with little additional effort.
As for the front-end component, MSDN also describes how forms authentication works, but personally, I wouldn't mess with your own cookie scheme. Even big custom implementations like Oauth for asp.net still use forms. Check out http://msdn.microsoft.com/en-us/library/system.web.security.sqlroleprovider.aspx
I am starting a new ASP.Net MVC 3 app and I'm hoping to be able to use the built in Membership provider.
The issue I have is that my application can be used by various organizations and it is important that the information shown is only applicable to the organization the user is working for.
The no brainer approach would be to insist all users use their email addresses as their username so everyone is unique and can be associated with their respective organizations. The problem is, some users don't have email addresses so there is no reliable way of ensuring unique names and I don't want people to know the Usernames already in use by different organizations. (USernames should only be unique to the Organization, not the entire app)
Ideally, I would want the User to enter their organization name in one field, then their username in another (and then the password!)
So we could have Jane login from one organization.....
Organization Company1
Username Jane
Password ********
and then someone else also called Jane could login from a different organization..
Organization Company2
Username Jane
Password ********
So my question is, what is the best way of modifying the Membership system to allow for this extra field?
I'd go about writing a custom MembershipProvider to suite the requirement.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
The provider pattern used by membership is designed so that you can extend it. You can inherit from the default provider and from the default membership use class to add the fields you need. This saves you from having to write a provider from scratch. As #mare pointed out, there are potential pitfalls though.
I would overcome these by perhaps having a login form that prompts for organisation, username & password, but behind the scenes combine the org & username & use that as the internal username.
The built-in (default ASP.NET) membership provider does not provide a concept of an Organization/Company/Firm or Department. You will have create your own tables in the database for those with a foreign key to the aspnet_users table to be able to store that additional information (I wouldn't go changing the default aspnet_users table because it might make it incompatible with the current default provider or future ones). You will then need to use the default provider for the default functionality and create a Service class to support the extended functionality. I know, I have done it. It gets complicated and dirty, takes time but it's completely doable.
Most likely you will end up creating your own provider and that starts with the requirement to support Users in Companies. In case you thought that changing the default provider to support that wouldn't be necessary. The requirement about uniqueness within the company is another one you will have to implement.
I think there is a built in option in the membership. look into the APPLICATION field in table my_aspnet_users.
reference here:
http://msdn.microsoft.com/en-us/library/system.web.security.membership.applicationname.aspx
I havent worked on ActiveDirectory Membership provider earlier, I have a doubt on creating an application using AD membership provider. If I need to foreign reference a user in a different table(lets say a custom role table ) then what primary identifier(Foreign key) should I use to identify the user in the the table which holds the relation of Role and the users.
Also , where is the additional information(other than AD details) about the user is stored like User Name, Department, Current project etc.
Is a snapshot of Active directory taken frequently and stored in a table in the database which is then used in sql joins?
The base membership provider (and derived providers such as the ActiveDirectoryMembershipProvider) uses UserName as a functional key (queries for members expect UserName as the key query parameter and return a single MembershipUser object). Those queries return MemberShipUser objects that have basic membership information—including roles, email, comments, etc. If you want to combine the ADMembership Provider with extra information, you're best off using the UserName as the key to do so. Storing extra data is easier if you use a database because .UpdateUser only commits Email, Comment, and IsApproved properties.
And no, snapshots are not taken, though you can enable caching if you wish. The provider queries AD directly when it needs the information.
The aspnet membership database when created resides in App_Data folder and is quite handy as it supports all the Login controls very well. The user roles can be very well managed by the aspnet configuration manager. The profile properties are managed all by the the database itself.
The database thus created can be seen in the server connections. If you analyze the datatbase you will see that every user has a specific userId apart from the username. Both of them are unique. You need not copy all user data in other tables. You can specify the related data using joins. Once a user is logged in, you can refer him/her by User.Identity.Name (c#) in your code behind.
Kindly view the database tables using the Server Explorer in Visual Studio and you can view the tables structures -- aspnet_Users, aspnet_Membership, aspnet_Profile etc...
I've done MVC in the past, but I am new to ASP and ASP MVC. I really love the ease that ASP MVC provides me, so far, but I am having trouble figuring out how to get more control over the Users. By default, the MVC provides a minimal user registration form. I have looked around quite a bit, but I still have two questions:
How do I make the User data base a local database in my project? I think SQLEXPRESS is used to store the user values, in what seems like a magical process. How do I de-magic-ify this? I would like to have more control on the location of this database.
This leads to another question: How do I expand the User? I have been reading up on Profiles, but I am still confused about a few things. How do I prepare a Profile and link it with a User? What serves as the foreign key? And, in my controllers, how can I access various parts of the user like username, email, or even from the profile stuff like firstname, lastname (though I guess once when I have a Profile's database and a User's database locally, I can run sql commands to retrieve data)
I would really appreciate some pointers to the right resources, and/or best practices with ASP.NET
I would start by reading this official Microsoft article on extending the ASP.NET Membership API. It talks about creating extra tables for storing additional information about users.
The membership database
If you have an existing database which holds all your other website information, you can run the aspnet_regsql.exe tool to generate the necessary user tables. You will then need to modify your web.config and add the SqlMembershipProvider along with your connection string.
If you're creating a new project and don't have a database, start with a new MVC project which already has Membership enabled. Your database will be created inside the App_Data folder on first use, and you can take this and attach it to your SQL/SQLEXPRESS server. Then it's just a matter of changing the connection string to use a DB server rather than a local file.
Creating additional tables
This part is actually quite simple and consists of a few short steps:
Create a new table, i.e. UserProfiles
Add a uniqueidentifier column as your primary key, and add a foreign key to the aspnet_Users table
Add any other fields you want to store (Phone, Address, Gender etc.)
If you're using LINQ-to-SQL or the Entity Framework, you can simply drag the tables you need onto the designer, and you'll be ready to query the Membership tables.
Here's a little sample on usage
Add this snippet to your repository responsible for Profile/Account information.
public aspnet_User GetUser()
{
MembershipUser user = Membership.GetUser();
return db.aspnet_Users.SingleOrDefault(u => u.UserId == user.ProviderUserKey);
}
Then inside your models, you can get the user and access the other information stored in your UserProfiles table.
AccountRepo accountRepo = new AccountRepo();
aspnet_User user = accountRepo.GetUser();
string Address = user.UserProfile.Address; // bingo!
And that's pretty much it!
This is obviously a simple example, and you should be checking if the user is null and you could also create a class responsible for returning the necessary information about a user, implement caching, etc..
I would start from here:
Managing Users by Using Membership
Managing Authorization Using Roles
Also a great article series (18 articles!!!) is from Scott Mitchell at 4GuysFromRolla.
The ASP.NET membership model is desgned to have a pluggable architecture. You can write you own MembershipProvider implementation that best suit your needs.
Even if most of the samples you will find on the net regards ASP.NET web forms, there are only very small differences when used with MVC.
If you're still looking for insight into this, I just ran across the fact that in MVC 4 WebPages sites, there's a provider called the SimpleMembership provider. It gives more control to the developer of the Users, Roles and Membership info stored on websites. More here:
http://blog.osbornm.com/archive/2010/07/21/using-simplemembership-with-asp.net-webpages.aspx
I'm trying to design an entity model for an application that uses ASP.Net membership for it's user authentication. In most of the database schemas I create, records typically end up related to users via the UserId field on the aspnet_users table. That's worked fine for me in the past, but now that I'm using EF, I'm having some conceptual issues with figuring out how I'm going to reference the user from an entity.
For example, let's say we have a "post" entity that contains a "postedBy" property. I'd LIKE to be able to do get the username of the user that created this post with something like post.user.username, but I'm wary of creating an entity based on the aspnet_user table for fear of creating a model that let's me bypass the Membership class when making changes to the database.
I've considered just leaving the post.userId field as a guid and then requiring that any code that needs to know the username use that guid to get the user from the Membership class, but that seems "ineligant".
Does anyone have any recommendations for entity model designs that integrate with Membership? I'd be reasonably happen with a "read-only" user entity.
My advice is: "Don't."
Let me be more specific.
Using UserId as a mapped, foreign key ties your entity model not to ASP.NET Membership in general, but to the SQL Membership Provider in general. What happens if you then want to use domain authentication or OpenID?
Don't get me wrong: 99.9% of the time it's correct to tie DB references together with a foreign key. Heck, you could even do it here, but don't map it into your entity model. You need to keep a wall of logical separation between membership providers and your own data. You access your data through the EF. You access membership data through the membership API. The fact that they happen to live in the same DB because you happen to be using the SQL membership provider is an implementation detail.
Update: I've expanded upon this idea in a blog post.