I’ve got a keyboard on the frits, so I’ll give this post about one more try before I put my fist through this keyboard and go on vacation until a new one arrives.
I’m about a quarter of the way through a rewrite of the IDM/A prototype.
The reasons I elected to rewrite most of the codebase instead of adapt it and release it are many, but the main issues were:
- The access control was being handled in the API layer, instead of the controller library that controls all the actions being performed, mostly to accomodate flask’s ridiculously embedded and inflexible marshmallow and sqlalchemy extensions. While not an issue for a whole product, it does make the API an unnecessary risk surface. To be clear, this is not an issue with SQLAlchemy and Marshmallow libraries, but Flask’s extensions of them.
- Having access control being handled in the API layer also means access control needs reimplemented in any interface being created to interoperate with the system, which not only sucks for responsibility isolation from a general design perspective, but as security problems would emerge, their impact scope would vary depending on which interface was in use, which breaks continuity and degrades the security posture of the entire system. Being an identity, access, and session management system I would consider that tendency to be purpose-defeating.
- This allows third party interfaces to be developed with security controls that are gauranteed to be in continuity with the provided ones and disincentivizes the development of frontends designed to exploit the underlying system.
- I wanted the API to merely be relaying input parameters and output responses to/from a secure underlying controller layer so that the modular design could be leveraged later for C-rewrites of various layers (including potentially the API). This creates the path for that.
- I wanted to completely remove any dependency of any underlying component on the API layer for that same reason.
- I want to write a CLI toolchain that accompanies it that performs all tasks. This is also useful for writing functional tests, and should make system administration a little easier. I did not want those tools to contain any of the security layer, and I do want it to be oriented to CLI toolchains first.
- I wanted to create a path for PAM integration and didn’t see a web API centric approach being suitable for that as it was. Ideally administrators should be able to configure PAM to point at this system and then use it for administrating users on a great many machines.
- I wanted to create a path for an LDAP emulation interface for web systems. This would require that component responsibility rework.
Unfortunately, as always, this sets my time tables back.
Job Stuff
Got another raise. Unfortunately, this one involves an expansion of my responsibilities this round, so, I’ll be busier and will have to do alot of skill refresh.
On both fronts, this is a time for building.