Auth module - SAML : Authentication successfull, but loop to login page

[cbois]

Hello!

Otoroshi v16.2.1

I created (manually) a SAML V2 auth module in Otoroshi, and set up the plugin on a simple route in order to secure with SSO an app without any authentication. I use PingFederate as Identity Provider.

The IdP login page is shown when I try to access to the route 👍 The authentication process is fine : I can see the SAML assertion in my browser (with "SAML Message Decoder" chrome plugin), and my ActiveDirectory profile is here, with AD groups and all usefull stuff to proceed 👍

The problem is that i'm always redirected to login page, and not to the target app. It sound like a bad redirection config, or missing cookie, or....

No certificate or signature validation is actually active.

Here's my Auth Module config (anonymized):

---
apiVersion: "proxy.otoroshi.io/v1"
kind: "AuthModule"
metadata:
  name: "app-saml-auth-env"
spec:
  _loc:
    tenant: "default"
    teams:
    - "default"
  type: "saml"
  id: "auth_mod_39611583-66e9-4981-808c-9a2fde86xxx"
  name: "app-saml-auth-env"
  desc: "New auth. module"
  sessionMaxAge: 86400
  clientSideSessionEnabled: false
  userValidators: []
  singleSignOnUrl: "https://my-idp:port/idp/startSSO.ping?PartnerSpId=com:example:app:env"
  singleLogoutUrl: "https://my-idp:port/idp/startSSO.ping?PartnerSpId=com:example:app:env"
  credentials:
    signingKey:
      certificate: null
      privateKey: null
      certId: null
      useOtoroshiCertificate: false
    encryptionKey:
      certificate: null
      privateKey: null
      certId: null
      useOtoroshiCertificate: false
    signedDocuments: false
    encryptedAssertions: false
  tags: []
  metadata: {}
  sessionCookieValues:
    httpOnly: true
    secure: true
  issuer: "http://my-idp.fed"
  validatingCertificates: []
  validateSignature: false
  validateAssertions: false
  signature:
    algorithm: "rsa_sha256"
    canocalizationMethod: "exclusive"
  nameIDFormat: "unspecified"
  ssoProtocolBinding: "post"
  singleLogoutProtocolBinding: "post"
  usedNameIDAsEmail: true
  emailAttributeName: "Email"

Ready for a demo if you want to go further in real conditions.

Thanks

[mathieuancelin]

Hi @cbois

do you expose (and consume) your SAML authenticated route on https ?

[cbois]

I use the "Force HTTPS Traffic" plugin on my route, and I consume it via https://app-env.mydomain.fr The target(backend) is http only.

  plugins:
  - enabled: true
    debug: false
    plugin: "cp:otoroshi.next.plugins.ForceHttpsTraffic"
    include: []
    exclude: []
    config: {}
    plugin_index:
      pre_route: 0
    nodeId: "cp:otoroshi.next.plugins.ForceHttpsTraffic"
  - enabled: true
    debug: false
    plugin: "cp:otoroshi.next.plugins.AuthModule"
    include: []
    exclude: []
    config:
      pass_with_apikey: false
      auth_module: null
      module: "auth_mod_39611583-66e9-4981-808c-9a2fde86f837"
    plugin_index:
      validate_access: 0
    nodeId: "cp:otoroshi.next.plugins.AuthModule"

[Zwiterrion]

Hi @cbois,

Could you try to change the The protocol binding for the login request from POST to redirect and try to login again ?

[cbois]

Done In Otoroshi :

and allowed on the IdP configuration :

After new login, unexpected result...

[mathieuancelin]

Hi @cbois,

can you provide us edited versions of otoroshi logs, ping federate logs and the browser request has .har file in order to understand what's happening please ?

[mathieuancelin]

@cbois

also can you provide us an extract of the ping federate module ?

[mathieuancelin]

moving this one to v16.7.0 as we need to release now

[cbois]

Hi @cbois,

can you provide us edited versions of otoroshi logs, ping federate logs and the browser request has .har file in order to understand what's happening please ?

Hi

Otoroshi logs are here :

Quite short, but the athentication attempt using OpenSAML appears

2023-07-20 10:01:02,561 [INFO] from org.opensaml.core.config.InitializationService in otoroshi-actor-system-akka.actor.default-dispatcher-12 - Initializing OpenSAML using the Java Services API

Nothing before or after this message in log file. And not more verbose with these loggers activated :

    <logger name="otoroshi-saml-validator-utils" level="DEBUG" />
    <logger name="otoroshi-global-saml-config" level="DEBUG" />

PingFederate are here :

We can see HTTP 500 and the redirect URI :

10.10.0.36 - - [20/juil./2023:08:01:03 +0000] "GET /idp/startSSO.ping?PartnerSpId=com:example:app:env?SAMLRequest=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmxxxxReallyLongSAMLRequestxxxx%3D%3D&RelayState=hash%3D8dba95a6b1df0aa50c58cfddda2d3431a3197586e5e28fe344b170912d3b677a%26desc%3Droute_255e2ed59-7756-4b5c-a0d3-22ec8b9e721c%26redirect_uri%3Dhttps%3A%2F%2Fexample-app-env.domain.fr%2F HTTP/2.0" 500 1648 

I found this message in another PingFederate log file. Not absolutely sure it's related, but timestamps seems to match :

Caused by: org.eclipse.jetty.server.QuietServletException: org.sourceid.websso.servlet.reqparam.InvalidRequestParameterException: [PartnerSpId, PARTNER] or [TargetResource, TARGET] are required for invoking: /idp/startSSO.ping
    at org.sourceid.servlet.ServletExceptionSupport.throwServletException(ServletExceptionSupport.java:30) ~[pf-protocolengine.jar:?]
    at org.sourceid.websso.servlet.IntegrationControllerServlet.process(IntegrationControllerServlet.java:88) ~[pf-protocolengine.jar:?]
    at org.sourceid.websso.servlet.EnforcerServletBase.checkProcess(EnforcerServletBase.java:74) ~[pf-protocolengine.jar:?]
    at org.sourceid.websso.servlet.EnforcerServletBase.doGet(EnforcerServletBase.java:130) ~[pf-protocolengine.jar:?]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) ~[servlet-api-3.1.jar:3.1.0]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[servlet-api-3.1.jar:3.1.0]

I send you all diagnostic files privately (not easy to make it anonymous, without loosing important elements). If it's a problem, just let me know

[mathieuancelin]

I have received the file and take a look asap

[mathieuancelin]

@cbois Just a quick question, how do you deploy otoroshi ?

[cbois]

@cbois Just a quick question, how do you deploy otoroshi ?

Deployed on-premise (RedHat-like OS), fat jar method. Cluster Mode (with only a leader for now, workers coming soon). Datastore : PostgreSQL

Do you need some config file?

[mathieuancelin]

@cbois can you try with this build please ? the link will work for 24h hours

https://otoroshi-states.cellar-c2.services.clever-cloud.com/test_builds/otoroshi.jar?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=O1ZJQYVP8FT2IKU3412F/20230720/us-east-1/s3/aws4_request&X-Amz-Date=20230720T141241Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=0c4939064d0e07449a6d5e80af9ec30ed0d9b7408ce0bc89672e6c2cb81664e2

[cbois]

Thanks! Version 16.6.0-dev is up.

I don't have the previous error which occured when I changed POST -> Redirect. But I'm back in an infinite loop on login page.

Otoroshi logs are not more verbose. PingFederate seems to validate SAML assertions. I send a new har capture (privately).

[mathieuancelin]

Ok I think I found the issue, it seems the login callback from ping federate is not well configured, it should target the otoroshi callback route (something like https://privateapps.my.domain/privateapps/generic/callback) and we expect to get initial RelayState value from query string or post body in the callback

also we found something like:

the correct endpoint to send SAML Requests is /idp/SSO.saml2 as covered in IdP protocol endpoints. This is a somewhat common misconfiguration.

[cbois]

Hi

I changed the Assertion Consumer Service URL with : https://`OTOROSHI_PRIVATEAPPS_SUBDOMAIN.OTOROSHI_DOMAIN`/privateapps/generic/callback

BUT : I can't see the RelayState in url / body when I watch the http traces...

The SAML assertion is always clean and valid. The redirection occurs following the configured ACS :

I also tried to append param ?connection=com:example:app:env to match with PingFederate identifier (no effect). I'm not sure which "connection" setting I'm supposed to specify here, and if it's required to redirect properly...

the correct endpoint to send SAML Requests is /idp/SSO.saml2 as covered in IdP protocol endpoints. This is a somewhat common misconfiguration.

I tried it too, but the whole auth process fails in PingFederate with a custom PingF error message...

Assuming the auth. process works using standard PingFederate "SSO Application Endpoint" (as the SAML assertion is valid using this one), I suppose the error is elsewhere...

[mathieuancelin]

Hi @cbois

can you send use privately the .har file with the new setup ? also can you try with this build : https://otoroshi-states.cellar-c2.services.clever-cloud.com/test_builds/otoroshi.jar?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=O1ZJQYVP8FT2IKU3412F/20230724/us-east-1/s3/aws4_request&X-Amz-Date=20230724T120249Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=2783ee058f2fbd651309cd66d414e51e6b744e6b0260861c0edd3f4cd45cd33f

[mathieuancelin]

@cbois Can you try with the last build ? https://otoroshi-states.cellar-c2.services.clever-cloud.com/test_builds/otoroshi.jar?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=O1ZJQYVP8FT2IKU3412F/20230724/us-east-1/s3/aws4_request&X-Amz-Date=20230724T124618Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=480b5f78b3fe614de86de65685be1a91bfa7cf5003caa20f88e0ce55109ab93c

[cbois]

Hello @mathieuancelin

Seems to be better with this new release! Otoroshi logs are :

2023-07-25 10:32:27,492 [DEBUG] from otoroshi-saml-validator-utils in otoroshi-actor-system-akka.actor.default-dispatcher-11 - Response Issuer validated

New situation after successfull login appears now :

If I reload the original url like suggested by Otoroshi, I get access to the backend. Is there a leeway setting that I can check?

[mathieuancelin]

ok, i think it's just a missing redirect uri on otoroshi side. I will make a new build tomorrow to try. what happens when you try it in an anonymous browser session ? do you still end up on the privateapps home page ?

[cbois]

what happens when you try it in an anonymous browser session ? do you still end up on the privateapps home page ?

Oh yes, sorry, I had a try but didn't report. The same effect happens with an anonymous browser session : I'm redirected to Otoroshi (privateapps) Home page

[mathieuancelin]

@cbois can you try the full login process with this build ? https://otoroshi-states.cellar-c2.services.clever-cloud.com/test_builds/otoroshi.jar?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=O1ZJQYVP8FT2IKU3412F/20230726/us-east-1/s3/aws4_request&X-Amz-Date=20230726T094915Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=818d0984abefcd573088f21a51026928ba0104ae3828e380f2d206debec1b474

[cbois]

Just deployed... and it works!!! 🥇 Ok too with anonymous browser session.

We'll wait for next release (16.7.0 ?) to go further with SAML Auth Module automation.

Thanks for your help @mathieuancelin !

[mathieuancelin]

Cool, i'll still provide you another build to try to be sure that I didn't broke anything with my last fixes

[mathieuancelin]

@cbois can you try this one ? https://otoroshi-states.cellar-c2.services.clever-cloud.com/test_builds/otoroshi.jar?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=O1ZJQYVP8FT2IKU3412F/20230726/us-east-1/s3/aws4_request&X-Amz-Date=20230726T135113Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=5fe94e25e2a73a114c2b825e96e2f5248c691c7c4dce797e7ad75f9ca1951680

[cbois]

I have to wait tomorrow before deploying this new version (we have a demo on Otoroshi tomorrow morning). I have stored the jar file, I give you a feedback ASAP

[mathieuancelin]

@cbois any news ?

[cbois]

No problem with this new release, It seems to work like the previous one.

Classic or anonymous browser sessions are OK. The first access requires login and PingFederate login form appears. Authentication process is OK. Redirection is OK to the target private app. If I try a new login, no login form appears, I'm autorized to access the app.

So, for our use case, this release is perfect! Thanks again for your help @mathieuancelin and @Zwiterrion

[mathieuancelin]

awesome, i'm closing the issue then. everything will be included in the 16.7.0 release that should be out next week