Can you guy send me a good example that they will verify my userid which it from window login workstation and match a list of userid in table in SQL Server? I am using IIS and they are both in same server but different machine. If my userid is not match one of those userid in table then it automatic prevent me from going in specific website. I do not want login or form. I just want automatic detect my userid before allow me to enter website.
What authentication mechanism are you using on the website? Forms? Integrated? Certificate mapping?
In the end, the authentication mechanism will generate a cookie which you can reference in code via HttpContext.Current.User.Identity.Name.
Your job is to figure out which authentication mechanism you are using and understand what the Identity.Name value is being generated by, since the authentication mechanism controls this and to synchronize the value in your user's table with this value. It does not necessarily need to be the primary key of the user's table; in fact security is slightly improved if you do not expose the primary key of the user's table at all. Any unique key will do; in general I use Guids because I can generate them independently and their sequence is (generally) not predictable.
Related
I've started an ASP.NET web site in Visual Studio using a Microsoft pre-defined template. This is to help me learn about OpenID within ASP.NET.
Inside the included SQL database within the sample site, there is a table called UsersOpenAuthAccounts that contains a column called ProviderUserName.
Can anyone tell me the purpose of this column? In my tests, this seems to store the username that I would log into an OpenID site with (e.g. my Google username - my email address). However, I also see that the ProviderUserId column holds the IAuthenticationResponse.ClaimedIdentifier value, e.g.
https://www.google.com/accounts/o8/id?id=AIt................g3c
...which would be used to identify the user against the OpenID provider for future requests.
Therefore, is there any point in including the ProviderUserName column? It's not actually used anywhere else within Microsoft's sample site.
ProviderUserName is... a bad idea (IMO).
The OpenID Claimed Identifier is the right string to check for return users. It reduces security to use anything else, including email address. If you're only interested in OpenID logins then you may want to just throw out the ASP.NET provided code and use DotNetOpenAuth's OpenIdRelyingParty directly and deal with the users table yourself. It will be about as simple as your current code, but without the unnecessary columns.
What the ASP.NET team's additional column and façade classes give you is the ability to mix OpenID logins with OAuth logins, which allow you to accept Twitter and Facebook accounts at your site as well. OAuth wasn't designed to be an authentication protocol, so those who use it have to make up their own idea of a username. In order for that to be globally unique, it must be prefixed by the provider who is issuing that username. So you have ProviderName ("twitter" or "google") and a ProviderUsername which is the username (or user id perhaps) of the account from the OAuth service provider.
I am building a multi tenant MVC4 web application. I distinguish the tenant based on the url alias (customername.webapp.net). I have a database that stores the customer id which I can lookup using the customername.
Obviously I need this customer identification during the entire session that a user from that customer is using my webapp.
Is it acceptable to store this unique identifier in the session? Or are there better design choices for this kind of "session data"?
I'd rather store this information inside the UserData portion of the forms authentication cookie (if you are using Forms Authenticatoin) or simply add it as a claim if you are using claims based authentication. When the user logs-in you would extract the tenant name from the current request, query your database in order to obtain the tenant id and then persist this id. If you store the id in the UserData portion of the Forms Authentication cookie you could write a custom [Authorize] attribute which will read the FormsAuthenticationTicket, decrypt it, get the tenant id from the UserData portion and then build a custom principal. This way you will have it available everywhere in your application. If you use claims based authentication, you would simply add it as a new claim.
I wouldn't use Session at all inside my application.
Please don't be misguided by the answer. It is dangerous to use cookie.
Session in this case would be the valid option, not cookies. If you store your tenantId inside your cookie, and your application establishes database connection based on your cookie, then after you login as a user, you can tamper and change the cookie and now your application will make connection to another database thereby compromising security. Even if your cookie is encrypted, it's not 100% reliable.
Session in this case would be the reliable server information that keeps track of which tenant database should be connected to. Although session can be a performance drop compared to cookie, in this case you have no other good options. You are designing a multitenancy application and that's just something you have to sacrifice.
Yes, you may still able to use cookie if you REALLY want to. You just have to keep checking if the user is connected to the right database somehow, which to me is more of a performance drop than using session.
Don't hate session just because alot of people abuse it or hate it. You just have to use it in the right manner.
Bottom line is, if you are using any info for security purposes, don't use cookie.
Here is my problem if i can call it that way.I have implemented authentification with custom memebership provider in asp.net mvc 2.0.Everything works well but i have one problem.When user log in he provides its username and password and i check this through databse in MSSQL then i validate user and pass and use FormsAuthentication to set only UserName as profile information.
But when that user wants to create new item(lets say for sale or something) that belongs only to him and can be listed with other items that user created i can use this username(in FormsAuthentication) check it in database and connect that item to appropriate user with foreign key but that works if username is unique so i need additional informations like ID column from database table "user" to store and use it later so what is the most secure and "best practice" way to store additional information of user and use it later because username as i mentioned must be unique in database and it is not enough information about logged user.
Couldn't you store the User object (or whatever additional info you have) in the Session? or using a cookie at the client side (if you need to persist the login state even after the user closes his browser etc)? Let me know if you need specific examples.
EDIT: After reading your comments, if you are looking for a "secure cookie" solution have a look at this: http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
I use it to store the user's id (only his id). When I retrieve this cookie I load the user given his id. Some in-memory caching allows me to avoid loading the user on each request.
But just wanted to clarify that the session object seems great for what you are trying to do + you dont have to worry about security (for the average app that is).
I was looking at linking my own User table to the asp.net membership by storing my userid (int) in the UserData area of the authentication cookie (Storing and accessing a legacy UserID in asp.net membership).
As my application is for my own use and also to help me learn asp/c#, I thought it might be a good idea to compare the effort of tweaking membership to fit my database with the reverse (i.e. use membership out of the box and adjust my database accordingly).
If I convert my database to use guid (uniqueidentifier) UserIDs as foreign keys in all my user related tables, then I still need a way to make the UserID easily accessible to my application. The accepted way to get the UserID seems to be like so:
Guid userID = (Guid)Membership.GetUser().ProviderUserKey;
Now, if I understand correctly, this involves a read of the database. Perhaps I'm being picky, but it seems a bit unnecessary on every request. I would be inclined to put it in the ticket. I can't see any problem with putting a PK value in the ticket (guid or int). Is there a security risk? Membership seems to be happy using the UserName as a key rather than the surrogate. Which begs the question - why didn't they put UserID in the ticket?
Cookies and URLs have practical maximum lengths - the FormsAuthenticationTicket.UserData documentation states:
"You should limit the amount of data stored in the UserData property.
You must ensure that the size of the UserData property does not result
in an invalid cookie or an excessively long URL."
ASP.NET can be configured to use cookieless forms authentication, which stores the authentication ticket in the URL. In this case the ASP.NET ISAPI filter also has to do a bit of extra work to strip the ticket information then rewrite the URL.
So part of the reason can probably be attributed to a trade-off of keeping the default cookie/URL lengths to a minimum - storing an encrypted, serialized Guid in the ticket would increase the length of the cookie/URL, and also further limit (granted not by much) the amount of data you can store in UserData.
You can always write your own UserPrinciple implementing IPrinciple which can give you the userID once and this can be called anywhere in the application without actually hitting the database.
Then you can use the userId in cookie if you still want to.
I have an Asp.net MVC project authenticating through AD. I would like to store audit information in tables for the current logged in user. What should I be storing in the database? I am currently using SamAccountName for my membership and role providers. Should I be using this? Should I use the more verbose and modern UserPrincipalName? What if we eventually end up using multiple domains?
What about Guid? Guid would seem like the obvious choice but I know nothing about it. Why is it nullable? Does this value change? What is it used for?
Update
According to SID vs. GUID ...
The reason for using SIDs at all, and not GUIDs, is for backward compatibility. Windows NT uses SIDs to identify users and groups in ACLs on resources.
SIDs will actually change if you move a user to a new domain, the GUID will remain
constant. It looks to me like GUID is the way to go unless you intend to authenticate against a NT4 AD server.
I'm not sure what to do here as I cannot accept my own answer for 2 days. Most in-depth explanation wins?
According to SID vs. GUID ...
The reason for using SIDs at all, and not GUIDs, is for backward compatibility. Windows NT uses SIDs to identify users and groups in ACLs on resources.
That being said, I've decided to go with GUID. SIDs will actually change if you move a user to a new domain, the GUID will remain constant. So long as you don't plan on running your application against an NT4 AD server, GUID is the way to go.
You might want to use the SID -- that's what the OS itself uses in most cases. SIDs are also unique across domains or workgroups.
The problem with user name alone is that it can be changed, whereas the SID is fixed.
If you are using ASP.NET MVC (or Webforms for that matter) with Windows Authentication, why not just use the user name that you get from this property:
HttpContext.Current.User.Identity.Name
This returns Domain/Username of the user. I have worked on corporate web apps that used this for auditing purposes. I would be curious to know if you think this is not unique enough for your purposes.
Also I'm not sure why you would want to store a SID or GUID of the user, as it is very hard to read compared to domain/user when you are viewing audit logs.
samAccountName is the user name the user uses to log in with. You can get a little more 'complete' by prepending the domain too, but there's no reason not to use the obvious username field.