I have a ASP.NET MVC site with a private site administration application secured with ASP.NET sql-backed authorization. I need to add a login for the public site to allow visitors to sign up for an account.
I am thinking I should create totally seperate storage for the public site, rather than extend the existing user db and rely on roles to keep public users out of the back office. Is there any reason not to do this?
Yes there is. You can isolate the private database from the public database. Create 2 database user accounts, make sure they only have access to the 1 database they need. The public and private apps will use different accounts. Then lock down the database accounts to make sure they only have the rights needed for the web app to function. (I'm not sure what database you are using. if you are using ms-sql make sure they don't have access to xp_cmdshell, if you are under mysql make sure the account doesn't have FILE privileges. There are other considerations but this is outside the scope of this question.)
If a SQL Injection vulnerability is found in the public part of your site then they will be able to access that one database leaving your private site unaffected by the attack.
Time and potentially money would be one reason. Otherwise, if you have the time. Depending on the need, not knowing exactly the issues at hand, it could also add a lot of complexity...
HTH.
Will you ever have a user with more than one role? Could you end up storing the same user in more than one database? If so, I would keep your users in a unified DB.
Related
I have a web application which requires two types of users, well 3 but the third one doesn't require a role: Admins which can access every page including the admin page which allows control over members; Members which can access every page except the admin page and they can post their data (high scores of a game); and guests which can visit all pages except the admin page and they can't do anything really.
Looking around I found out that ASP.NET has roles but they are tied to only three types of role providers(SqlRoleProvider, WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider). Also I'm unsure but I assume that ASP.NET's Roles are connected to the whole Membership thing which means that unless I use the ASPNETDB.mdb database everything fails.
Anyway I have to restrict everyone but the admins from entrance to the admin page and allow members to post their scores. The idea I have now is that upon login, when I authenticate the user I store the user role into the cookiless session data and read it on every page load and proceed accordingly. Is there a better way?
Asp.net membership is not tied to a DB, you can roll your own, but I am assuming that you will be storing your users in a database of some sort, so the SqlProfileProvider is probably sufficent (this can be any database, does not need to be ASPNETDB.mdb).
Details on adding this support to existing DB is here: Create ASP.Net membership database structure in existing database
You will need something like the membership, as you will need to login, you need roles, and this is what the membership API is all about. It also uses industry standard storage etc., so that you don't code yourself a security hole by rolling it yourself.
You can then restrict either individual pages, or more commonly entire folders (e.g. an admin folder) by role using web.config files.
Well, it doesn't really matter how you call your database as long as you register the membership and roles services in your own database. It is as simple as running the aspnet_regsql command prompt tool without any parameters whatsoever and it will launch a wizard (.net style) to guide you through the installation of these services. ALL it does is create sql server objects in the database you wish (schemas, tables, sprocs, etc)
Now, if you dont like these built in providers (particularly I don't) there's nothing stopping you from implementing your own, it's quite simple but maybe a lengthy process due to the amount of abstract or virtual methods you'll need to implement/override depending on your approach or need. You two options to implement your own...
one is implementing theRoleProvider abstract abstract class or
extend/inherit from the SqlRoleProvider class which exposes a lot of virtual methods and properties.
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.
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.
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
Dim mbmr As MembershipUser
mbmr = Membership.CreateUser(newUserName,newUserPwd)
There are something like 6 overrides for the CreateUser method.
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.