<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D54z00008SJhs2CADOkta Identity EngineSingle Sign-OnAnswered2026-06-04T17:47:36.000Z2022-11-30T22:24:57.000Z2026-06-04T17:47:36.000Z
Log SAML Assertion logging

We're using SAML identity providers in our Okta Tenant. We would like to log the raw SAML assertions during failure for trouble-shooting purposes. If the Okta errors are obscure/un-helpful, we'd be able to trouble-shoot the SAML problem by inspecting the raw SAML assertion (unless the problem occurred decrypting it, in which case this error would be stated).


  • DonF.81354 (Customer)

    Hi! An absolutely awesome tool I use for this is a browser plugin (I use Chrome, so I will share that link):

     

    SAML Tracer

     

    This will capture all the SAML traffic you are sending from your session, and it will pick up on assertions, etc. When say selecting a tile in Okta, look for the orange "SAML" lines in the logs and it gives you a nice, formatted output that is much easier to read.

     

    I am sure there are additional tools out there, but I have been using this for awhile and it has been working rather well for my needs.

     

    Thanks!

    Expand Post
    Selected as Best
  • DonF.81354 (Customer)

    Hi! An absolutely awesome tool I use for this is a browser plugin (I use Chrome, so I will share that link):

     

    SAML Tracer

     

    This will capture all the SAML traffic you are sending from your session, and it will pick up on assertions, etc. When say selecting a tile in Okta, look for the orange "SAML" lines in the logs and it gives you a nice, formatted output that is much easier to read.

     

    I am sure there are additional tools out there, but I have been using this for awhile and it has been working rather well for my needs.

     

    Thanks!

    Expand Post
    Selected as Best
  • I'm familiar with this tool, and I agree that it's a good solution when a customer with issues can schedule time to run it during a support call.

     

    Unfortunately, our operating environment is the following:

    • Medical-related, so many of our customers are 'locked-down' and can't install SAML Tracer.
    • Sometimes SAML issues are intermittent (i.e. customers IT infrastructure may sometimes send good SAML, sometimes send bad SAML). When this is the case, we often waste client-time trying to reproduce the issue.
    • We have SLA agreements to uphold. Therefore we need an audit-trail of login events and details of what went wrong. Being able to record and display bad SAML assertions we receive from clients is key.

     

    We're replacing our home-grown SAML endpoint with Okta. With our home-grown implementation we logged all unencrypted SAML assertions. We were able to trouble-shoot all sorts of problems with this telemetry, as well as demonstrate to clients errors in what they sent. We didn't just say "You did it wrong" - we could show them exactly what was wrong in an indisputable manner.

     

    If Okta doesn't log unencrypted SAML assertions when there are problems, that's a pretty big 'gap' from our home-grown system.

    Expand Post
  • xod39 (xod39)

    we ca n use : Preview the SAML assertion generated from the information above under saml setting.

    Image is not available
    it is in OIE.

    Image is not available
    Image is not available
     

    Expand Post
  • This allows you to create examples of valid SAML payloads. It doesn't allow you to view SAML payloads received by the Okta tenant (which is what I need when trouble-shooting a connectivity issue).

  • a0n5s (a0n5s)

    it can let you know what the assertion are during authentication with SAML for this user. it same as saml tracer when you login.

    • It can show me how to create SAML for a client. It can't show me the 'wrong' SAML a client may have sent. I often have to tell users what wrong information they sent in order for them to figure out what went wrong - "Oh, that looks like a SAML packet from our UAT environment instead of production - let me fix that".

  • I have control of the front-end/back-end for my application, so I was able to use the following work-around:

    1. Use my existing back-end to validate/read the existing SAML payloads our partners send us.
    2. Have the back-end create an 'echo' version of the SAML payload that targets Okta, signing it with my certificate. Save this to the client as cookies.
    3. Change the front-end so that instead of logging the user in using the cookies from 1-2, load the SAML payload created in 2 and POST that to Okta.
    Expand Post
This question is closed.
Loading
Log SAML Assertion logging