{"id":460763,"date":"2025-05-23T15:00:09","date_gmt":"2025-05-23T15:00:09","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=460763"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=460763","title":{"rendered":"DASTing SAML: Breaking Trust, One Assertion at a Time<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

My name is Ilya and I\u2019m a Core Developer at Bright Security. In Bright we work on a DAST (Dynamic Application Security Testing) solution that helps development teams find and fix vulnerabilities early, straight from CI\/CD. My own path began in full-stack engineering, but almost a decade of shipping production code drew me ever deeper into application security. In this article I\u2019m explaining key approaches on what SAML actually is and how we detect it in Bright using DAST.<\/p>\n

<\/figure>\n

What is SAML (Security Assertion Markup Language)?<\/h2>\n

Let\u2019s start with the definition even though I\u2019m quite certain you know it if you\u2019re reading this article. SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between different security domains, typically an Identity Provider (IdP) and a Service Provider (SP).<\/p>\n

Where You’ll See SAML in Action<\/h4>\n
    \n
  1. \n

    Enterprise Single Sign-On (SSO):<\/strong> inside companies, employees often log in once and then can access email, CRM, cloud tools, etc., without having to authenticate again. That\u2019s SAML making life easier behind the scenes.<\/p>\n<\/li>\n

  2. \n

    Federated Identity: <\/strong>sometimes two different companies (or two different departments) agree to trust each other’s users. SAML is often the protocol that makes this «you can use your ID from Company A to access Company B» setup work.<\/p>\n<\/li>\n<\/ol>\n

    Why Developers (and Companies) Care About SAML<\/h4>\n
      \n
    1. \n

      One Login to Rule Them All:<\/strong> SAML centralized authentication. No more users creating 10 different passwords for 10 different services (and using «Password123» for all of them).<\/p>\n<\/li>\n

    2. \n

      It\u2019s a Standard: <\/strong>because SAML is standardized, your app can work with any identity provider that implements SAML \u2014 Microsoft, Okta, Google Workspace, you name it.<\/p>\n<\/li>\n

    3. \n

      Security Boost: <\/strong>\u0441redentials stay with the IdP. The service provider just gets a signed assertion saying, \u201cYes, this user is legit.\u201d The SP doesn\u2019t know any credentials.<\/p>\n<\/li>\n<\/ol>\n

      Why SAML Refuses to Die (and Probably Won’t Anytime Soon)<\/h2>\n
        \n
      1. \n

        Legacy Systems:<\/strong> big companies started using SAML over a decade ago. Moving away from it would mean rewriting tons of systems, testing for months, and basically begging for budget approval.<\/p>\n<\/li>\n

      2. \n

        Compliance Rules:<\/strong> for some industries, SAML-based SSO isn’t just \u201cnice to have\u201d \u2014 it\u2019s baked into regulations and audit checklists.<\/p>\n<\/li>\n

      3. \n

        Existing Trust Networks:<\/strong> partnerships between businesses often rely on long-standing SAML agreements. Switching protocols means legal headaches and new contracts.<\/p>\n<\/li>\n<\/ol>\n

        \n

        In short: it\u2019s stable, it works, and ripping it out would hurt.<\/strong> <\/p>\n<\/blockquote>\n

        Under the Hood: How SAML Actually Works<\/h2>\n
        <\/figure>\n

        Here’s a straightforward breakdown of the SAML authentication workflow:<\/p>\n

          \n
        1. \n

          User<\/strong> tries to access some protected resource.<\/p>\n<\/li>\n

        2. \n

          Service Provider (SP)<\/strong> notices this unauthenticated user.<\/p>\n<\/li>\n

        3. \n

          SP<\/strong> redirects the user to the Identity Provider (IdP)<\/strong>, asking for authentication.<\/p>\n<\/li>\n

        4. \n

          The user’s browser<\/strong> gets sent over (via HTTP Redirect or POST) to the IdP.<\/p>\n<\/li>\n

        5. \n

          User logs in<\/strong> (or maybe they already have a session at the IdP).<\/p>\n<\/li>\n

        6. \n

          The IdP builds a SAML Assertion<\/strong> and signs it<\/strong>.<\/p>\n<\/li>\n

        7. \n

          The IdP sends<\/strong> the signed SAML Response back to the browser.<\/p>\n<\/li>\n

        8. \n

          The browser posts<\/strong> that response back to the SP.<\/p>\n<\/li>\n

        9. \n

          The SP validates<\/strong> the response and signature.<\/p>\n<\/li>\n

        10. \n

          The SP reads<\/strong> the assertion and verifies the user’s identity.<\/p>\n<\/li>\n

        11. \n

          The SP creates a session<\/strong> for the user.<\/p>\n<\/li>\n

        12. \n

          The user is in!<\/strong> They get access to the resource they asked for.<\/p>\n<\/li>\n<\/ol>\n

          !<\/strong> Important to remember:<\/strong> the SP and IdP never<\/strong> communicate to each other directly. It’s all through the user’s browser.<\/p>\n

          Breaking Down a SAML Assertion<\/h2>\n

          Once the IdP authenticates a user it sends a SAML Assertion inside the SAML Response which represents an XML-document. A typical SAML Response looks like this:<\/p>\n