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..
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
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.
I have an asp.net application that uses the SQL membership provider. I know how to get multiple applications using the same membership provider so a user can go to multiple sites and login using the same credentials. However the requirement on my current project is that each user is given access only to certain applications. For example, the user is given credentials to access Site 1, then at some point in the future, the user needs access to Site 2 and a manager/admin has to allow the user to access Site 2. Or when the manager creates the user's account initially, he/she approves access to the 3 sites (or whatever) the user needs to access.
So my question is what is the best way to use 1 membership provider for many applications, but only allows users to access applications they're approved for (so a manager can manage access to applications, but give users 1 username and password)? I've thought about using roles, but I already use roles in the application for allowing access to certain features in the application. It seems like that would get messy.
I've read about 50 similar questions on SO but none of them addressed the application approval requirement. Thanks in advance.
The easiest straight forward method here is to use roles.
If you add more roles (one for each app) for this purpose it is no big deal. You have a basic role for each app that must be available and check this on Application_AuthenticateRequest or Application_AuthorizeRequest . There are other ways to do it, but this is the least impact, easiest to code (nothing required but a role check), and easy to follow.
I’ve been asked to upgrade a few applications and I’m planning on merging all of them into one asp.net application. I’m fine with this decision and have spoken with fellow workers and they also think it’s the best option to go with.
The application will be accessed from a small group of users which belong to a larger domain. I’m currently planning on using Windows authentication and only allow this small set of users to access the asp.net application. Also there must be some role management, so that only certain users can view certain functionality.
I really don’t want to have many different windows groups; so I want to avoid having to assign different windows groups to different folders and control permissions in the web.config.
What I’d like to do is:
- Assign one windows group to the small group of users who will access the page.
- Create a custom membership provider and control the user who accesses the application. Depending on the user I will then assign his current set of roles.
- Add an application setting to the web.config, with the name of the current administrator, so if he logs in, he will be assigned all roles, and will be able to create and assign roles to other users.
I’d appreciate some advice if this would be the correct way to go about this.
Thanks!
I would check out the AccountManagement Namespace.
I like to use this. You can create a global security group (one for each 'role'). The account management namespace will allow you to fetch the UserPrincipal from AD with their logon name from the http context. Then you can check them for memebership in the security groups you created using the .IsMemberOf Method.
Our current Intranet environment is a little outdated. The current stack has ASP.NET 1.1/2.0 applications that are querying against a SQL 2000 database.
For role security, there are user groups on the servers that users are added into (so you need to be added into the group on the test and production machine). These user groups are synchronized into user roles on SQL 2000 itself. Roles are granted execute permissions to stored procedures as needed to prevent any access violations.
At the web application level, we use basic authentication (which authenticates against our Active Directory) and have identity impersonation turned on. The connection string to the database uses Integrated Security. This creates an environment where the web application connects to the database as the user logged in, which will enforce database security on stored procedures being called. It also allows us to use the typical User.IsInRole() method to perform authorization within the application itself.
There are several problems with this. The first is that only our server administrators have access to the user groups on the machine, so updating role security, or adding additional users is out of the hands of the application administrators. In addition, the only way to get the role was to call a SQL procedure called "xp_logininfo" which is locked down in SQL 2005. While I don't know the full details, our DBA tells us that this general model doesn't play nice with SQL 2005 given the nature of schemas in the newer version.
We're at the point now that we're ready to update our environment. We're writing .NET 3.5 apps to leverage more AJAX and SQL Server 2005 is the primary environment for our database. We're looking to update the security model as well to be a bit more flexible for the application administrators, and potentially leverage Active Directory more.
One concern we have as well is that a given user will most likely have access to multiple applications, so having some kind of centralized solution is optimal so we can easily remove users when needed.
What is considered the best practice for maintaining role security in this kind of environment?
ASP.NET 2.0's Membership, Roles, and Profile
I don't think the considerations related to the decisions that where made before has changed that much.
About the schema comment, those will just help you organize the database elements, so you can assign permissions to all inside a schema instead of having to configure for each procedure/table.
The decisions involved on whether having the identity flow down to the SQL Server instead of using the trusted subsytem model, are pretty much specific to the particular scenario. That said, I don't like to flow identity like that, because usually there is still logic being enforced on the application which means the sp are probably enforcing partial rules. Because of that reason, that approach also pushes to have more logic in the stored procedures.
About only administrators having access to the user groups in the machine, consider looking at ADAM (active directory application mode). I don't know if it supports integrating it with SQL Server, so I am not sure if that will work with that architecture. It is worth checking though.
Regarding not being able to get the roles, based on your info, I would assume there is a close relation between user groups and involved database roles. You can get the groups(roles) the user has in active directory.
Bottom line: evaluate how ADAM fits in your scenario, and whether the considerations involved into using the current identity flow approach remain. Also don't forget to consider the impact in the project on changing the identity flow of the application.
Try to refactor your design in such a way that your repository itself is LDAP. So essentially your users and roles objects map AD objects. You can then have the complete control rather than going through various system administrators. Of course, this is not easy depending on the state of code. But the best way to start out is to create small proof of concept to accomplish this mapping of your business objects to AD.