Okta integration callback page returning 404 on 11.10.4

Summary

We are trying to integrate Okta with an on-premise GitLab server running CE 11.10.4 following the steps in https://docs.gitlab.com/ce/administration/auth/okta.html. We have set everything up according to the document, but when we go to the Okta link, the callback page (/users/auth/saml/callback) returns a 404.

Steps to reproduce

Follow the steps in the above document.

Example Project

Not related to a specific project.

What is the current bug behavior?

User sees a 404 error instead of their dashboard.

What is the expected correct behavior?

User should be automatically signed in via Okta and see their GitLab dashboard.

Relevant logs and/or screenshots

I do see this in the application.log on the server -

Started POST "/users/auth/saml/callback" for 10.4.111.68 at 2019-05-16 10:47:36 -0700
  
ActionController::RoutingError (No route matches [POST] "/users/auth/saml/callback"):

If I do a GET to that endpoint in Postman, I get the login page back. (See screenshot).

If I do a POST to that endpoint in Postman, I get the same 404 error. (See screenshot).

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:
Current User:	git
Using RVM:	no
Ruby Version:	2.5.3p105
Gem Version:	2.7.6
Bundler Version:1.17.3
Rake Version:	12.3.2
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.5
Go Version:	unknown
GitLab information
Version:	11.10.4
Revision:	62c464651d2
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	9.6.11
URL:		https://gitdev.example.com
HTTP Clone URL:	https://gitdev.example.com/some-group/some-project.git
SSH Clone URL:	git@gitdev.example.com:some-group/some-project.git
Using LDAP:	yes
Using Omniauth:	no
GitLab Shell
Version:	9.0.0
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 9.0.0 ? ... OK (9.0.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: uid=XXX	 uid: XXX (for 100 lines)
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
260/1 ... yes
… snip ~2900 lines - all “yes” …
483/2893 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 272
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)