Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I am currently in situation where I have to decide when to implement security measures. So the question is simple, is it better to implement authorization and authentication methods right off the bat in the beginning of the project, OR at the end of the project, before the first release?
Things I considered: at the end, one would make quite a bit of changes to the API; at the beginning it is time consuming, if the client wants to see first results soon.
You should let the client know about this too, you can provide them with 2 options, the first being the client will see A&A in the early stages and another seeing A&A in the later stages. This is sort of like giving the client a heads up & keeping them in the loop.
Equally important, depending on the client's needs, if the client wants fast results and implementation of security 'now' is not a factor, then he will go for the 2nd option.
I highly recommend implementing A&A at the start of the project, hence every other change & update you push from then on will be with respect to A&A being implemented, prevent hiccups & future errors popping up! Hope this helps.
I'm assuming both authentication and authorization are requirements, if you don't know then you should raise it as a risk and make it clear you could end up with significant re-writes.
Assuming you have requirements you don't have to build authentication and authorization into an application right away, many prototypes have no security at all because they will never be accessible to the outside world. Before an application is going to be in production it will need to have its security requirements met or you risk a breach.
Before you start delivering code you need to have a security model, and understand how you are going to deliver security in code or you may have to re-write the whole thing later. How are you going to filter information based on role? Do you know the roles, and what access restrictions need to be put in place? Are you collecting all the data you need to implement your security model? Do you need row filtering, or column level filtering as well? Will databases or buckets be accessed directly by users or is will restrictions be implemented in the application code? If you don't know my advice would be to stop until you do.
Clients live in the now, as in they want it now, and can't understand why you can't deliver it now. It's your job to tell them what it will take to do it right, and make sure they understand the risks of rushing it, and their job to take the risk. Make sure you get it all in writing, so they can't come back to you later.
Perhaps I am coming at this from a different perspective than your client, but when commissioning software (and particularly in relation to staged payments) I want to be assured that the contractor is working on my project, and delivering product of satisfactory quality. I would be happy for a contractor to display authentication and authorization at an early stage. There are very well-defined requirements about security - so seeing this early on and appraising it properly would give me a lot of insight into what to expect going forward.
OTOH I would expect a timetable of when to expect demonstrable components before work commences. That this is not the case gives me concerns about your client's governance and technical skills. I would also expect that the authentication component would be mostly boiler plate code hence not take a lot of time to deliver. i.e. you may in a hole already.
Talk to your client.
