Skip to content

Atomic Entra

Notes on Microsoft Entra, identity architecture, and the practical side of identity-first security.

Subscribe via RSS

Safeguarding SAML Assertions with SAML Token Encryption

Digging in to SAML Attributes

Continuing on the topic of SAML from last weeks article, another interesting topic worth exploring is SAML Token Encryption. In most cases during an SSO setup or an SSO application migration from one identity provider to another, you likely won't come across a case where token encryption is required. However, without a proper understanding of what it is or how to set it up you may find yourself troubleshooting an issue that has a relatively simple solution.

Digging in to SAML Attributes

Digging in to SAML Attributes

One of the common projets I'm often times engaged in is Single Sign-On migrations from a previous IdP to Microsoft Entra. Typically these projects are pretty structured. Do some planning to determine which apps need to be moved, prestage applications in the environment, start coordinating with Application Owners on requirements around configuration and claims, and then cutover the application at a predetermined time. Other than the sometimes painful work of communicating and coordinating with App Owners to discuss configuration and figure out if a Vendor has to get involved, attributes and claims are an easy thing to get wrong. It's easy to sidestep attributes when learning about SAML and not spend any time thinking about each claim is and how it's used, but then I feel like you're left with an incomplete view of how SAML actually works. This post is my attempt to grapple with them just a little bit more intentionally.

Welcome to Atomic Entra!

Welcome to Atomic Entra banner

When I initially started this blog, I was not always completely sure what I wanted to talk about. I was earlier in my career, moving through personal and professional change, and interested in nearly every corner of the Microsoft cloud ecosystem. At the time, a lot of my day-to-day work lived around Microsoft Sentinel and Microsoft XDR, so that naturally shaped what I wrote about.

Last year, after moving into a consulting role and getting re-exposed to the broader Microsoft cloud landscape, identity became the topic I could not ignore. Between the pace of change in identity security and the explosion of agentic AI, identity keeps becoming more central to how organizations protect access, make decisions, and manage risk.

In-Depth Sentinel Part 1: What is it and Why use it?

In-Depth Sentinel Part 1 banner

Microsoft Sentinel is Microsoft's cloud-native SIEM and SOAR platform. As organizations continue moving deeper into cloud services, it makes sense that security operations and event management increasingly need cloud-native tooling as well.

Sentinel is Microsoft's answer to that need, with support for ingesting signals from Microsoft 365, Azure, AWS, GCP, and on-premises systems into a single security operations platform.

Microsoft Sentinel and Zero Trust

Microsoft Sentinel and Zero Trust

In the last few years, the term "Zero Trust" has been used both to describe a real security strategy and as a buzzword for selling more products. Depending on how you first encountered it, your understanding of the term can vary wildly.

This article is focused on two simple goals:

  1. Define what zero trust means and why it matters.
  2. Show how Microsoft Sentinel can support a zero trust strategy.

Introduction to Microsoft Sentinel's User and Entity Behavior Analytics

As SOC analysts work to defend their environments, one of the hardest problems is understanding what normal actually looks like. Baselines are difficult in distributed organizations with remote work, varied privilege, and a wide mix of systems and workflows.

Microsoft Sentinel's User and Entity Behavior Analytics, or UEBA, is designed to help with that problem by correlating logs and alerts from multiple sources and building behavioral baselines around entities in the environment.