Do you integrate and compile User Authentication and Authorization code from the beginning of your project?

Question

This is specifically about when to develop and implement code for authentication and authorization. I do not mean things the developer should be aware of such as exploits or using Prepared Statements for SQL Injection, and so on. These should be axiomatic for the developer.

What I mean is when in your development cycle do you build in the Authentication and Authorization "system/membership/whatever you want to call it"? Do you do it as you're going along, maybe you just turn it off or make yourself an admin, so you can run your code? Whether it is "Role Based" or "Activity Based" or something else I don't think should matter for this question. I might know what security I want to use, the system, architecture, etc., but when in the SDLC do I put that system in the actual code (whether I wrote it or it is some plugin)?

I do not mean the database. Only the application and that with Usernames and Passwords. I do not mean in my mind. I mean when you sit down to start typing your tests or however it is you write your software. When do I actually start typing the security stuff in? Before I do anything, during it, after it? All three+?

Side question, would TDD necessitate I do security as I go along?

There were promising question titles, but not the answer(s) I was looking for. It feels like it would get in the way of making things work. But I don't want it to be an afterthought either.

I put the word compile in the title to emphasize what I meant by "when."

Edit: For example, do I add this as I do this:

 // Create a PrincipalPermission object.
            PrincipalPermission MyPermission = 
                new PrincipalPermission("MyUser", "Administrator");

or

[AttributeUsage(AttributeTargets.Field, AllowMultiple=false)]

or

IsInRole...

I am not asking for which kind of security I should implement. There is no way for you to know that. I am only asking the when it should be typed in.

(Code I copied from MS sites)

Answer 1

If you follow an agile process, the answer is "when you need it". Most likely it will be relatively late in the development cycle. The reason is you want to deliver actually useful core functionality as early as possible so you can get feedback from product owner and stakeholders. A security infrastructure without any functionality cannot really be evaluated, but core functionality without security can be evaluated and get useful feedback.

If you follow a classic waterfall model, you will develop security early in the process since it is a fundamental piece of infrastructure which business logic is built on top of. But in agile, infrastructure is usually postponed until it is absolutely needed.

This does not mean security is neglected and treated as an afterthought, it is just a question of prioritizing tasks to reduce overall risk for the project.

Answer 2

Security (in general) is part of the functionality of your application. It is not an add-on. Security and access control affect whether other functions can be performed and on what data. This means it is also an important facet of your unit testing and component testing. It cannot be deferred until system integration -- it will be too late then.

As for PrincipalPermission objects and friends, you may want to specify an abstract permission such as PermissionToAddCustomer, PermissionToModifyCustomer, etc. Each of these abstract permissions would then be bound to a domain of interest to get concrete permissions.

Your unit tests for, let's say, adding a customer might look like (pseudo-code):

testAddCustomerWithAllPermissions();
testAddCustomerWithoutPermission();
testAddCustomerWithBasicPermissions();
testAddCustomerWithWrongBasicPermissions();

and so on. The first test in the list is probably the only one you think to start with. You will need to have tests that explore the combinations and permutations of the permissions model you implement.

The usual consequence of adding your security and access model late in the game is that you don't have those variations in your unit tests, and you do all of your testing only with "AllPermissions". This leads to large security holes.

Answer 3

Security mechanisms should be put in place as early as is practical, for the following reasons:

1. Proper security can affect the design of nearly anything in your site. For example, if you have role-based object access, it may affect how you pass object identifiers in your HTTP requests (e.g. direct object versus indirect object references); it may affect whether a particular page accepts a POST or a GET; it may affect how you divide up workflow steps in the UX (e.g. to prevent a user from attempting an activity that he will not be able to complete); it may limit your use of iFrames; etc. In order to prove your designs you will need to be able to test with at least two roles and you will need to be able to exercise the site in authentication vs. unauthenticated mode.

2. Your security designs and implementation may need external review, e.g. if you are attempting PCI/FDIC/ISO/FISMA compliance. The sooner you get the stuff put together, the sooner you can get the review process completed. Until it is done, your PM will have to keep a risk item on the status reports since the impact of a failed review could be serious.

3. Security mechanisms need to be verified through App Scan and PEN testing, which are not trivial exercises. If you build authentication/authorization early, you can increase project parallelism. Other features are not likely to get this level of scrutiny so they are better candidates to put off till later.

4. There are many features that could depend on security context, everything from rendering the menu system to recording audit records for user activity. If you change the security systems later, you could end up invalidating a lot of QA.

5. Back end services may require bits and pieces from your authentication/authorization context, e.g. if you are using context propagation.

On the other hand, if your authentication system is very complex, or relies on third parties (e.g. if you accept SAML or some sort of bearer token from a federated authentication system), you may be in a bind, since you don't want to have to wait for dependencies before building the meat of your site. In that situation you may want to write a back door that creates a security context that your site can use. A back door can be as simple as a bookmarkable URL that lets you specify a user ID but doesn't require any password or other validation. Your main code should still use the "final" interface for accessing security context, but the creation and teardown of the security context would be simplified, possibly with items hardcoded, to allow you to proceed.

Putting it off to the end is not a great idea, unless your site has very lax security requirements, e.g. it is for sharing baby photos and not for sending payments or completing purchases.

Answer 4

The sooner you include authentication module into your code, better it is. The reason being that the consumer of your API can include and test it. Otherwise it could give you false impression that everything is working fine whereas technically it is not.

Answer 5

It varies for different projects and companies. If you know what security, authorization and authentication you're going to need (often this isn't very complicated), then you build it sooner rather than later.

However, if you think there are other design decisions that could impact how it's implemented, you may want to wait. Some clients want a very sophisticated system until they find out they're going to have a lot of administration to contend with, so they cut back. Other times, you may not know how parts of the application are going to be implemented. A change to them could impact authorization.

Something like having sales divisions in a Customer Relationship Management (CRM) can alter the requirements during the development process as the client gets a better understanding about what they want. Can sales people in one division see clients in the other? Different lines of business may want to cross-sell to different territories, so the answer would be yes. Does reassignment need to be a simple and easy process? Maybe not if it doesn't happen often.

Usually you put off all decisions to as late as possible. You can develop a lot of software and business logic before you even pick a database or maybe you don't need one at all. Security decisions are the same.