we are going to build a asp.net web based application but are stuck at point where we are unable to decide what authuntication method should we used? (Active Directory Authentication or Forms Authentication Provider)
80% of the application is going to be used inside the company(all the users are part of active directory) and rest 20 is going to be used from outside. This application is going to have intense permission based on user(probably control level. i.e. a grid might have differet column for user A than user B on same page)
I am just wondering what is the best way to go?
There is no reason why you can't use LDAP with Forms Authentication. I do it all of the time. Basically, I use the LDAP to authenticate the user and grab any groups that they are in which are relevant to my application. I use forms to manage the cookies and application specific permission. You can provide an alternate form of authentication as you so desire, you just need to provide a way for your application to know when to use the LDAP or the alternate method.
Many companies maintain very tight control over who can manage their LDAP permissions (and rightly so). Depending on how often you need to add/remove/change permissions for users, and how much red tape and pain you need to go through to make those changes in the LDAP system, that may represent a significant drawback to that approach.
Obviously, that shouldn't be your one and only decision point - but it's probably worth including in your pros/cons list.
I wouldn't use LDAP for authentication. It's easy to implement, but logging is less reliable because the user cannot simply log off the application, which means that if someone else comes on and starts making changes, those changes will be tracked to the user who was logged into the computer. Users should be able to click a "Sign out" button somewhere on the page and be done with it.
You can use the Windows identity with FormsAuth, which seems to strike a comfortable medium between the two approaches. The good thing about windows authentication is that it forces consistency with usernames between the application and the domain, but there are circumstances where that's not a good thing either.
Related
I often have a need to secure a single page (i.e. Reports) on a public facing app so that only authorized users may access the page. In the past, this mean setting up a custom login form or using the ASP.NET membership provider or something else far too complex to serve the purpose. Is there an easier (safe) way to secure a single page in this fashion?
Some things I've considered:
Client certificates (initial setup is a pain)
A single master password (works in a pinch, but feels dirty)
Restrict access by host address (cumbersome when the need arises to allow external users access to the page). Also, need to support access via proxy (X-Forwarded-For) which can be faked by technical users)
Are there other options? Recommendations?
You can do it in your web.config file something like what is suggested here. As far as authentication is concerned the easiest way is to use windows authentication.
A login system is your best option. If you don't want to go through the trouble of setting up and managing a login system yourself, consider using OpenAuth.
You can achieve functionality pretty easily using DotNetOpenAuth. Users can then log in with their Google, Yahoo, StackOverflow, etc. accounts, and you get a token that you can store to limit access with.
Big picture: I have been asked to create a search engine for our company's intranet. Such a search engine will crawl pages supplied to it by XML files for each independent application on the intranet. Problem is, the entire intranet is using Forms Authentication, and so the crawler will have to have access to each application without actually having user credentials (e.g. username and password).
Each application within the intranet has its access controlled by a permission manager, which is essentially a wrapper on the default Role Manager ASP.NET comes with. Each application can define its own roles and assign people who have those roles.
Please note that there are potentially hundreds of applications.
The crawler has access to the permission manager's database, so it knows what all the roles are. Therefore my idea was to have the crawler create a cookie that identifies it as having all roles for each application.
The problem I'm running into is this: how do I create a forms authentication cookie which already has the roles assigned in it without creating a corresponding user (IPrincipal).
It is entirely possible that I've failed to completely understand how Forms Authentication works, and if so, please tell me what I can do differently.
This is probably not what you want to hear, but...
I would just have the crawler authenticate like anyone else.
Given that this is a crawler you control, why fight Forms Authentication? Seems logical to create a user with all required roles in each application (hopefully you have a central administration point for the hundreds of apps, else I would not want to be an administrator there ;-)
If you do anything that allows "just the crawler" special access (bypass user-based authentication based on... what? The crawler's user agent? A specific origin IP?), you create a security hole that a hacker can leverage to gain access to all of the intranet applications that have otherwise been diligently secured with user IDs, passwords and roles (in fact, the security hole is particularly wide because you propose granting access to EVERY role in the system).
It sounds like what you want is an appropriately encrypted System.Web.Security.FormsAuthenticationTicket (which then gets attached to HTTP requests as a cookie).
The encryption logic is located in System.Web.Security.FormsAuthentication.Encrypt(), which I think uses the MachineKey as the encryption key. Also have a look at the GetAuthCookie() logic (using Reflector).
You might have to write your own version of the encryption method, but what you want to do should be possible, provided you have a copy of the remote site's encryption keys. You don't need the user's passwords -- only the user name is encoded into the Ticket.
It seems to me that the problem is not yet well defined, (at least to me!).
Why do you need to crawl the pages and index them if there are fine grained permissions on them?! How do you show search results without violating the permissions? Why not index the back end by passing the pages altogether (I mean index the database records not the pages)....
I'm using VS2010,C#,SQL Server to develop my ASP.NET web app, although this is not my first ASP.NET experience, but this time my project is more attack-prone and I should consider better security polices. I have a login screen as my first page, users enter their user name and password and a page specific to them is showed, in my last project, I used query strings (a userid) along with sessions for security purposes, but this time I've used just query strings, it means that at the moment one can enter myaddress.com?userid=1 and visit a page in my site!!!
I know this is not good, but what are my approaches, of courses I'm not working with banking or financial systems but I'm going to have an standard security policy, I should use sessions? cookies? can you suggest me an easy-to-develop and meanwhile secure way of implementing protection policies? any sample code or tips?
thanks
ASP.NET actually comes with all of the facilities you need to provide a secure site out of the box so you don't have to worry about all of these things yourself.
Use the built-in ASP.NET Membership features and you'll be fine.
when to use
windows authentication, form authentication, passport authentication, none?
I don't find on internet any relevant matter on it, although all say how to use these authentication.
But no one says which one is superior and when to use one.
Please elaborate a little on it.
Also i want to know benefit of one over another, and what is that authentication i did by now by creating table with user id and password and match the user id and password with the data table. If that can be done easily what is the need of these authentication.
It depends on the project and what you want to achieve. If you were developing an Intranet for a company obviously only to be accessed from internal computers then windows authentication would be the choice.
If you want people to register and wish to access as much information as possible then use forms authentication to get the data you require and store it alongside membership.
If you want people to come and go from your site with ease with as little steps as possible for registration, then use Passport.
Hope this helps :)
Windows authentication is generally for companies where people do something locally and server checks if the computer that is trying to do something is valid.Example: Company that accepts some requests and people working there do something with them.
Forms authentication is for whole web where you want people to access the content regardless from PC/other device? they are using.Example: Website like this.
Windows Authentication is generally used for Active Directory-enabled networks, such as Intranet sites etc. where the user's Windows credentials double as a login to the web app.
Forms Authentication allows you to use the .NET Membership/Role/Login features and control a more in-depth user database.
I've never come across a good reason to use Passport Authentication, but it's a proprietry MS single-signon style authentication method.
I'm porting an ASP.NET application to MVC and need to store two items relating to an authenitcated user: a list of roles and a list of visible item IDs, to determine what the user can or cannot see.
We've used WSE with a web service in the past and this made things unbelievably complex and impossible to debug properly. Now we're ditching the web service I was looking foward to drastically simplifying the solution simply to store these things in the session. A colleague suggested using the roles and membership providers but on looking into this I've found a number of problems:
a) It suffers from similar but different problems to WSE in that it has to be used in a very constrained way maing it tricky even to write tests;
b) The only caching option for the RolesProvider is based on cookies which we've rejected on security grounds;
c) It introduces no end of complications and extra unwanted baggage;
All we want to do, in a nutshell, is store two string variables in a user's session or something equivalent in a secure way and refer to them when we need to. What seems to be a ten minute job has so far taken several days of investigation and to compound the problem we have now discovered that session IDs can apparently be faked, see
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
I'm left thinking there is no easy way to do this very simple job, but I find that impossible to believe.
Could anyone:
a) provide simple information on how to make ASP.NET MVC sessions secure as I always believed they were?
b) suggest another simple way to store these two string variables for a logged in user's roles etc. without having to replace one complex nightmare with another as described above?
Thank you.
Storing the user's role information in a server-side session is safe providing a session cannot be hijacked. Restating this more broadly, it does not matter where user role info is stored if an authenticated session is hijacked.
I advise not putting too much faith in the article you linked to, but the 2002 vintage report linked to from your link is of interest. Here are my take-aways:
Don't accept session IDs embedded in URLs.
Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.
Issue cookies for complete domains (e.g. myapp.mydomain.com)
Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.
Don't issue persistent session cookies.
Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.
Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)
The only way to make a secure cinnection is to use SSL. Anything less than that, and you simply have to make the evaluation when it's "safe enough".
A session variable works fine for storing a value, with the exception that the web server may be recycled now and then, which will cause the session to be lost. When that happens you would have to re-authenticate the user and set the session variable again.
The session variable itself is completely safe in the sense that it never leaves the server unless you specifically copy it to a response.
Have you considered setting up a custom Authorize tag in MVC. I gave an example of this in another question.
On initial authorization (sign-in screen or session start) you could seed a session value with the IP address also. Then in your custom authorization, you could also verify that IP's still match up as well. This will help make sure that someone isn't 'stealing' the person's session. Everytime you access your session data just make sure to pass the requester's IP and have some check on it.
Are you trying to control the access to functions at the client level? That is the only reason I would expose the roles and items to control client side functions.
Alternatively, you could create a function to obtain the items that the roles of the user are allowed to use, and then even if the function is called outside of the items given back to the web application, you can prevent the user from accessing them.
4Guys seems to show how to control functions with the roles.
The approach I have used in the past is to use symmetric encryption of a cookie alongside SSL. Encrypt the user information in the reponse and decrypt it in the request. I'm not claiming this is foolproof or 100% secure and I wouldn't want to do this on a banking application, but it is good enough for many purposes.
The main issue with session variables is that if you store them inProc rather than persisting them, then you need to apply 'sticky' sessions to your load balancing in a web farm environment. Guffa is correct that without this persistence session variables will occasionally be lost causing a poor user experience.
Sticky sessions can lead to uneven load balancing, perhaps reducing the value of being able to scale out.
If you are going to be be persisting the sessions so they can be accessed by all servers in your web farm, you may be better off using a Guid to identify the user, encrypting this in a cookie and retrieving the user record from your data store each time.
My obvious question is that why do you want to store a users role in session ?
Here is my answer to your query, how this helps. I have attached a small demo application for you to take a look at and understand my points. When you open this project in visual studio, click on the project tab on the top and select asp.net configuration. From the page that will show up you can do the user administration stuff.
You need to store the roles of a user in some secure manner ? The answer to this question is that there is no need for you to worry about storing the role for any user, when we have the asp.net membership, profiles and roles framework to help us out on this. All you need to do is create a role in the aspnet database and assign that role to the user.
Next you want to store two string in some secure manner. I suggest you user profile for storing user specific information. This way you have the information available to you where ever you want from the profilecommon class.
Also please see the attached demo application placed at the end of my blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx
Just a suggestion, you might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It has a server side implementation of the cookie whereby all cookies can be stored on the server while asp.net authentification is used to identify the user. It supports encryption and is also very flexible making it very easy to switch from one storage type to another.