The Many Ways of Approaching Identity Architecture

all things which hold us together — muni wires of the sky : castro, san francisco (2012) / torbakhopper

At some point in the finite past, I had the good fortune to become involved in a project that was essentially completely greenfield. An unnamed company, in an unnamed industry decided to try something new. In a page right out of “The Innovator’s dilemma”, they spun up a new, separate organization, with a small team of senior business and IT people from the existing organization, physically relocated them a few miles away, and set them to work to build the future.

One of the first orders of business was to find an external consulting firm(s) that could assist with use cases & requirements, UI/UX/wire framing, application design, cloud native architecture, identity, all aspects of security, coding, and testing. My employer was chosen to do all of that. I became involved after the project was sold for system architecture and application security.

Since this was largely greenfield, we were starting from scratch on middleware, the identity stack, and application security models (among so many other things). On the one hand, for many consultants, this is the dream project — starting from scratch, chose your way of doing it for everything, etc, etc, greenfield. On the other hand, 99% of all project efforts I have ever been a part of had most of the structure around technology choices in place already. Even if we were creating a new security model, we generally had guidelines around a particular identity stack vendor or platform. Most of our projects are geared around how to enable a couple of new features using the system components that were previously deployed. Not always, but often this is the case — at least, in the enterprise space. Nevertheless, this time, we were starting from scratch defining how the entire identity stack and application security model should work for a brand new application — exciting times.

There are always some constraints. The initial set of requirements that I documented in the first week of this project filled only a few pages. This included, at a high-level:

• Cloud native architecture
• Low administrative foot-print. Anything that does require IT staff for ongoing operational support will be outsourced to an MSP (Managed Service Provider).
• Authentication with social login providers (Google+, Facebook, Twitter, LinkedIn — were the ones that kept coming up).
• Assumption that any server-side application code would either be Java or Javascript (that is what they know).
• Assumption that cloud provider would be Amazon (AWS).

In the identity space, a couple of blanks were filled in early on:

• Identity as a Service was the preferred solution (this goes right along with the cloud native architecture).
• OpenID Connect as the authentication protocol.
• Federation/authentication/authorization/security would be achieved with as much out of the box functionality as possible.

Given all of that, we were starting from the beginning, there were many decisions to be made. Many of the consultants and recent-hires at the client on this project had done application security before using completely custom solutions — not the path to a secure system in my experience.

AWS Cognito was the early favorite for the identity stack. I haven’t historically had much experience with Cognito. But, over the past year numerous features have been implemented in it and in the AWS API Gateway that makes it usable from the perspective of my standard application security model that I have spent so much time writing about. The coming-of-age of AWS Cognito is a separate blog post; we are here to explore something else.

There are decision points in picking an identity stack and designing an application security model.

• Is this application used by B2E, B2B, or B2C user communities?
• Use protocol endpoints directly and craft your own protocol requests? Or, use a library to do it. The first has been done before. Today, there are plenty of libraries on the Internet that can work with a wide variety of protocols and IdPs.
• Use your identity stack’s authentication SDK or a more generic OIDC library?
• Do I care about the details of the authenticated identity? Or, do I just need to know that a trusted, third-party source says they are who they claim to be? In the AWS Cognito world, the answer to this question would be the difference between User Pools and Identity Pools (or AWS Cognito Identity).
• Is there any claims mapping occurring between the federation partner and my system’s representation of that user?
• Will the local user definition have custom claims that must be stored in the directory?
• Is the Identity Provider serving up the Login Workflow? Or, is the application doing it itself?
• Is Single Sign On (SSO) required? If so, what approach is used to accomplish this characteristic?
• Is federation with external identity providers utilized? If so, does the application integrate with them directly or rely upon an identity provider to act as an Identity Broker?
• In the corporate setting (especially large organizations), does the application have its own Identity Provider? Or, utilize an existing, centrally-managed IdP?
• For large organizations, how do your answers to these questions match up with the larger enterprise identity story? If there is no relationship between the two, it’s unlikely you are going in a direction that is in the best interest of your organization.

These questions and many others should be considered (at least briefly) when designing the security for your application. What are the correct answers? That depends on the context and the requirements. I’ve spent a lot of time writing about what I believe to be the correct answers in a variety of different use cases, but I’ve barely scratched the surface.

Most organizations will have a person or group whose job function is to think about these things (especially in the larger picture). In smaller organizations, it will likely fall on the senior developer(s) to make these decisions.

Don’t push these decisions off to the last moment. The UI/UX and security of the system will all suffer in the long run.

Most importantly, if you don’t actually know what you are doing in the application security and identity spaces, seek the help of someone who does — yes, this might cost time and money. The overall security of the system will be greatly enhanced and you’ll probably sleep better at night.

Image: all things which hold us together — muni wires of the sky : castro, san francisco (2012) / torbakhopper