We Keep Coding

Add Authorization at the beginning or the end of production?

In the production process of an internal-use ASP.NET/C# website, are there any advantages to starting with authentication/authorization/login FIRST, and building up from there? Or is it better to just build your site exactly how you want it, with unlimited restrictions and no logins or anything, and then do that at the end of production, before release? That's what I WANT to do --- just work on the functionality of the website, unrestricted, having one less thing to worry about. But I want to make sure that this approach doesn't cause problems later.
When it comes time to implement the ASP.NET authentication, it should just be a matter of running the script to generate the necessary tables and then using WSAT to manage the users and then provide restrictions to the already-existing content...should be...

You need to give your security consideration right up front. Even if you don't develop the final login screens and restrict access as you develop, IMO you should make sure that you can authenticate your users and limit access on at least one screen before going ahead with 'god mode' development. Include:
Authentication - Windows, Forms, etc.
Authorization / Access Control - will Role do or do you need Operation-level checking - e.g. AzMan
If you will be using SiteMap, you will need to look at security trimming to hide functionality to which the user doesn't have access (menus, breadcrumbs etc)
Auditing - e.g. changes to important data
Even though the site is for internal use, users can't be trusted, and you will need to ensure that you are safe from SQL Injection, XSS etc as well.

Definitely yes, that is the practical approach. You, said it, adding security creates no problem at all to an existing project.
Infact, when you come to securing the site there are a number of procedures before creating users. Also you shouldn't rely fully on WAT for user management it is better, I think, to have your own interface as you'll need it after deployment.

Your approach may sound faster but it have architectural drawbacks in following areas:
1- Missing security alignment with per page / per method level invocation.
2- Not clear Use case and work flow in terms of authentication / authorization.
3- Complete lack of security based testing while developing and adding up the new features gradually.
4- Lack of End-to-end dependency- What if security needs to be considered across layers, you will miss the whole vision on modular dependency and end-to-end testing.
Overall, if you do it 1st then you can just have one sample user/pwd/roles established and use that for all the secure areas of site, this will be sufficient to test and develop the application continuously.
Later when your application is ready; it's good to go with large number of user/pwd and associated roles to work with.
Hope this helps.

How to avoid using membership provider?

We are currently building architecture for thin-client bookkeeping application. It should follow two main requirements:
Application should have module design. Each module can have (and they actually do have) own Role system.
Later application should be adapted for running using different databases on different machines.
We think Asp.NET MVC 3 is appropriate platform for this task. For managing application data we chosen latest version of Entity Framework - its batch of Data Providers and Code First feature can save us much time.
The part we are tangled with is user/role management system. We should have some kind of Global Administration section for adding users and giving them access to modules (only global admins can add user to the system, no "guy from street" registration supported) and each module has its own administration section with its own admins and roles. We already have data model to store everything we need in appropriate way but have no idea how to access this data correctly from application.
Currently we see two possible ways to resolve this problem:
To write custom Membership and Role providers based on our DAL. Nobody from our team have done this before so we are not sure if this way worth the trouble. Membership provider cant offer as much flexibility as application needs so some crunches would be needed.
To dig through some obsolete books to find out how web sites administration system was organized before Membership providers where created.
Both this ways are not elegant and not obvious for us and its not an easy question which way to choose. Also we do believe that it can be other solution (of cause architecture can be affected). So, we would be glad to see any suggestion connected to this problem.

I'd personally recommend using the standard membership provider for creating and authenticating users in the first place, and then once you've verified that the user isn't just some "guy from the street," use your own custom architecture to verify that the authenticated user has access to the controller and action that they're trying to access.
The built-in membership provider takes care of a lot of nuances with regard to user authentication, password storage, and such. It uses best practices to avoid brute force attacks, rainbow table attacks, etc. It's tried and true.
But it sounds like your per-module permission structure may or may not fit the mold of the ASP.NET Role Providers. If they do, that's all well and good, and it'd be a good idea to implement a custom role provider. But if your needs are "outside the box," you'll probably be better off just manually checking rights at the point that's most appropriate for you (controller, action, request filter, etc.).

I would encourage you to use a custom membership provider. Why? Cause its the standard way and will save you tons of works. It's not as hard as I might see and there are tons of resources like this one.

To write custom Membership and Role providers based on our DAL.
Nobody from our team have done this before so we are not sure if this
way worth the trouble. Membership provider cant offer as much
flexibility as application needs so some crunches would be needed.
It is very much worth the trouble, if the default ones do not provide the functionality you need. If you already have a complex user system in your database, a custom membership provider is probably a good idea.
It will add valuable experience to your team, and you should be able to reuse much of the code in your next project. As #Randolf mentioned, there are loads of good resources for building a customer Membership provider, and I speak from some experience when I say that it is not really all that difficult. Everything is there, you just need to implement some methods.

Well, finally we decided write all from scratch and it was easier that it seemed to be
Add own IPrincipal implementation. Additional fields and completely different logic for IsInRole() method to avoid writing own attributes.
Assigning our IPrincipal in Global.ajax event to User.
It wasn`t hard at all. Now we have all the flexibility we wanted. No providers involved.

Database independent row level security solution

does anybody knows about Java/C# database independent authorization library. This library should support read, write, delete, insert actions across company organizational structure.
Something like this:
- user can see all documents
- user can enter new document assigned to his unit
- user can change all documents assigned to his unit and all subordinate units.
- user can delete documents that are assigned to him
I should also be able to create custom actions (besides read, write,...) connect them to certain class and assign that "security token" to user (e.g. document.expire).
If there aren't any either free or commercial libraries, is there a book that could be useful in implementing this functionality?
Thanks.

I, too, am surprised at the lack of security frameworks.
There is Rhino Security. Ayende has a handful of blog posts about it.
Another blog has a couple of articles on it, too.
It is possible to use it with S#arp Architecture as well.
Can't say I've implemented it in a project, just read up on it a while back. It was the only implementation of its sort that I could find.

I found one library that has functionality similar to my needs:
http://www.codeproject.com/KB/database/AFCAS.aspx
It is strange that there aren't any more of it on web since this is a problem that every serious application faces. As for documentation/example, the best I found are authorization modules of CRM systems like:
- Siebel - Siebel security guide - Chapter 10.Access Control
- Sugar CRM - http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/library/ms955698.aspx
That is a kind of functionality I need. I guess it will be DIY task.

The problem with implementing your security solution in your client library is that it is only effective with the client tool. That sounds pretty DUH on it's own, but you leave open the huge security hole that is the database itself. So if a user connects directly to a database (for example using an Access ADP to SQL Server) they have full control to whatever their user role is. Which they would need full access to everything in the database, if you are doing your restrictions in the client library.
The only case where this wouldn't be as big an issue would be with web applications and web services. If your web service did the security and hid it behind the web service interface (so there was no direct access to the database), then it would be safe. This may be what you're talking about, but didn't specify in your question.
If you are using a fat client, is there a reason why wouldn't want to put the security logic in the database side? You mentioned database independent, but nothing you specified would be difficult to provide in each platform. You basically are describing pre-/post- triggers that check if a user has rights to edit a record. A full RLS would also restrict the user's rights to view and make things slightly more difficult depending on platform.

What is the best approach to take for user profiles in my web application?

I'm currently building an ASP.NET MVC web application. My site security is (currently) built atop an extension of the System.Web.Security Membership model where I've extended:
AuthorizeAttribute
MembershipProvider
RoleProvider
This has sufficed for the security mechanism - although it has complicated a lot of things I could probably have done more simply. However, it's done and it was a very useful learning experience. Although at a later point, I may still rip it all out and replace it with a model that is more specific to the site - I'd like to keep all my user profile information in a single table indexed and built specifically for the site.
Now I've moved onto development of the user personal profiles. I need to store a lot more user information than for the basic user log-in system. I've checked out the ProfileProvider which seems like it's a whole different can of worms. I like that it's flexible enough that I can configure user profiles right from the web.config without having to rebuild my objects and the ProfileProvider handles the rest. What horrifies me though is the PITA this causes to run queries or reporting on my database. This fact is probably clouding my judgment against the ProfileProvider. Is the ProfileProvider even the right model to be using for this?
Should I go down the same road I did with the customization of the existing system or custom build my own system?
On one side, it going down the customization of the ProfileProvider could be a useful learning experience but on the other hand, I can see this rapidly becoming a reporting and querying nightmare. But coding my own is going to make querying/reporting very simple but I'm not going to learn much less.
If anyone has any experience with use of or customization of the ProfileProvider model (if that indeed is what I should be using) and can either point me in the direction of useful reading material or can steer me in a more useful direction I would really appreciate it.
Thanks in advance.

I read in some books and many blogs that the way to go was to implement your own MembershipProvider, RoleProvider and ProfileProvider based on the base class that Microsoft provides, and that's what I did. But at the end, I ended up changing all that code to my own custom-based security schema, which gives me all the flexibility I require.
The problem is that those providers make a lot of assumptions that might not accommodate to your system. For example, the create method of the MembershipProvider requires question and answer as parameters (which I didn't require) or if you need another attribute, it starts becoming cumbersome to code and maintain.. And let's not talk about testing it...
Like you said, the learning experience is always good, but the amount of code that I had to maintain to make it fit my needs was not worth it.
As for the AuthorizeAttributte, what I did was I created my own filters that fit my own security schema.
My advise? If your requirements fit what Microsoft thinks a ProfileProvider should look like, go for it. If not, build your own. You can copy some of the practices they execute, but it gives you the freedom to change wherever you have to.

I use tables in the database to implement security. A table-based approach is simple to implement, easy to understand, and provides for security trimming by simply joining the table to the table of items to be trimmed. Reporting is straightforward, and table-based security can be used for roles as well.
I just found the existing security model in ASP.NET MVC to be cumbersome, and it didn't do some of the things I needed it to do. In particular, it's difficult to apply attributes on things like document records that require access to an ID from the database, because you wind up looking the record up twice; once in the attribute class, and once in the repository for the controller method.
All other things being equal, I would rather maintain one security system than two. So I use the built-in security to authenticate the users, but after that I switch to table-based security.

Using Windows Workflow Foundation in applications with reporting requirements

I am wondering, very generally, about the feasibility of a WF solution in an application, where the business owners want extensive reporting capabilities on application state and data.
The main issue that I see is that WF tends to hide data, such as a recipient list, that is serialized inside the workflow instances, so it can't be reported on, in a way I'm aware of.
On the other hand, if the instance data is written out to an external resource such as a sql table, then haven't you just given up your ability to change that part of the workflow at will (taking away a major selling point for WF)?
In WF for .Net 3.5, I understand the SqlTrackingService can provide raw data about Workflow instance events, Activity events, and User events. But, I wonder about the scalability of logging a lot of instance data, in the activities, to User events. Also the schema I see that the SqlTrackingService uses looks like it would be hard to maintain a reporting solution on, especially if there are updates to the workflow over time. Am I wrong here?
So, has anyone out there successfully used WF when reporting was a major concern? If so, I'd like to hear about how it was done, if WF was isolated to only certain parts of the app (having data not applicable for reporting), and so on...
Perhaps, this is just a question about reporting in a BPM solution in general, as well...
EDIT:
I've accepted Maurice's answer because he took the time to answer it, but I'm still interested in any other opinions on this!

Using the SqlTrackingService in combination with tracking profiles is quite performant, specially when you enable transactional logging. Basically you want to use the tracking profile to only track events you are really interested in. You can also tell it to extract and log specific pieces of user data.
The main way to retrieve the data is not through SQL, although that is possible and for some queries like give all workflows executing a specific activity, but the SqlTrackingQuery class. This will also deserialize the additional user data.