OpenCTI-Platform / opencti

Open Cyber Threat Intelligence Platform
https://opencti.io
Other
6.32k stars 932 forks source link

Okta issue after upgrading to 5.11.14 version #4987

Open rpudlowski93 opened 11 months ago

rpudlowski93 commented 11 months ago

Description

I made the upgrade process from 5.10.3 version to 5.11.14 version and the application is working fine but my Okta integration for SSO is not working as expected.

Environment

  1. EKS DEPLOYMENT
  2. OpenCTI version: 5.11.14

Reproducible Steps

Upgrade opencti and all the connectors to 5.11.14 version from 5.10.3

Expected Output

I would like to use OKTA as my SSO and be redirected to opencti dashboards with authenticated user

Actual Output

Application is working fine but when I use Okta to login to opencti I'm getting blank page with simple

Found. Redirecting to

Additional information

I can add manually simple ";" at the end of my url when the blank page appears and the redirect works fine. I'm redirecting to the dashboard with authorised user so looks like simple issue with redirecting, not with authentication

It was working fine in 5.10.3 version.

Screenshots (optional)

nino-filigran commented 11 months ago

@rpudlowski93 Do you have any logs or any other inforamation that could be useful? Additionnaly can you raise your issue on Slack, OpenCTI channel?

Jipegien commented 10 months ago

@rpudlowski93 do you still have the problem? Have you any additional info?

robert-pudlowski-mox commented 10 months ago

hi guys, @nino-filigran @Jipegien which informations could be useful for You?

We made the upgrade on two environment from 5.10.3 version to 5.11.14 version and the issue apprears in both envs. When we use okta dashboard in order to login to opencti we are getting the information "Found. Redirecting to" but when I enter the dashboard directly, it works as it should. Looks like some issue with redirection.

Jipegien commented 10 months ago

@Kedae do you think of someone on the team who could help with that ?

jmcnatt commented 8 months ago

Hey @nino-filigran and @Jipegien - I'm also experiencing this issue with version 5.12.29.

What type of logs would help here? Anything specific from the opencti-platform container?

nino-filigran commented 8 months ago

@jmcnatt could you please:

  1. Record a quick video of the problem
  2. Provide us with your config, hiding sensitive details such as tokens.
nino-filigran commented 7 months ago

@rpudlowski93 & @jmcnatt are you still having the issue?

max-frank commented 2 weeks ago

Can confirm this issue still exists in 6.3.5 essentially what seems to be happening is the following flow

  1. https://my.opencti.example/auth/saml -> HTTP 302
  2. https://myoktaexample.okta.com/home/<redacted>/<redacted>/<redacted>?SAMLRequest=<redacted>&RelayState=%2Fdashboard -> HTTP 302
  3. https://myoktaexample.okta.com/app/<redacted>/<redacted>/<redacted> -> HTTP 302
  4. https://myoktaexample.okta.com/app/<redacted>/<redacted>/sso/saml -> HTTP 200
  5. Okta side login flow happens
  6. https://myoktaexample.okta.com/login/token/redirect?stateToken=<redacted> -> HTTP 200
  7. https://my.opencti.example/auth/saml/callback -> HTTP 302 (but the location header is not set)

With page content at 7 being this:

<p>Found. Redirecting to </p>

Essentially it seems that the POST call to /auth/saml/callback gets an HTTP redirect but without location header so nothing happens. My best guess currently is that something changed and behavior before worked with SSO, Recipient and Destination URL all being set to /auth/saml/callback, but now it doesnt 🤔 or at least as far as redirection is concerned. Or alternatively an issue with the RelayState getting lost somehow 🤔

OpenCTI SAML config env vars:

PROVIDERS__SAML__CONFIG__ORGANIZATIONS_DEFAULT: '["<My Org>"]'
PROVIDERS__SAML__STRATEGY: SamlStrategy
PROVIDERS__SAML__CONFIG__ISSUER: <Okta App Name>
PROVIDERS__SAML__CONFIG__ENTRY_POINT: https://myoktaexample.okta.com/home/<redacted>/<redacted>/<redacted>
PROVIDERS__SAML__CONFIG__SAML_CALLBACK_URL: https://my.opencti.example/auth/saml/callback
PROVIDERS__SAML__CONFIG__CERT: <Okta App SAML Cert>
PROVIDERS__SAML__CONFIG__AUDIENCE: https://my.opencti.example/auth/realms/citeum/protocol/saml

Okta App Config:

Single Sign On URL:         https://my.opencti.example/auth/saml/callback
Recipient URL:              https://my.opencti.example/auth/saml/callback
Destination URL:            https://my.opencti.example/auth/saml/callback
Audience Restriction:       https://my.opencti.example/auth/realms/citeum/protocol/saml
Default Relay State:
Name ID Format:             Unspecified
Response:                   Signed
Assertion:
Signature:                  Signed
Signature Algorithm:        RSA_SHA256
Digest Algorithm:           SHA256
Assertion Encryption:       Unencrypted
SAML Single Logout:         Disabled
SAML Signed Request:        Disabled
authnContextClassRef:       PasswordProtectedTransport
Honor Force Authentication: Yes
Assertion Inline Hook:      None (disabled)
SAML Issuer ID:             http://www.okta.com/${org.externalKey}
max-frank commented 2 weeks ago

Ok I have identified the problem and its basically a configuration issue on the Okta side.

At least in our configuration we were using the embed app URL as the SAML entry point. This will allow for a successful login but RelayState cannot be forwarded using this. Instead one has to use the IdP SSO URL.

The IdP SSO URL can be found by going to the "Sign-On" tab in the app config and clicking "View SAML setup instructions". With this URL Okta will properly forward the RelayState and upon login you will be redirected correctly to the page you initiated the login from.

I suspect previously OpenCTI redirected to the dashboard by default upon receiving a valid SAML assertion, but now its expecting to receive a RelayState. This explains why the Location header is empty and the page displays

<p>Found. Redirecting to </p>

the template is expecting to have an URL/relative URL to output, but as the RelayState is not set its empty.

@rpudlowski93 & @jmcnatt I believe your setup is running into the same issue. CC: @nino-filigran