I'm working on a internal web application (only employees can log in) and need some help figuring out a good approach to handling an individual users permissions to the system.
The system itself is in C# / ASP.NET (4.0 / Webforms / Forms Authentication) / SQL Server 2008 and has several different areas which will have varying sets of permissions. You can think of it in a basic crud scenario (create, view, update, delete) though those would apply to different aspects of the system.
(I do want to mention this isn't a type of CMS system, so I can't pick an Open Source Project like DotNetNuke or anything. This is being developed from scratch. I can use open source libraries if they are available though.)
What would be a good approach to designing the User Permission system for a complex system with probably 5-6 different sections that have a good 10-15 different view/update/deletes contained in each section?
The goal here is to make it:
Understandable for Users (Admins) to use / set up.
Easy to Maintain Code Wise.
Easy to adapt as new permissions are needed (different types or in different spots).
There are two approaches that come to mind:
Approach 1:
Try to use the built in ASP.NET Roles system to define the different permissions and manage it from there. I could build custom pages to handle the different areas and assign permission sets to users. I believe that would also allow me to use the current session object by default to contain all of the permissions in the system for a user. (HttpContext.User.IsInRole() etc...).
Now, while I think that method would work, I'm not sure it's going to be easy to maintain or adapt to future needs. It seems like it'd be the quicker way to get it up off the ground and working but not the best long term.
Approach 2:
Roll my own. In this scenerio, I'd set up database tables to store true/false style permissions for each section of the application. Then I'd retrieve that information and place it in the session and basically access it anytime I need to check if someone has permissions to do something. I'd then build the custom pages to manage the lists, etc..
It seems this approach might be the more maintainable long term solution. It gives me more power in the set up and how it is handled. However, I'm basically still doing the work that the Roles system abstracts away for me in approach 1. I favor this over approach 1 still however.
In the end, I'm not sure if either approach is the best way to handle this. Can anyone help explain to me why either of the above would be good / bad? Or even to suggest a different alternative as to the "best" way to handle it in general would actually be. This is my first major undertaking in this area, so I don't have a great deal of experience in trying to "secure" an application like this by permissions. Any and all help is appreciated!
Use the built in approach, unless you've a specific architectural need not to. If you don't use the built in one, you can choose to roll your own provider implementations, but you should follow the same templates as the build in system, as it covers a lot of the security caveats that you should think about.
There's even the built in configuration page for quick and dirty user maintenance.
I would stick with the built in approach, you can always write a custom RoleProvider to match the roles and permission you need for your user base see (Implementing a RoleProvider)
Related
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
What is for sure, the more I read about WIF, the more I get confused about how to do things.
For something that was supposed to ease things, I can't imagine how it would be without. I guess there's too many scenarios and I have hard time to find the one that fits me.
For some (good for my point of view, but maybe bad) reasons, I want to avoid a official STS (ADFS or ACS) and then write my own to keep things simple!
What I'm looking for is being able to deal with Users (that I'll wrap from an AD identity), Groups of users (custom) and Roles that get users/groups assigned to (custom).
I want to decorate my client side methods with the ClaimsPrincipalPermissionAttribute (or a declarative equivalent) to check if the current user has the required role. I want to be able to use that from a Windows Client application or a WCF Service hosted on IIS/WAS (Net.tcp is my preferred choice of binding).
Some guidance will be greatly welcome as I'm tired to read on an on WIF materials without any improvement of how the solution could be shaped.
Thank you !
So first of all - there is no such thing as a simple STS. I hope you realize that an STS is criticial security infrastructure and probably should not be your first WIF project. If you want to have a look at an open source STS to get some ideas have a look here: http://thinktecture.github.com/Thinktecture.IdentityServer.v2/.
Next authZ happens on the server side (client side is usability). Simply roles checks are rather done with PrincipalPermission. ClaimsPrincipalPermission encourages you to separate service and security code - look up ClaimsAuthorizationManager for more information.
I have an ASP.NET webapp that business customers in India wish to purchase and run within their premises (it's for industrial use). What's my best approach to do this, but not lose control of my IP? Some concerns I had:
Does ASP.NET4 code still need to get obfuscated to protect against reverse engineering, and how would this be done?
Do I need to create a separate build specific to each customer that is restricted in some manner (eg. tied to physical box attributes such as CPU)?
Is it possible for me to be the sole admin on the box, but give remote access to the folders that contain my CSS and HTML. That way I can maintain control over the code, but give the limited access the custom needs to customize the webapp to their site's look and feel. (Would large companies even accept this idea?)
Of-course, the other question is, am I better off not selling a white-label of the webapp altogether...
You should probably look at a software licensing and protection solution like http://www.inishtech.com/.
I dont know how good they are, but its a spinoff from one of Microsoft's divisions so they should be having good support for .net apps.
Being the sole admin on the box is just not a feasible solution for a software vendor. Its like if Microsoft was saying - 'hey you can buy Windows, but only I can change the admin password on your machine'. In fact if there is any information worth storing that the Businesses are going to put in there, they would want to ensure that you DO NOT have any access to their data.
My new assignment at work is to create a second version of our existing web application. Currently, our application supports only full time brokers, but now we our launching a second site specifically for part time brokers.
The new site will be almost identical to our existing site with the following exceptions:
It will have it's own branding.
A couple of the user controls used for displaying information will be different (but none of the pages will be different).
Our existing users should not have access to the new site and vice versa.
It needs to be easy to test both versions of the website from within Visual Studio easily.
We want to reuse as much our existing code as possible.
I have 2 weeks to do this.
I'm hoping that this is a common scenario and someone out there has some advice for how to accomplish this.
I really, really don't recommend branching projects or other routes which involve copying what is essentially identical code with the exception of branding and authorization. It will certainly be easier in the short run but, as you said, will become a nightmare very quickly trying to maintain almost-identical code bases.
Your pages can make the decision on what controls to show based who is logged in or even set globally to indicate this is the part-time broker version of the application. You could have a set of views and light logic to handle part time vs. full time brokers. Since the sites are deployed separately, a config setting would be straightforward. If you have other versions of the same site, you may have to give this some thought to ensure it would scale with your other variations.
I would even use the same database as long as you can separate the data appropriate using claims-based (preferred) or role-based authorization or similar.
All this said, there does not seem to be any great reason why you'd want to deviate from using the same code base.
I would create a branch of your code and then work against that. This is of course assuming that you are using version control. You are aren't you?
My first thought would be to
copy the entire source code to another IIS website
script the database over to another database (fresh start for new website)
make necessary adjustments to usercontrols and branding
roll out the new site (as Beta)
In Visual Studio, you can create a new project inside the same solution so that you have access to both projects at the same time.
If you're using Version Control... create a branch, and start customizing from there.
what this will do for you is give definitive separation between the two sites... no users have access across sites, all future customizations will be on a per-site basis, etc.
While I really like the idea CaptainTom posted another solution would be to break off the display layer of your application from the rest of the logic and create a new project that implements the new user experience while sharing the rest of the code
i.e. a FillTimeBrokers project and a PartTimeBrokers project with both implementing their logic from a common Brokers project.
I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)
Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags
Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.