Security is a business where you must have a big picture view, because after all security is a system level property and attackers will look for weak links. And at the same time, we live in a mainly bottom up project by project world. The role of architecture is central to mediate the gap, grasp the big picture and craft a plan to execute bottom up project by project.
Identity is an interesting domain. It absolutely gets some strategic due and some budget, too. Lots of companies spend millions on identity. But there is an old consulting saying, its never a technology problem, its never a process problem, its always a people problem. Companies get there is an identity challenge, they invest dollars, but who owns this? Usually, identity is owned by someone who is doing fifteen other things. I can count on one hand the number of companies that have a dedicated identity architect, much less director or VP.
The result here is a lack of strategy. The strategy is not built around the company's goals. That matters because identity is the new perimeter. Strategy matters because most identity projects are not quick wins, they take some time, so you better have a roadmap to roll it all out. In the absence, people usually just jump to whatever the vendors have. There is good stuff out there, good tools all around, but I hear thse kind of things every week. "We have to do roles. What tool should we buy?" Just jumping to a tool is not necessarily going to solve your problem and it could be very costly to find out whether its the right fit.
Instead I would suggest defining your own design patterns. What do you want your identity system to do for your users. Not how tool a or tool b works, what do you want it to do for your users, your business and the systems you need to integrate to?
One pattern I use is called Model-Approach Controller. The first step is to separate concerns. That's fundamental in architecture. Say you are designing a building, a kitchen and bathroom both need plumbing but what you do in those two places is very different.
The job of the Model is to know and protect your assets. Ensure access control is not bypassed. Think authorization services.
The Approach is the front end, identity service consumers. Authenticates users, services, messages. The Controller enforces policy and composes system based on access control model.
The state transition then starts at Approach where we have unknown unknowns. The Controller is accessed and its job is to field the request, e.g. authenticate, its taking an unknown unknown and turning it into a known unknown, it limits the access request, the attack surface and defines list of what is allowed to be accessed next. The Model then should function as a known known, authorization mapping, are you using roles, groups, and attributes and how.
This separates the functions in a way that you can design tools and what skills are useful at each step. The model needs business logic skill, this is an area where companies should have an advantage over attackers, your team very likely does not know the clients' or even the API attack surface as well as the atatcker's but the backend assets should be an area of advantage. In a field where defenders have few advantages make the most of the ones you have - use fine grained authorization, risk based access control.For front ends its more about usability and for controllers, its more about management of sessions, apps and integration.
The overall idea here is to separate your concerns first, then go and look for the tools, protocols, and skills that meet those needs. That's a critical first architecture step missing in a lot of systems and can add a lot of value to develop the design patterns and use them to help shape as you build out the implementations.
Comments