SAML (Security Assertion Markup Language)
👋 Hi there! I'm Balaji S, a passionate technologist with a focus on AWS, Linux, DevOps, and Kubernetes.
💼 As an experienced DevOps engineer, I specialize in designing, implementing, and optimizing cloud infrastructure on AWS. I have a deep understanding of various AWS services like EC2, S3, RDS, Lambda, and more, and I leverage my expertise to architect scalable and secure solutions.
🐧 With a strong background in Linux systems administration, I'm well-versed in managing and troubleshooting Linux-based environments. I enjoy working with open-source technologies and have a knack for maximizing performance and stability in Linux systems.
⚙️ DevOps is my passion, and I thrive in bridging the gap between development and operations teams. I automate processes, streamline CI/CD pipelines, and implement robust monitoring and logging solutions to ensure continuous delivery and high availability of applications.
☸️ Kubernetes is a key part of my toolkit, and I have hands-on experience in deploying and managing containerized applications in Kubernetes clusters. I'm skilled in creating Helm charts, optimizing resource utilization, and implementing effective scaling strategies for microservices architectures.
📝 On Hashnode, I share my insights, best practices, and tutorials on topics related to AWS, Linux, DevOps, and Kubernetes. Join me on my journey as we explore the latest trends and advancements in cloud-native technologies.
✨ Let's connect and dive into the world of AWS, Linux, DevOps, and Kubernetes together!
SAML is an open standard for exchanging authentication and authorization data between two parties — an Identity Provider (IdP) and a Service Provider (SP). It enables Single Sign-On (SSO), meaning you log in once and gain access to multiple applications without logging in again.
The three players
User/Browser — the person trying to log in.
Service Provider (SP) — the app they want to use (e.g. Slack, Salesforce, GitHub).
Identity Provider (IdP) — the trusted system that knows who the user is (e.g. Okta, Microsoft Azure AD, Google Workspace).
How it flows
① The user tries to access a protected resource on the SP without being logged in.
② The SP doesn't know who they are, so it creates a SAML AuthnRequest (an XML message saying "please authenticate this person") and redirects the browser to the IdP.
③ The browser carries that request over to the IdP.
④ The IdP shows a login page. The user enters their credentials. The IdP verifies them and builds a SAML Assertion — a digitally signed XML document containing the user's identity and attributes (name, email, roles, etc.).
⑤ The IdP redirects the browser back toward the SP, carrying the signed assertion.
⑥ The browser POSTs that assertion to the SP's Assertion Consumer Service (ACS) endpoint.
⑦ The SP validates the signature (using the IdP's public certificate), reads the user's attributes, and grants access.
Why it matters
The SP never sees the user's password — only the signed assertion.
The assertion is cryptographically signed, so the SP can verify it wasn't tampered with.
One login at the IdP unlocks many SPs — that's Single Sign-On (SSO).
SAML with AWS: Three Key Use Cases
AWS supports SAML 2.0 in several ways. Here are the most common integration patterns:
Use Case 1 — Federated Access to AWS Console via IAM
Allow your corporate users to sign into the AWS Management Console using their corporate IdP (Okta, ADFS, Azure AD). No IAM users needed.
User visits https://signin.aws.amazon.com/saml or your IdP portal
IdP authenticates user and includes AWS role ARNs in the SAML assertion attributes
AWS STS validates the assertion and calls AssumeRoleWithSAML
Temporary credentials issued — user accesses Console or API with those credentials
IAM SAML Provider + Role Setup
Step 1: Create a SAML Identity Provider in IAM
aws iam create-saml-provider
--saml-metadata-document file://idp-metadata.xml
--name MyOktaProvider
Step 2: Create IAM Role that trusts the SAML provider
Trust Policy (attach to the role)
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789:saml-provider/MyOktaProvider"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}]
}
Step 3: In your IdP (Okta), configure SAML attributes
Attribute: https://aws.amazon.com/SAML/Attributes/Role
Value: arn:aws:iam::123456789:role/DevRole,
arn:aws:iam::123456789:saml-provider/MyOktaProvider
Use Case 2 — AWS IAM Identity Center (formerly SSO)
The modern way. IAM Identity Center acts as the hub — connect your external IdP to it via SAML, then centrally manage access to multiple AWS accounts and applications.
Architecture:
Corporate IdP (Okta/Azure AD) → SAML 2.0 → IAM Identity Center → AWS Organizations (multiple accounts)
In AWS Console: IAM Identity Center → Settings → Identity Source
Choose "External Identity Provider"
Download AWS metadata XML → upload to Okta as a SAML app
Upload Okta metadata XML → into Identity Center
IAM Identity Center then handles:
- User/group sync via SCIM 2.0 (automatic provisioning)
- Permission sets (templates for IAM policies)
- Account assignments (which groups access which accounts)
Terraform example: assign a permission set
resource "aws_ssoadmin_account_assignment" "example" {
instance_arn = aws_ssoadmin_permission_set.admin.instance_arn permission_set_arn = aws_ssoadmin_permission_set.admin.arn
principal_id = "GROUP_ID_FROM_IDP" principal_type = "GROUP"
target_id = "123456789012" # AWS Account ID target_type = "AWS_ACCOUNT" }
SAML is most common in enterprise environments (B2B SaaS) where companies want employees to use their corporate identity (e.g. Active Directory) to sign into third-party apps.
