The 57th Edition of the Identity Jedi Newsletter

Sorry for the delay, People Process Technology, Common language

Thursday 10/19/23 - Identity Jedi Newsletter - Subscribe

Hey Jedi welcome to the 57th edition of the Identity Jedi Newsletter. I’ll begin with an apology. I’m sorry for this newsletter coming in a day late. I strive to make sure I give you the best every week, and to be honest, life has been lifing. I didn’t have it in me to write it and give it my all yesterday, and I care about this industry and you all too much just to mail it in.

Sponsored By

Bullet-proof your cloud IAM and ensure rapid recovery with Acsense

Let’s Get to the Good Stuff!

  • People, Process, Technology

  • Make Identity simple again…

People, Process, Technology

I often bring up this phrase whenever I talk to organizations about IAM. People, Process, Technology. Those three things in that order have such significant factors in the success of an IAM program. This article from the Ramp engineering team illustrates this to a T.

I loved the approach they outlined in how they solved their problem. So I wanted to break it down for everyone:

They start with people. In this case, it’s their engineers. What’s their primary function, and how do they currently operate? What allows them to do their job effectively? What causes friction?

Asking these questions allows you to understand the people's needs. It also leads you directly to the next part, which is process.

How do they do it today? Are there issues with the current process? Here’s how they broke this down at Ramp

In the early days, our engineers mainly operated with only 3 AWS roles (Junior-Engineers for interns and entry-level engineers, Engineers for senior and established engineers, and Admins for system owners). Whenever a backend engineer wanted to access a new or existing resource, the infrastructure team would have to add a new IAM statement to the role policy to allow this access. In addition to adding friction for both the backend engineer forced to wait until the request was completed and the infrastructure engineer forced to perform a repetitive task, this also generated significant organizational problems that worsened with time. After months of operating with this workflow, we noticed the following problems:

Senior engineers had persistent production access to more of our system than necessary. This increased the base rate of risk of their accounts - a mistake or account compromise could impact a large swath of infrastructure at once.

Junior engineers had limited access to our system, leading them to ask senior engineers to run queries on their behalf. This added friction, monopolizing engineering time.

So they understood their people and how they worked. What their current process was, and what issues had grown. Then they applied security principles to the current process. ( Because Identity is security, right?) This allowed them to find objectives that they needed to meet.

Next, BEFORE CODING A SINGLE THING OR BUYING A SINGLE PRODUCT. ( Ok, to be fair, I don’t know if they did this, but for the sake of this post, I’m going to assume they did to make a point)

They designed their ideal system. They took what they knew about their people and processes combined that with the things they wanted to fix, and applied security principles. This gave them a direction for where they wanted to go.


They directed their ideal system into the components they would need to make that happen. Check out how they describe the process.

By describing the ideal system, we understood two halves to it: the technical one, being defining what access to obtain and implementing how to provision that access, and the human one, being about establishing clear system ownership for every engineering team to ensure that they would all use the tool properly.

In our journey towards achieving just-in-time access, we first moved to fine-grained access control by scoping AWS SSO groups per engineering teams. By moving from 3 roles to more than 20, our objective was to create a clear social contract around the use of our future tool. The tech lead of a team would increasingly own their corner of the stack, and they would similarly be accountable for their team's use of production access. As our teams scale and create more resources, it becomes easier to identify owners of parts of the systems. In embodying our core company value of ownership, each tech lead manages and takes proactive responsibility for their part of the system, ensuring that accountability and quality are never compromised in our ongoing developments.

Chef’s kiss.

I LOVE this approach and thought process. Being successful in an IAM program is about more than just tech, and requirements. People have to buy in, process has to be designed. None of this comes with contract you sign with the vendor, or even the contract you sign with the consultant company to come do this for you. It HAS TO START with you and your organization. Now those other actors can and will help, but that can’t do it all for you. It’s like coaching. You can tell a player everything in the world, give them all the practice sessions, and all the information, but when it comes down to it, the player has to execute. The coach can’t do it for them.

Finally once you’ve done this prep work, you pick the technology that best aligns with your process. You know exactly where you need it to fit, and you know what to look for when purchasing. Check out the full article from Ramp to read about their process. Definitely worth checking out.

Make Identity Simple Again?

So CISA and NSA issue a report that says vendors need to do a better job of explaining technology to customers, and make it less confusing when describing features and services.

Now why does that sound familiar? I could have sworn I saw the other day, somebody that said something very similar. That the industry needed to do a better job of explaining what things where, and not using the same product marketing pitches over, and over, and over again.

For the life of me, I can’t think of who that was 😉 

All jokes aside, good report from the CISA/NSA folks, we do need to do a better job of describing the areas of this industry. We should be focused on developing standards and vocabulary that cleary define the lines between the interesecting disciplines.

We’ve made some progress over at IDPRO with the Body of Knowledge and CIDPRO exam, but there’s always more work to be done. I encourage you to get involved. Hope on a standards body, write an article for the Body of Knowledge, etc. Together we can change it.

Plus, we like beer and happy hours in the identity community so the more you’re involved the more happy hours you’ll know about. And who doesn’t love that?

Shared Responsibility

A word from our friends at Acsence

Let’s talk about the Shared Responsibility Model. (SRM) If you’re building architecture for cloud-based applications it’s a term you’re probably all too familiar with, and if not, its definitely something you should. Here’s a blog from our friends over at Acsense that breaks it down.

Identity Jedi Show Podcast

Officially in Season Two of the Identity Jedi Podcast! It was so much fun hanging out in Austin at XO NighClub and filming our first episode of the season. The team is hard at work editing and should be hitting the steaming platforms soon! Excited to welcome Sameer Sait to the show as my co-host, and I’m looking forward to all the great conversations we’ll be having!

The Last Word

Some quick updates: The LinkedIN Course is making it’s way through the approval process and I’m expecting to get the final details in the next couple of weeks, as always you’ll be the first to know!

Raincoat: Thanks so much to everyone who has reached out about the new endeavor with Raincoat. We are excited to have our demo ready, and enjoying the conversations we are having with potential customers. If you’re interested to know more, want to give us feedback on our demo, you can reach out on our website ( or just email me directly [email protected].

Podcast: We had so much fun doing the podcast in front of a live audience, and we are looking to make it a thing going forward. So, if you’ve got a city you want us to come to, let me know! No promises yet, as live podcasts are expensive, but we are working to figure that out. If you’ve got a company that wants to sponsor it, we’ll take that

Finally: I love making this newsletter. It’s sometimes therapeutic for me because I love writing and I love talking about identity. But the reality is..I’m human, and I’ve got A TON of stuff going on. I say all that to say, please make sure you are checking on yourself. Take mental health days ( like for real). This shit is hard. Life is hard. I have to remind myself, and I’m glad I’ve got friends and colleagues ( shoutout Ian Glazer) that remind me by checking in on me. So I want to remind you,and check in on you.

How are you?

Whether we’ve known each other for years, or this is the first newsletter you’ve ever gotten from me. My inbox is always open.

Be Good to each other, Be Kind to each other, Love each other

-Identity Jedi

What did you think of this weeks newsletter?

Login or Subscribe to participate in polls.

Join the conversation

or to participate.