Skip to content

Fix OneLogin PHP SAML toolkit, doesn’t automatically extract NotOnOrAfter response from OKTA #16872

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

kalavt
Copy link

@kalavt kalavt commented May 6, 2025

SAML integration with OKTA has issue

Oops! An Error Occurred
The server returned a "400 Bad Request".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.

the root cause is OneLogin SAML PHP library didn't well handle assertionNotOnOrAfter from OKTA response.
hence

  1. patch the saml.php extractData, manually extract NotOnOrAfter from raw xml
  2. remove the Expired SAML Assertion or allow 5 seconds of clock skew if we got null notValidAfter
if ($nowUtc->greaterThanOrEqualTo($notValidAfter->addSeconds(5))) {
    Log::warning('SAML assertion is expired (with 5s clock skew).');
    abort(400, "Expired SAML Assertion");
}

here's a patch of solution 1: patch the saml.php extractData, manually extract NotOnOrAfter from raw xml

@kalavt kalavt requested a review from snipe as a code owner May 6, 2025 14:26
@kalavt
Copy link
Author

kalavt commented May 6, 2025

Hi @snipe
I've messed up with original PR.
#16869 (comment)

here's it, patching on develop branch.

@kalavt
Copy link
Author

kalavt commented May 7, 2025

@snipe may I have your feedback regards, thanks.

@snipe snipe requested a review from uberbrady May 7, 2025 11:12
Copy link
Member

@uberbrady uberbrady left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems simple enough but any time we start to mess around with Authentication it tends to be kinda scary :/

I'd like to know a little bit more about what Okta is sending for its "NotOnOrAfter" value, such that we can't seem to parse it. Are they violating the spec? (That's not uncommon, unfortunately).

I had a couple more comments I sprinkled throughout - would love it if you could get back to me on those.

I know we've had plenty of Okta SAML users in the past, and they don't seem to have needed this change - if there's an Okta-side configuration you can change to make this not needed I would definitely prefer that if possible.

Regardless, thank you for this contribution - it's very easy to read and it's very nicely targeted to what it needs to do!

@kalavt
Copy link
Author

kalavt commented May 8, 2025

hi @uberbrady,
thanks for looking into this.
yes, we have integrated with OKTA years ago and it works well (v6.1.2, we stick on this version for a long while)
but days ago I decided to upgrade the version to v8.1.2, the SSO login was broken.
we haven't change any on our OKTA SAML settings. I thought might be cause by code change.

plus, OKTA implementation of SAML protocol isn't something we can change.

Copy link
Member

@uberbrady uberbrady left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on what the output that I asked for looks like ($assertionNotOnOrAfter) - I still think we're going to need to load that into Carbon - with a line similar to the other output that you shared - new Carbon\Carbon($blah, 'UTC'); - because I imagine that's going to come back as a string and not an integer, which is what we're expecting here (I checked the source, and it normally uses a utility class to parse that value. Which obviously won't work for us (because if it did, we wouldn't need this to start with)).

@uberbrady
Copy link
Member

I appreciate your contribution here, but since Okta is one of our most popular SAML integrations, and I haven't heard about any problems about it, I am just a little too uncomfortable with taking code contributions to fix something that we aren't sure is broken, especially when we aren't exactly sure how it works.

So I appreciate you trying to contribute back, but we're going to close this for now.

For your own edification, I would wonder if perhaps the server you're using to connect to Okta might possibly have an incorrect clock? That might be how you're running into this problem.

@uberbrady uberbrady closed this May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants