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
Related
I'm building an asp.net application that will later be ported to azure.
For the moment, I have all the business tables in one database and a separate database that I use for membership; it's basically the default database that the login control generates.
In the business database, I have a table that contains user profile data and one field is TheUserID (which is an int) and another field that's called TheUserMembership (a string), which will contain the user ID that's generated by the asp.net user management tool.
Once the user logs in, I store TheUserID in the session and the whole app works with the int as the identifier.
Is this a good way to do it? Will this port to azure?
You should be using: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
And then yes it will port to Azure and SQL Azure.
Things to watch out for with Azure
Local storage (disk storage). Since you have multiple instances, local storage doesn't work as you will never be able to tell which instance it is on.
Session state must be out of proc, for the same reason as above.
There are many other little things here or there about Azure but those would be the 2 biggest to watch out for when moving across.
the user id is a GUID and it you can find the on the users table, you should not store user id into session since cookie can be stolen. for azure one principal requirement is that all tables have a primary key
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 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..
In my web application we have many users.I want to set permission for each user.In our windows application we used Database to store the Permission(Insert,Modify,delete and View).In web application can anybody tell me about where to store the permission.Somebody told that if we use database it will take so much time?In the case of XML it is easy and not taking much time.But if the client set permission for number of users,then it will create problem?....Please Give some idea
(Permission means in case of "Category" page which user can view the Category page,which user can edit information about category,which user can delete information of category,which user can add new category)
I'll leave it to the asp.net experts (one of which i most definitely are not) to recommend when to use the Asp.net Membership that Shoban suggested. I would advise, however, not to store the information in a disk file. Especially one can be user altered. You are asking for concurrency issues (especially with xml). Storing things in a database is just fine for this application. Once the overhead of the connection to the database server is handled (which probably isn't a big deal anyway because of connection pooling and is probably required by your app anyway, no?) the retrieval of info from the database is not a performance drag. So, use a database to store this info - if that database can be managed by the Asp.net Membership features the more power to you. If you want/need to roll your own, that is just fine.
-don
Take a look at ASP.net Membersip. This can help you develop your framework of storing user credentials and creating different roles. You will then have to develop your application to allow/disallow certain operations based on user's role.
I’m using .Net 3.5 and SQL Server 2008 Express.
Should I use the administrator user for the connection string,
Or should I create a new user with limited permissions?
If I need to create a new user for the connection string:
What security permissions should I grant him?
How do I set those permissions?
Thanks.
You must definitely create a specific SQL login, which you will use for database hits in your application.
Access only to the database it uses.
Assign specific write/read permissions according to the logic you have.
Never use Admin users account. Decide what all permission is required by your application then create the user based on that. I dont work mostly with SQl servers but I don't think there is a definite rule for this. It depends on application and the situation.
if the application is used to display only records then grand only read access.
Please check this post too
Enterprise Connection String Management in ASP.NET - Best Practice?
never use the sysadmin (sa) account - EVER!! create a new account, probably start with a member of the Public group, which is the default and then work from there.
Also, do not embed the pwd in the connection string - rather make it part of a config file; not only is it more secure, it's easier to manage.
In fact, you should really store the entire connection string in a config file.