Closed cbois closed 1 year ago
Hi @cbois
do you expose (and consume) your SAML authenticated route on https
?
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"
Hi @cbois,
Could you try to change the The protocol binding for the login request
from POST
to redirect
and try to login again ?
Done In Otoroshi :
and allowed on the IdP configuration :
After new login, unexpected result...
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 ?
@cbois
also can you provide us an extract of the ping federate module ?
moving this one to v16.7.0 as we need to release now
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
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" />
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
I have received the file and take a look asap
@cbois Just a quick question, how do you deploy otoroshi ?
@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?
@cbois can you try with this build please ? the link will work for 24h hours
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).
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.
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...
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
@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
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?
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 ?
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
@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
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 !
Cool, i'll still provide you another build to try to be sure that I didn't broke anything with my last fixes
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
@cbois any news ?
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
awesome, i'm closing the issue then. everything will be included in the 16.7.0 release that should be out next week
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):
Ready for a demo if you want to go further in real conditions.
Thanks