<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
0D54z00007RUHfKCAXOkta Classic EngineIntegrationsAnswered2025-03-31T09:00:41.000Z2022-02-09T23:04:37.000Z2022-10-24T13:12:27.000Z

aqv73 (aqv73) asked a question.

Ability to set SAML AuthnRequest parameters for an IDP connection

I have a custom OIDC application configured in Okta, and it uses multiple Identity Provider connections to authenticate users, depending on where their enterprise account information originates.

 

A use case has come up where one of my Identity Provider partners is requesting us to use the SAML "ForceAuthn=true" parameter for its users. Essentially, requiring re-authentication for every sign-in instead of leveraging an existing SSO session.

 

In my model, Okta is acting as the Service Provider to the SAML IDP, but does not give me the ability to customize the parameters of the AuthnRequest. All documentation seems focused on using this parameter for an Okta SAML Application, not an Okta Identity Provider.

 

How can I accomplish this configuration? Thank you!


AnthonyL.55811 likes this.
  • aqv73 (aqv73)

    For future viewers of this thread, I am also able to confirm that this solution works for SAML.

     

    To go into a little more detail:

    • We have an OpenID application in Okta that authenticates using signInWithRedirect.
    • For a user we know will be using an external SAML Identity Provider, we include an additional parameter in that call of "prompt=login".
    • The result is that the "ForceAuthn=true" parameter is set on the SAML AuthnRequest between Okta and the SAML provider.

     

    This is tested and confirmed with SAML on both Azure AD as well as ADFS.

     

    Oddly, it DOES NOT seem to work for OpenID Identity Providers. One would expect the prompt=login to pass through intact to that authorization request, but it didn't, in our testing. You can, however, append it explicitly as a querystring parameter to the Authorization Endpoint in the IDP setup.

    Expand Post
    Selected as Best
  • aqv73 (aqv73)

    Hi Natalia.

     

    Thank you for your message. I have read through the linked article but do not believe it applies in my case. It provides instructions for how to connect a SAML Application (created via the Applications menu). It also indicates at the beginning that in the scenario discussed, "Commvault is the service provider (SP)".

     

    My scenario is the opposite direction. I am setting up a SAML Identity Provider in Okta (via the Security > Identity Providers menu). And in this model between Okta and 3rd party Identity Provider, Okta itself is the service provider (SP).

    Expand Post
  • LauraC.70509 (Customer)

    Hi Matt,

    I'm sorry this isn't an answer. We have the exact same use-case and have not found a solution either.

    @User16254393570754125507 (Okta)​  Is there a way to escalate a question when there are multiple users with the same issue?

  • aqv73 (aqv73)

    Glad to know I'm not alone, @LauraC.70509 (Customer)​ !

     

    I'm still banging my head on the SAML problem with no luck. I even tried to use the Okta API to see if maybe there were non-ui-exposed options that were hidden away in there, but nope.

     

    However, on the off chance that your IDP partner is able to support OIDC instead, I have discovered that there is a possible workaround for that protocol. I was able to add a "?max_age=0" onto the end of the Authorization endpoint url in the Okta Identity Provider setup. Not sure if all IDP's support that parameter, but in our sandbox Azure instance it was getting passed through from Okta successfully and effectively prompting for login at each new authentication request.

    Expand Post
  • LauraC.70509 (Customer)

    Hi Matt,

     

    Thanks so much for the tip about max_age! It led me to our eventual solution which is to add prompt=login as a query param on the okta authorization endpoint. We traced the SAML request on that and it does set ForceAuthn=true in the SAML request.

     

    I can confirm that it does work with Azure AD B2C.

    Expand Post
  • aqv73 (aqv73)

    For future viewers of this thread, I am also able to confirm that this solution works for SAML.

     

    To go into a little more detail:

    • We have an OpenID application in Okta that authenticates using signInWithRedirect.
    • For a user we know will be using an external SAML Identity Provider, we include an additional parameter in that call of "prompt=login".
    • The result is that the "ForceAuthn=true" parameter is set on the SAML AuthnRequest between Okta and the SAML provider.

     

    This is tested and confirmed with SAML on both Azure AD as well as ADFS.

     

    Oddly, it DOES NOT seem to work for OpenID Identity Providers. One would expect the prompt=login to pass through intact to that authorization request, but it didn't, in our testing. You can, however, append it explicitly as a querystring parameter to the Authorization Endpoint in the IDP setup.

    Expand Post
    Selected as Best
    • @aqv73 (aqv73)​ 

      I'm trying to get the ForceAuthn = true set in the SAML request when federating to a SAML idp via a pkce sign in flow app in okta. I have tried:

      • by setting the prompt=login query parameter for the /authorize endpoint from the oidc app
      • by setting the prompt=login query parameter for the "IdP Single Sign-On URL" with Request Binding set to HTTP POST
      • by setting the prompt=login query parameter for the "IdP Single Sign-On URL" with Request Binding set to HTTP REDIRECT
      • by setting the ForceAuthn=true query parameter for the "IdP Single Sign-On URL" with Request Binding set to HTTP POST
      • by setting the ForceAuthn=true query parameter for the "IdP Single Sign-On URL" with Request Binding set to HTTP REDIRECT

      None if these worked.

      Any insight?

      Expand Post
      • aqv73 (aqv73)

        @User16191222754363368807 (Customer)​ Based on your description of what you have tried, am I correct in understanding that you are attempting to set these parameters from the Okta configuration side? ie: "Identity Provider" or "Application" configurations, respectively?

         

        We did not find any way, from Okta configuration alone, for this to work. Our solution involved customizing the Client user application itself that was initiating the login such that it passes the "prompt=login" parameter when it authenticates to Okta.

        Expand Post
  • sats.09549 (Customer)

    Hi. Can you please elaborate more here? Specially this point "We have an OpenID application in Okta that authenticates using signInWithRedirect". What if I don't have any OpenID app and I just want Okta when acting as a SP to set "ForceAuthn=true" in the AuthRequest? I did not understand the OpenID concept here to turn  "ForceAuthn=true" in SAML AuthRequest through Okta.

     

     

    Expand Post
  • aqv73 (aqv73)

    Hi. Unfortunately I was not able to find a way within Okta Admin to configure this behavior directly on a SAML Identity Provider such that it applied to all interactions with that IdP.

     

    Instead, what we discovered is a means to pass-thru the instruction from an OpenID based application and Okta, when mapping between App and IdP, is able to somehow (apparently undocumented) convert an OpenID "prompt=login" parameter into a SAML "ForceAuthn=true" parameter.

    Expand Post
10 of 11
This question is closed.
Loading
Ability to set SAML AuthnRequest parameters for an IDP connection