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");
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)