“At the beginning of a project, time is the rarest resource”
In our projects at ekito we have to deal with new projects for our customers. Some are startups, some are bigger companies but in both cases the project should be setup in no time!
There are several critical phases in a project lifecycle, but the most critical one, or for sure the most costly to change later on, is its starting phase.
Product owners want to present prototypes to the users as soon as possible to better design the future product. Developers are so hot and eager to code they would start to write anything but wise and effective architecture patterns. At the beginning of a project, time is the rarest resource! Weird isn’t it? But it’s true! Choices done at that time will have the more dramatic long-term consequences during the project life time. Countless projects have taken their major technical debt during this phase.
Typical quotes are:
“Code fast! Code fast!”
“Can you show me something tomorrow, users are available?”
“Security? Authentication? Architecture? We will see that later! Refactoring FTW!”
“Houston, we have a problem! We will fix that later!”
Some projects will fail and afterwards we can felicitate ourselves to not have spent time and money on “non focused” tasks such as Architecture, Security, etc… In this case we will be more than happy to invite you during for our FailCon conference in order to share your experience. But some projects will succeed! And these projects will have to live with their technical debt and for some of them die because of this debt…
At ekito our objective is to participate in successful projects, so our mindset is to think the project will have to live with its technical debt in the long term. So let’s try to minimize it as much as possible!
The main idea of the product bootstrap is that some topics are important and cannot be delayed from the beginning of a successful project even if there is no time to design it nor implement it. So the solution is to have it already done for what we call Minimum Viable Architecture (MVA). This architecture may be changed later on according to the project requirements.
Just like Pivotal has done with SpringBoot product for Java development, we are convinced that an opinionated quick start can be applied to the majority of the new projects. Of course some projects are so typical from the very beginning that they will require a specific product bootstrap, but we are believing this is exceptional: so let’s forget that for the moment.
The goals of the product bootstrap are the following:
- Provide seed projects to quickly start new projects
- Based on our past experiences
- Good projects
- Fullstack solutions
- Multi-technological stacks
- Based on a common architecture
- With connectors up and ready to go
Olivier Bearn has written an excellent article on the topic of “IDaaS: Users management is no more my concern“. Drop a comment here below or flood him on Twitter (@obearn) if you want him to translate it in english!
The main idea here is that we can now design robust architecture which will delegate the users management to another application which could be:
- a service hosted in the Cloud
- a product deployed on premises
- an ad hoc product developed and deployed on premises (for sure it’s the less favored solution in our opinion)
The diagram bellow illustrates the “IDaaS” oriented architecture and your project is located in the left part of the diagram:
How many times, you! seasoned developers, have you coded the user-management services for your projects? Every single time for every single project ! Yeah… So you know that user management is not only a CRUD (Create Read Update Delete) task. We have to deal with:
- Password hashing and storage (Security concern here!)
- Password strategy (complexity and change requirement)
- Forgot my Password feature and associated workflow with email (Security concern here!)
- Sign in and Sign up feature and associated workflow (Security concern here!)
- Email verification workflow (Security concern here!)
- MultiFactor Authentication (Security concern here!)
- Account revocation or locking mechanism (Security concern here!)
- Social Sign in
- Enterprise authentication mechanism: LDAP, … (Security concern here!)
- Single Sign On (SSO)
- Account linking (for social accounts and application accounts)
- Setup secure best practices for exchanges (Security concern here!)
- Brute force detection mechanism (Security concern here!)
Do you think you will have time to think about that in the starting phase of your project? Do you think this is not important? How many days will you waste to develop this for every single project?
Our opinion is to not spend time to develop and maintain this kind of features but to use available products and technologies to do that. And if for some reason you have to develop it… Do it only once and for all!
So our first rule is:
Users management is not my concern in the scope of my project
To clone or not to clone? That is the question…
If we share the same architecture, does that means we will be able to clone our solution for every project? Of course not! There are several variables which can change amongst the projects.
First, let’s talk about the Identity and Access Management (IAM) component. For some projects Cloud based solutions (such as Auth0) are acceptable in term of privacy and legal engagements. This choice will not require too much work to administrate, customize and scale the IAM and pricing is not so much expensive for the job done.
Some projects will prefer to have the hands on this component and will focus on specialized product (such as Keycloak which is an Open Source RedHat project). This approach will require more administration and customization work compared to the Cloud based approach but it will be nothing compared to the third solution consisting to develop and maintain its own IAM product.
As a consequence, our Product Bootstrap must be able to deal with any of these three way of doing.
JWT for interoperability
Hopefully, there is JSON Web Token (JWT) for the rescue. JWT provides a method for representing claims securely between two parties in a standard way (IETF standards).
Everything is standardized. Only payload claims remains to be agreed to assure full interoperability between Identity and Access Management products such as Auth0, Keycloak or any other. JWT defines some payload claims such as:
- “iss” (Issuer) Claim
- “sub” (Subject) Claim
- “aud” (Audience) Claim
- “exp” (Expiration Time) Claim
- “nbf” (Not Before) Claim
- “iat” (Issued At) Claim
- “jti” (JWT ID) Claim
Other claims are defined in OpenId Standard Claims, but maybe it’s not enough… We can also require some other ones for the project purpose or for the company requirements. All IAM products we have evaluated so far provide mapping mechanism to customize payload claims forged in the JWT returned once a user is authenticated.
Note JWT can be issued by IAM for authenticated users but also for authenticated “non human” clients (with clientId and clientSecret).
Our second rule is:
JWT and agreed payload claims are key for the interoperability
Stateless in the other key benefit of JWT technology which bring to the architecture scaling capability quite easily.
Indeed, in the IDaaS oriented architecture, the front-end application is in charge of authenticating users thanks to IAM component and retrieve and store JWT token on the client side (for instance in the local storage).
The current application back-end is never involved during these authentication workflows. Application back-end simply exposes APIs (for instance REST, Reactive, Websockets, …) which are either public or with access restriction. Should the access be restricted, a valid and not expired JWT token is required to be inserted in the request.
The back-end application will verify incoming tokens and eventually serve the response according to the authenticated user’s or client’s granted role for the application.
Our third rule is:
Application back-end is stateless. It requires valid and not expired JWT token to access restricted API
What about technologies now?
Up to now we haven’t talked about technologies used to develop front-end and back-end applications for the product. Should the Product Bootstrap impose one technology? For sure, again the answer is no!
Customers may have technologies constraints or favors. But also people at ekito may be more fluent in some technologies and as a consequence will be more productive with some technologies. The technologies have to be selected according to the project constraints as well. So definitively, the Product Bootstrap cannot be designed with only one technology.
Ok, so should we prepare and develop Product Bootstrap for every technology? Again no, but this time for money and ROI (Return on investment) reasons. We are pragmatic people so we choose to develop and maintain Product Bootstrap for a set of technologies (again here opinionated approach is chosen).
We have selected the following technologies:
- Auth0 or Keycloak for the IAM component with ready to go social sign in for Facebook and Google+
- Angular (React is in the pipe but not ready today) for front-end
- SpringBoot or NodeJS for the back-end
These choices will evolve according to the future of the techs but also to our customers requirements.
We have covered so far the:
- Identity and Access Management
- Common stateless architecture
- Opinionated technological choices
… but there is still something missing in our Product Bootstrap big picture: our capitalized know-how and ready-to-go connectors.
Each Product Bootstrap technological stack will come with optional ready to go implementation and connectors on the following topics:
- Client-side error log gathering mechanism and storage on the server-side (File, DB, SaaS: Papertrail)
- Client and Server analytics connectors with MixPanel
- Remote File storage connector with Amazon S3
- Transactional Email service provider connector with Mailgun
ekito’s Geek Breakfast and live demos
For people living in Toulouse, France, stay tuned on ekito’s events!
During a future Geek Breakfast, we will talk about this topic and present you live demos of all the available stacks.