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
Related
We are using Advantage Database Server (ADS) to store data that is being used by some dashboard components in an ASP.NET 4.5 Web Form application. My connection string is set up to connect to my ADS DB in order to generate the dashboard visualizations, and it works great. However, when trying to use the built in forms for authentication and authorization, I don't know how to get the data to store in ADS.
Normally it would create a localDb SQL-like database, and store the .mdf files in the App_Data folder. However, I am not using this default connection, but am instead connecting to my ADS DB. Is there a way to utilize the Identity functions, but use ADS to store the user data?
In short, I discovered the answer is "no." MySQL (and also MariaDB) can be used to store the Identity user and role tables, but not ADS.
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 am looking for a best pratice to use the actual username in tSQL, while at the same time, my ASP.Net application logs into SQL Server with a global login, configured in the connection string in the web.config file.
This ASP.Net application is written as an extension to a SharePoint2007 implementation. The database this applies to is a legacy database, not a SharePoint database.
The application in question needs to log each insert, update and delete in audit (shadow) tables, including date&time and username. This is done by triggers.
The triggers use the SYSTEM_USER value, so that the global login is always written to the audit table.
There are about 2700 stored procedures in the system, and I guess that half of them perform DML statements.
What would be the best way to change the application so that the actual username is logged? My ASP.Net application knows the usernames. In fact, all of my users log in to the ASP.Net application with an Active Directory account.
I am considering the following options:
Use integrated security; but what about permissions that should only be granted throught the application, not to be used when connection with some other SQL client?
Set some global variable on each connection that is opened; but in the current code, each requests opens many connections, sometimes hundreds of them, to process the request.
Passing the username in the stored procedures, adding a field to each table. The trigger than simply reads the usernames from the tables in stead of deriving it; however, this requires a lot of modifications in database objects, potentially generating a lot of bugs.
Any comments on these options or perhaps other options to consider?
I normally use context info. Integrated security with impersonation will defeat connection pooling and passing username to procs just feels plain wrong.
I use MS SQL Server 2005 application roles in an application. I execute the sp_setapprole to start the SPs role and to finish sp_unsetapprole.
"connection pooling doesn't work" with application pooling, and there is no way to react on connection "disconnect event" (execute sp_unsetapprole just before disconnection).
I decide to call sp_setapprole at the start of all my SPs and call sp_unsetapprole at the end of all SPs.
Have you used SQL application roles? What are your XPs? What about performance hits?
I've rolled my own "approle" in the past, it's not too hard. Create a database role for each type of user (manager, casher, clerk, whatever). Create a database user with the group name (manager_user, casher_user, clerk_user etc). Create accounts for your real users and put them in the database roles. Validate your asp.net users by logging them into the database (open & close a connection), a lookup table or best if you use windows authentication and just get their user name from IIS. Check their membership in a database role but log in to the database using role_user. You can secure the database objects via the role_user, the users don't login and don't have access to any sql objects and you get connection pooling.
I have not used app roles before, but from what I know about the perf hit is that after setting the application role there is no way to revert to the prev. security context. Thus the connection cannot be reused in pooling. This alone is a huge perf. hit that forces you to think twice about using app roles.
However, the docs say that starting from SQL Server 2005 there is a way to remember the original security context in a kind of cookie returned from sp_setapprole and after that use sp_unsetapprole to revert back to it. So the pooling should work again. If I were you, I would compare the perf. with a couple of simple statements/sprocs.
Any reason you don't use the standard ASP.NET membership API on the application level instead of app roles?