I am currently writing an ASP.Net MVC Web Application that will use three items of information to authenticate a customer and allow them to login to a secure area to view their booking details. The three items are:
the customer's booking reference number,
the customer's surname and
the customer's booking date.
I am currently using session to track the login of the user. I would prefer to use Forms Authentication as it is tried-and-tested and more secure.
Is it possible to use Forms Authentication with this kind of login? The MembershipProvider class's ValidateUser() method takes in as parameters username and password. I guess I would need to write my own Provider to accomplish this.
You don't need to use Membership for Forms Authentication. You just need the enable Forms Authentication Module in the web.config file, set up your login page with whatever credentials you want and use FormsAuthentication class to set the cookie.
Here is a sample, it does use the password, but you can set the authentication logic to whatever you want - check DB with the three parameters you need, etc. Then use FormsAuthentication.RedirectFromLoginPage to set the cookie and send the user to the requested page. You do need a unique ID to identify a customer, cause that's what the module will use on subsequent calls to set the identity.
Simple Forms Authentication
Here is an MVC sample, it uses the FormsAuthentication.SetCookie method to do the same
MVC Sample
Related
I'm creating an app with a login page that compares the password with the password stored in the database. I'm using a superclass Person, with 3 subclasses: Admin, Trainer and Member. My goal is to get a login page, that redirects the person to a homepage, where they have an overview of their profile. If the person is an admin, they also have access to an admintools button, which takes them to a new page with admin-only tools.
During class we learned that Asp.Net has built-in role authorization and a registration/login page by default. The problem is that we need to keep track of users, their password, location, their role,... in a database and I have no idea if this is possible with the default login/registration/roles.
Passwords aren't created by the user, but are instead handed out by the admin, who also has to keep track of users and their password.
Is it possible to keep track of all those things with the default registration/login page and would using those defaults be better than creating my own loginpage? If it's better to create my own loginpage, wouldn't that cause me trouble with role authorization?
Identity covers all your mentioned requirements and many more. More importantly, it is highly customizable. So, I personally recommend using Identity and customize it whenever you need.
I'm about to start working on an ASP.NET (C#) website project which requires users to authenticate and I've run into a bit of a design issue. I am required to use a SQL Server database to store the web app's data (to include user's login data), but all of the information I've found regarding ASP.NET and authentication uses Windows Authentication.
Now of course I could just write the code to query the database and check the users input against the database to see if the username/password exists (the current plan), but then how do I set the state of the session to authenticated along with other data (such as a user ID) so that the site can give the user only their data?
First, read more on Forms Authentication. You couldn't have really missed that (could you?) but it's the other major authentication mechanism that doesn't involve Windows accounts, instead the session is maintained with the help of a cookie that stores the user name together with any other so called user data (could be user ID or whatever else).
Second, the Membership/Role Provider mechanism is available for like 10 years - and it gives you an abstraction you implement on your own. The abstraction is about storing users/passwords/roles. The Membership/Role Provider is nowadays slowly replaced with the Identity 2.0 framework and you are free to choose the olderone or try the newer.
These two together, Forms Authentication and Membership/Role Provider, make a foundation of what you need.
The basic flow is as follows:
users request various resources ("pages")
some resources are guarded from anonymous access and require authentication/authorization
the Forms Authentication module redirects requests to such resources to a login page (login view)
in the login page you use the Membership/Role Provider to verify user and issue a Forms cookie
you redirect back
The Forms authentication module now picks the cookie upon every request and recreates the identity so that the user is authenticated when your server code is about to run.
I'm trying to implement "Act As" functionality for an ASP.NET application while at the same time using Windows Authentication and a custom role provider. Essentially what I want to be able to do is:
Use Windows Auth to get the current user's domain account to verify they are an approved domain user
Use a custom role provider to get permission information from a SQL Server database.
Implement functionality to allow the admins of the application to be able to "act as" another user, without requiring them to actually log into the application as that user.
The scenario I'm trying to fulfill is that an application admin is attempting to assist a user with a problem and clicks the "act as" button to act as that user and see the application as they would see it. So the Role Provider would need to understand that the current user is acting as someone else and get permissions information for that user instead of the current user.
My plan was to implement an impersonation feature that would delete the roles cookie and add a value to a session variable indicating that the user is currently impersonating another user. As the session is not populated at the time that authorization occurs however, this isn't possible. I don't want to use cookies as I don't want this to cause a potentially persistent state on the admins machine (such that the admin couldn't open another window to the app and either act as another user or view their own data).
I can't find a good way (without cookies) to save the "Acting as user..." information given that the session is unavailable. I'd like to use the role provider, etc., so that I can leverage the built in security trimming in .NET. This all may simply be impossible, but I'm hoping someone out there has either tried this before or has a suggestion for something I can attempt to implement.
Thanks in advance!!
See my answer to a similar question here
The gist of it is:
The way I did this, which is admittedly a little crude, was to have an
impersonation table in my database which contains the logon name of
the user who is doing the impersonating and the logon of the user they
wish to impersonate.
I added some override code so that when the user first goes to the
page (it uses Windows authentication), it will check to see if that
user has an impersonation set in the table and then place this user id
in an object in the session state. If there was no impersonation, it
would place the actual user id in this same object.
To prevent me from doing things to the user's data as them, there are
two properties in this object, one for logon_name, which is what is
used by the system for content-customization, and another called
NameForLog, which is used when logging any actions. All actions I make
will be logged as me.
All areas on the site that display user-customized content look at
this session object, so they will always use the impersonated ID and
therefore always show me what the user is seeing. Beyond the first
page and the logging code, it doesn't even know that it is me it is
dealing with.
For your scenario, you could implement a roles provider and override GetRolesForUser to return the roles for the impersonated user plus some role that will allow the impersonating user to access the impersonation functionality for the purposes of turning it off.
You could even return the impersonated user's roles with the impersonating user's roles in order to give the admin user access to all of their own features as well as the user they are impersonating, it all depends how much this would affect the usefulness of the feature in your particular scenario.
I have implemented something similar...though not exactly like your scenario but pretty close.
Admin Login (Has one role like Admin)
Then admin is redirected to "Select Client" Page. Admin can search Client by ID, Name, etc. From the list Admin selects a Client. I store the client ID in a cookie.
I have custom RolesProvider that calls my custom GetRoles(loggedinUserid);
GetRoles(int loggedinUserId) method then determines the type of the user i.e. if it's Admin or non-admin. If it is admin then, fetch ClientID from cookie. Pass loggedInUserID, typdofuser and ClientId to the stored procedure that will return all roles for the admin + all roles for that ClientId and return to roles provider.
This way I have all my menuitems for Admin available as well as menus needed for ClientID.
Admin can go to "Select Client" page anytime and switch to another client. When they select a client, new ClientId will be stored in the cookie.
Now you have two options after this:
You can let rolesprovider call this upon every request or
Store the fetched roles in HttpCache and update this cache whenever ClientId is changed.
Hope this helps.
I have already created a form authentication application. I had User table and created a custom membership provider. My user table has relations with other tables such as roles and permissions.
I change that to work using Windows Authentication. It looks easy but I have no clue how to still be able to read permissions from my tables? some tables are related to User table and requires user id, what to do here? should I break the foreign key?
If a user is accessing the page from LAN, s/he should get logged automatically, but if they accessed the application over internet, I should allow them to login? How to do this? What passwords should they use to login (active directory or my User table)?
I hope i get simple and easy answers.
Regards
In your controllers you can use User.Identity.Name to get the users AD username. You can then add a field to your users table called ADUSername (or update the values in the existing username field) so that you can link the logged in user to the existing user record in your database.
You don't have to do anything, if the user is accessing it from an external network or any machine that is not on the domain the browser will pop up a username/password prompt.
If you use Windows authentication, the user is going to be prompted for credentials just to access your site. You won't be able to prevent that. They won't even get to your code until they are authenticated.
We've done similar things using SSO (single sign-on), though I've never tied it to Windows authentication. The idea would be that you have two apps that share user credentials and, if you are logged into one, you are logged into the other. The first app would be your normal application which supports forms-based authentication. The second would be an app that only does Windows authentication and then, upon successful login, redirects to your normal application. Since you're already authenticated, the normal application simply creates it's standard authentication cookie and takes you to the main page of the application.
Typically these work by passing a token in the URL which you can then redeem via a back channel to the SSO server (or, in your case the Windows authentication server) to confirm that the token is authentic. The response to the back channel call contains the user name and other pertinent details if the token is successfully redeemed.
A sketch of the process might look like:
Get request to protected action on site.
If not authenticated, redirect to login site without token
Your login site contains both a forms-based login form and a link to the Windows authentication url
User clicks the Windows authentication url
Windows authentication site authenticates, creates a one-time use token in DB for user, and redirects back to your login action with token
Your login action redeems the token via back channel WebRequest to the Windows authentication server.
Windows authentication server validates the token, marking it as used, then returns the username to your login action.
Your login action creates standard forms authentication cookie and continues as normal.
Hi i am new person in asp.net webservice. I want to give user name and password in my web application the authentication performed by comparing username and password from webservice instead of comparing to database. Can anyone able to help me it will really appreciated.
Thank you,
You should use Forms Authentication - on click of login button on Login Form, you need to validate user supplied credentials by making the web service call. In case the credentials are correct then you can use FormsAuthentication.RedirectFromLoginPage to indicate authentication success to ASP.NET runtime.
Yet another variation (along with Forms Authentication) will be to use custom membership provider. See this MSDN link to understand how membership works. Then you have to write a custom membership provider that will use the web service to validate user.
Are you developing the webservice or it is done by someone else.
What is the functionality that you would be doing in Webservice.
I think you are trying to compare the username and password submitted with the
values stored in the database through webservie isn't it?
If you want to compare only in webservie or any page without using the database then I think you have to hard code the useername and password and simply do string comparison.