Question: What is the standard method for accessing back end data, which logon should you use?
Examples:
For example we have applications that require the user to login but then use an admin account to access the data from the backend.
But there are also applications that require the user to login and use those credentials to access the backend data.
Reason: We are in the process of creating an application that will require the user to login and would like to implement the more common method(standard practice) of accessing data.
If there are alternatives those are also welcome.
Note: This will be made in ASP.Net 3.5 or higher and may include Windows Applications(VB.Net) as well.
Thanks in advance.
Edit: I dont want to have two sets of credentials. What I am asking is which credentials are normally used to access the Database. For example one one application may access 2 or more database's. Now would you use the same credentials they used to login to the application or would you use the admin account to access the data?
Edit 2: Maybe this should be a seperate question but if I ended up using integrated security to access the database would the user be able to simply connect to the database using his AD account? Either through an ODBC connection and MS Access or equiv.
Why not just create a login table and a table of roles for the user? You can have a user be an Admin or a User just by setting their roles either in the Login table or in a separate table if a user can be more than one. Having 2 sets of credentials seems a pain to me.
You would typically use a single restricted permission account to access the database. This would be used as part of an application level connection string.
If you are set on having individual accounts for each user to access the database then you will need to construct the connection string dynamically using the appropriate individual username and password. You will need to store these in a table somewhere. You may find that SQL Server connection pooling becomes less effective with many different connection strings being used.
An alternative would be to use Windows authentication but this would generally require all users to be part of the same domain and you haven't indicated whether this would be possible in your case.
Related
In my MySQL database I have two kind of users
MySQL users, used to connect and access a database directly from a client such as MySQL workbench or any ODBC editor.
ASP.NET membership users + roles : used to provide login for my websites.
My situation:
When I login via a webpage using the ASP.NET user credentials. I want to create a temporary random MySQL user (assign privileges, set password etc) and give it to the currently logged in (asp.net user) to gain temporary access to the MySQL database.
I know, if ASP.NET user has root access to create users he also has complete access to the database. My problem is, I have to give the user name and password so he can connect from another client and access the database directly. (I don't want give him root access or permanent access)
Having said he can access from another client, I would like to restrict this according to his login status in my webpage. like when he logs out of my webpage the newly created MySQL user is marked as expired or deleted.
I assume this should be very possible but I cannot think of any starting point. Could anyone help me?
kind regards
krish
This is possible. You could use the create user and grant syntax to create your user and grant them privileges.
You would however need to maintain a separate table for mapping MySQL users with an expiry date.
Have you thought about a different solution?
it would be vastly more work to complete but in the long run might be a more stable / reliable and scalable solution.
Maybe create your own WCF proxy for MySQL using NET.NCP, you could then have local user accounts / temporary accounts managed by you that authorise against your WCF service rather than the database directly, the proxy would in turn would connect directly to your database. This solution would also work from 3rd party applications.
Using a custom proxy would give you much greater control such as:
Being able to log SQL for specific users Sanitise or restrict any
specific command you don’t want executed on your database Not having
your MySQL server directly contactable on the internet
Split read & writes to different servers or clusters when scaling out
Edit 1: as per comments below:
I wouldn’t recommend relying on an event for the session end as this isn’t always fired. I would suggest you create another table to manage the users and their expiry.
For example, a table that holds the user ID or username and host along with an expiration time. This could be either date time / integer (epoch) depending on your requirements.
You would then need to invoke a query to identify all accounts from this table that have expired, you could then delete the user accounts from MySQL.
Depending on your MySQL version you could wrap a lot of the logic into a few stored procedures which will make the querying and maintenance overhead easier
I am currently working on converting a Windows Desktop application to a Web Site/Application. The data structure for the entire application is stored in SQL Server databases. Each database represents a different "library". One customer can have many different "libraries" (databases), and I'm contemplating placing many customer installations on the same web server.
This will be an internet site, so I'm strongly considering using Microsoft's supplied user account management for site access. I'm thinking that I would then provide administrator-level access that would allow a user to be assigned privileges on a particular database. (i.e., by default, creating a user account through the Microsoft mechanisms wouldn't give any real functionality.)
User access would have the following generic levels:
1. Read access (without this, the user shouldn't even know the library exists)
2. Insert access (user can add records to the system)
3. Edit access (user can alter the details of a record)
4. Delete access (what do you think this does :)?)
5. Admin access (user can modify other users' attributes)
I'm considering a model where there is a single account in the website that handles all SQL Server interactions. Thus, all of the code to handle allowing/denying access levels 1 through 5 above would be handled by code in my website pages, rather than by SQL Server's user account management.
I'm thinking that I would have one, central database that would contain all user names and to which libraries their account has (at least) read access (level 1 access from above). Then, levels 2 through 5 would be stored in each database for that user and that database.
Two questions occur to me:
Is this approach reasonable? Am I missing another way to do what I want (like, using SQL Server's user management tools) that is safer?
If I were going to enact this method, how would I create the "SuperUser" account on the website? I'm assuming it would be some sort of "NETWORK SERVICE" or "LOCAL SERVICE" account, but I'm still a little bit hazy about which account does what in ASP.NET.
Thanks!
Why cant you use ASP.Net Login authentication using Roles and Membership.. I think this should help you..
I'm developing a site that will display confidential readonly information,
with data fetched from a WCF service.
My question:
What is the best approach to user management across different information pages.
The service returns a collection with customer info after a secure login.
My idea is to have a Customer object class that is stored in session.
Is it possible to use things like HttpContext.Current.User.Identity.IsAuthenticated
followed by HttpContext.Current.Session["UserId"] without using a database with role-based security?
Would I be better off with a combination of local database, Linq to SQL or datasets rather than using
just class objects for data fetched from service?
thanks,
nakori
If you have no need of tracking the user's identity within your application, just use session as you indicated.
But the HttpContext.Current.User.Identity.IsAuthenticated and such relies on the user having authenticated with your site in some way or another (or it will always come back as false). Authenticating with the web site doesn't necessarily need a database though. You can setup users directly in web.config, xml files, or use AD or some other authentication mechanism that doesn't use a traditional database.
But unless you need to authenticate the users, you can probably do what you want using the server's session object and/or cookies.
You don't need a local database - but best practice is to have the user authenticate. The two options are via a database and or via AD if this is an internal site.
You might as well create a new WCF service to perform the authentication since you've already got your database functionality separate. This will also let you access databases that aren't local.
Here's the flow I'm looking for for authentication:
Attempt to pull in the user's name from windows authentication
If that failed (user is external to network), use BASIC authentication to get the username/password.
Check the username/password against the SQL database. If windows, password isn't required, if BASIC authentication and password is incorrect, prompt again
Create the Identity object with the user name, and populate the user's roles via another SQL database call
This would need to be used for multiple applications.
What would be the best method of implementing this? Creating a HTTPModule? If so, what do I need to keep in mind (security, virtual directory setup, etc)
This type of authentication is called Mixed Mode authentication (some google searches on this will get you alot of hits). We have a flavor of this running on a site I work on, however there are some quirks to our setup that have to do with odd business requirements.
Here is an article that might get you going on the subject:
http://www.15seconds.com/Issue/050203.htm
It is a big topic to give a huge detailed explanation of how you could set it up in one post.
Good luck!
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx