Question - Troubleshooting SAML Authentication with Keycloak as IDP

Hello Erambateers.

I come to your forum, seeking aide, guidance, advice, and solace. I’ve trawled this forum and the learning documentation for answers, and have come up short.

Context

I’ve just started the process of deploying Eramba (Community) to evaluate it for use in our organisation. We like the feature set on paper, but making sure it does what it says it does is kind of important. We would be looking to move to an enterprise package if this solves our current problem, which is that the executive would like to get a better handle on risk and compliance.

At the moment, everything is going swimmingly, and following the learning documentation journey has been straightforward - if not long winded. It’s better than the alternative of short and meaningless documentation, though, or none at all.

Work and troubleshooting so far

We have a Keycloak deployment where we mostly use OIDC, but can support SAML in a pinch if that’s all that’s available. We’re trying to phase out LDAP traffic where possible.

I have set up Eramba using the Docker Installation method. We are additionally running this behind an NGINX reverse proxy to our DMZ so that Keycloak and Eramba can talk to each other. This hasn’t caused issues for other SAML apps in the past.

Eramba App Version: 3.24.2
DB Schema Version: 20240605095337

So far, I have followed the limited guide on configuring SAML for Eramba, but it’s heavily focussed on Azure AD SAML, and there’s not much information about any settings other than the Azure AD SAML video in the documentation portal.

I have:

  • Set up the SAML authentication connector in Eramba
  • Set up the client and client scopes in Keycloak based on the information from the connector
  • Confirmed communication between the two
  • Enabled the authentication connector as SAML in Eramba
  • Switched a user from Local to … not local … which means it should be identified by SAML connector.

These should be all the required steps to get it working, however we ran into the issue described in : Question - SAML using Keycloak as IdP - #5 by steelem

As with the above issue, we were getting “Invalid request” from keycloak; notably, the connector says to use <fqdn>/saml/saml-connectors/get-metadata but in the SAML packet information we can see it needed to be <>fqdn>/samlConnectors/getMetadata. This matched what I saw in the other forum post. We changed this setting in the Keycloak client settings, and the SAML request started working from Eramba to Keycloak.

Once I authenticate with Keycloak, the SAML response is returned to Eramba, seemingly successfully, but Eramba doesn’t do anything with it.

I have tried a few variations on the user; at the moment, the user is set so that both the username and email address fields are the users’ email address, but my preference would be to have the username be “user.name” format, not email address. I’d rather it be working than not, so if that’s non-negotiable, then so be it.

I can confirm that in my SAML response to Eramba, the SAML parameters include the “email” attribute, and in Eramba I have the identifier as “email”.

The SAML “subject” is user.name, as that’s our model, but Eramba should only be looking at the email field defined in the connector.

My actual question

Nothing is in the logs (authentication.log) at all, not even a failed attempt. The only logs that are changing are the access log and the debug log, neither of which are showing anything relevant (other than 401 unauthorised in the access log)

I would have expected to see a log from Eramba when it receives the SAML response, and fails to find a matching user, it should log that somewhere.

What am I missing? Do I need to turn up authentication logging? If so, how?

My best guess is that Eramba is seeing the SAML response, and is not matching it to a user.

I am getting no error, no feedback, and no logs on the server side, and no error in the browser on the client side - the only way I was able to determine for sure it should be working and isn’t was by using a browser extension to inspect the SAML information, and compare it to one of our other SAML apps.

So, does anyone have any ideas? I spent a few hours trying to get this to work, but without logs, or clearer documentation about the SAML connector settings, I’m spinning my tires.

NB: As an aside, this forum looks like it might be Gitlab, which is big chops. We also run gitlab internally, and love it.

As a new user, I am limited in one post per 10 minutes, and am not permitted to embed more than one media item in my post; follow up posts contain the additional screenshots for context, please excuse the 10 minute delay between posts:

How we’ve set the SAML connector in Eramba:

image

The request flow is:

The “red” line is the response which I would expect to log an error somewhere, but the only relevant log for this is the 401 Unauthorized response in the access log.

Is it correct to assume that the non-local user you have set up has access to the “Main” portal?

This OKTA config guide may also provide some clues - Question - SAML Configuration for Okta

And maybe this Azure/Entra ID setup guide - Question - SAML Configuration for Azure AD

Of course, my ability to speak SAML ends where those guides do, but I’ve gotten it running on both Okta and Azure/EntraID with those. Haven’t tried keycloak yet…

**Ninja edit - until a few years ago I was running eramba behind a NGINX proxy until it quit working behind a NGINX proxy…

Great clarifying question. Thanks for replying.

The user in question has access to the Main portal, and is in the Admin group. If/When the Local authentication mode is enabled, I can log in just fine, using the full e-mail address as the username, and the password saved to Eramba.

Once I had tested this user was locally working, I disabled “Local” and then attempted SAML. So, by deduction it should be working.

Thanks for the link to the OKTA setup. Checking this against my configuration, I am fairly confident that Eramba → Keycloak set up is correct, as Eramba sends the request for authentication to the correct Keycloak Client, and Keycloak (once it authenticates a user) sends back to Eramba the SAML information including the attribute for email. I’m less confident that the Keycloak → Eramba response is 100% correct, but it appears to be correct.

I suppose my main line of questioning isn’t “please fix my busted SAML configuration” but “how can I help myself by getting more out of the logging generated by Eramba?”

If Eramba told me what it was doing with the SAML packet, that should give me the clues I need to get it working.

Edit// my leading theory is that the difference between the Azure and OKTA guides is that our Keycloak portal uses “user.name” instead of “user.name@fqdn.com” as an email address as the “SAML Subject” is the main thing preventing this from working. The key would be if I can see in Eramba’s logs what it thinks about the information it’s being handed.

Edit 2+3// Spelling + context

Hello,

I would throw also this post into the discussion: Question - SAML using Keycloak as IdP
Regarding the logging, yes I would expect failed attempts as well. I need to have a look at that. I will provide and update shortly.

Eramba’s SAML connector does not provision user accounts on its own if my understanding is correct. You will need to use LDAP to populate the user directory even if you don’t use LDAP for authentication.

We authenticate to Eramba using Keycloak. Eramba keys the user based on their primary email address, so Keycloak needs to provide that attribute. Users sign in using their username. I think this aspect is the same for Azure or Okta.

The main reason I signed up to this forum was based on your thread, @steelem. It was actually a deciding factor for POC’ing Eramba in the first place - the crossover of Keycloak and Eramba users might be … well, just you, and then I could join that prestigious club if I can get this working.

I was hoping that you would reply, and lend some of your experience, if at all possible. The main thing I want to validate is that in the Eramba Settings → SAML Connector, the field name “email” matches the SAML attribute mapper “email”, or whether it needs a full SOAP-style formatting, or something tricky like that.

Your guidance and advice would be welcome, as it’s the only thing I can’t be sure of in my configuration.

I concur with this assessment; I have a user in Eramba set up to test, and once I can get this user working, I will import the remainder of the users.

The Keycloak realm we have running works for other applications, so it’s back-end authentication database is working well.

The Eramba configuration I have is:

Settings → Authentication

Settings → SAML Connectors → Keycloak → Edit
(Codeblock instead of screenshot, because it’s easier to digest, I have renamed the realmname and urls)

/*
Single sign on URL: https://eramba.fqdn.com/saml/saml-connectors/single-sign-on
Audience URI (SP Entity ID): https://eramba.fqdn.com/saml/saml-connectors/get-metadata
Default RelayState: https://eramba.fqdn.com/login
Assertion Consumer Service (ACS): https://eramba.fqdn.com/login?acs=1
Logout URL: https://eramba.fqdn.com/saml/saml-connectors/single-logout
Redirect URLs:
https://eramba.fqdn.com/login
https://eramba.fqdn.com/portal/policy/login
Name: Keycloak
Identity Provider: https://ourkeycloak.fqdn.com/realms/RealmNameRemoved/protocol/saml/descriptor
IDP x509 Certificate: Provided, downloaded from Keycloak
Remote sign in URL: https://ourkeycloak.fqdn.com/realms/RealmNameRemoved/protocol/saml
Email field: email
Sign SAML request: Set to off, for now, until I can get unsigned working.
SP x509 Certificate and SP Private Key are blank (signing is set to off)
Authentication Context: Set to "Password Protected Transport"
Status: Active

Finally, the user is simple:
Settings → User Management → Edit User

/*
Name: Joel
Surname: McLean
Email: joel.mclean@fqdn.com
Login Name joel.mclean ( I have also tried setting this to the email in a fit of inspiration, no change )
Local Account: Disabled
Portals: Main
Groups: Admin
Status: Active
REST APIs: Disabled

All of these details match the SAML user object provided by Keycloak.

The Keycloak Realm is just a normal realm, with the above information (urls, etc) pasted into the Client and Valid Redirect fields.

In addition to putting in the information from Eramba, I have created a Client Scope Mapper within the Eramba Client to map the attribute Keycloak has as “email” to a SAML attribute called “email”

and as demonstrated in this part of the post:

I believe that it’s named correctly in Eramba, but I’ve just got no logging to confirm that.

TL;DR

I think the configuration is correct; but if you can validate for me how your Keycloak Client has it’s mappers configured, and the value you have in Eramba’s SAML connector for the attribute name, and let me know, that would be greatly appreciated. If you had to do any other magic to make it work (flags different from a default SAML client, that you had to change to get it to work) it would also be welcome knowledge, although I acknowledge you set this up some time ago, so that information might be lost to time.

If anyone knows how to make Eramba do more and better verbose logging, that would also be appreciated, as Logging would really help me solve my own problems.

For your benefit, Sam, just so we’re both sure I’m doing this the way you would expect:
→ I log into the Eramba Container with an interactive session (not redis, mysql, or cronl containers)

  • docker exec -it eramba bash

→ Navigate to the app directory’s log location

  • cd /var/www/eramba/app/upgrade/logs

→ I tail all the log files, and then attempt to log in. I open the page in a private window at 11:39:39, and click “SAML Sign In” which redirects me to Keycloak. I authenticate with Keycloak at 11:39:58 and it send me back to Eramba with the SAML information. Here’s the only logs that get written to:

==> access/access.log <==
2024-11-13 11:39:39 info: N/A - AAA.BBB.CCC.DDD - GET (302) / "https://**domain**/"
2024-11-13 11:39:39 info: N/A - AAA.BBB.CCC.DDD - GET (200) /login "https://**domain**/login?redirect=%2F"
2024-11-13 11:39:39 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/login "https://**domain**/system-api/login?portal=&redirect=%2F"
2024-11-13 11:39:39 info: N/A - AAA.BBB.CCC.DDD - GET (200) /locales/en_US/translation.json "https://**domain**/locales/en_US/translation.json"

==> error.log <==
2024-11-13 11:39:40 error: [Authentication\Authenticator\UnauthenticatedException] Authentication is required to continue in /var/www/eramba/app/upgrade/vendor/cakephp/authentication/src/Controller/Component/AuthenticationComponent.php on line 182
Stack Trace:
- /var/www/eramba/app/upgrade/src/Controller/Component/AuthenticationComponent.php:21
... removed most of the stack trace for brevity ...
- /var/www/eramba/app/upgrade/webroot/index.php:40

Request URL: /system-api/users/info
Referer URL: https://eramba.fqdn.com/login?redirect=%2F
Client IP: AAA.BBB.CCC.DDD

==> access/access.log <==
2024-11-13 11:39:40 info: N/A - AAA.BBB.CCC.DDD - GET (401) /system-api/users/info "https://**domain**/system-api/users/info"
2024-11-13 11:39:40 info: N/A - AAA.BBB.CCC.DDD - GET (200) /settings/get-logo/login "https://**domain**/settings/get-logo/login"
2024-11-13 11:39:40 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/users/change-translation "https://**domain**/system-api/users/change-translation"
2024-11-13 11:39:59 info: N/A - AAA.BBB.CCC.DDD - POST (200) /login "https://**domain**/login?portal=1&redirect=%2F"
2024-11-13 11:39:59 info: N/A - AAA.BBB.CCC.DDD - GET (200) /locales/en_US/translation.json "https://**domain**/locales/en_US/translation.json"
2024-11-13 11:39:59 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/login "https://**domain**/system-api/login?portal=1&redirect=%2F"

==> error.log <==
2024-11-13 11:40:00 error: [Authentication\Authenticator\UnauthenticatedException] Authentication is required to continue in /var/www/eramba/app/upgrade/vendor/cakephp/authentication/src/Controller/Component/AuthenticationComponent.php on line 182
Stack Trace:
- /var/www/eramba/app/upgrade/src/Controller/Component/AuthenticationComponent.php:21
... removed most of the stack trace for brevity ...
- /var/www/eramba/app/upgrade/webroot/index.php:40

Request URL: /system-api/users/info
Referer URL: https://eramba.fqdn.com/login?portal=1&redirect=%2F
Client IP: AAA.BBB.CCC.DDD

==> access/access.log <==
2024-11-13 11:40:00 info: N/A - AAA.BBB.CCC.DDD - GET (401) /system-api/users/info "https://**domain**/system-api/users/info"
2024-11-13 11:40:00 info: N/A - AAA.BBB.CCC.DDD - GET (200) /settings/get-logo/login "https://**domain**/settings/get-logo/login"
2024-11-13 11:40:00 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/users/change-translation "https://**domain**/system-api/users/change-translation"

This is as compared to using to form login as the admin local user I have set up at they start, where I opened the login page at 11:45:31, and logged in at 11:46:04:

root@3d686e2e7d39:/var/www/eramba/app/upgrade/logs# tail -f *.log access/access.log
==> access/access.log <==
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (302) / "https://**domain**/"
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (200) /login "https://**domain**/login?redirect=%2F"
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (200) /locales/en_US/translation.json "https://**domain**/locales/en_US/translation.json"
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/login "https://**domain**/system-api/login?portal=&redirect=%2F"

==> error.log <==
2024-11-13 11:45:31 error: [Authentication\Authenticator\UnauthenticatedException] Authentication is required to continue in /var/www/eramba/app/upgrade/vendor/cakephp/authentication/src/Controller/Component/AuthenticationComponent.php on line 182
Stack Trace:
- /var/www/eramba/app/upgrade/src/Controller/Component/AuthenticationComponent.php:21
... removed most of the stack trace for brevity ...
- /var/www/eramba/app/upgrade/webroot/index.php:40

Request URL: /system-api/users/info
Referer URL: https://eramba.fqdn.com/login?redirect=%2F
Client IP: AAA.BBB.CCC.DDD

==> access/access.log <==
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (401) /system-api/users/info "https://**domain**/system-api/users/info"
2024-11-13 11:45:31 info: N/A - AAA.BBB.CCC.DDD - GET (200) /system-api/users/change-translation "https://**domain**/system-api/users/change-translation"
2024-11-13 11:45:32 info: N/A - AAA.BBB.CCC.DDD - GET (200) /settings/get-logo/login "https://**domain**/settings/get-logo/login"

==> authentication.log <==
2024-11-13 11:46:04 debug: `SUCCESS` for 'a*****n' `App\Model\Entity\User` on Main portal.

==> access/access.log <==
2024-11-13 11:46:07 info: N/A - AAA.BBB.CCC.DDD - POST (200) /system-api/login "https://**domain**/system-api/login"
2024-11-13 11:46:07 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (302) / "https://**domain**/"

==> reports.log <==
2024-11-13 11:46:07 debug: ------
2024-11-13 11:46:07 debug: Report (id:29) initialized with model: `Dashboard.DashboardReports`, type `1`, params `[  'user' => 'User::1',  'reportId' => (int) 29,  'dashboard' => true,  'async' => true]`
2024-11-13 11:46:07 debug: Reports\Block\TextBlock (1080) initialized with config: `[  'size' => '12']`
2024-11-13 11:46:07 debug: Reports\Block\TaskListBlock (1099) initialized with config: `[  'size' => '4',  'type' => '2']`
2024-11-13 11:46:07 debug: Reports\Block\TaskListBlock (1087) initialized with config: `[  'size' => '4',  'type' => '1']`
2024-11-13 11:46:07 debug: Reports\Block\TaskListBlock (1142) initialized with config: `[  'size' => '4',  'type' => '3']`
2024-11-13 11:46:07 debug: Reports\Block\ChartBlock (1136) initialized with config: `[  'size' => '12',  'model' => 'Risks',  'chartId' => '16',  'visualisations' => '1']`
2024-11-13 11:46:07 debug: Reports\Block\ChartBlock (1137) initialized with config: `[  'size' => '12',  'model' => 'CompliancePackageRegulators',  'chartId' => '4',  'visualisations' => '1']`
2024-11-13 11:46:08 debug: Report (id:29) rendering

==> access/access.log <==
2024-11-13 11:46:08 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /dashboard "https://**domain**/dashboard"
... removed request logs to website assets for brevity ...
2024-11-13 11:46:09 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /limitless_theme/css/icons/icomoon/fonts/icomoon.woff "https://**domain**/limitless_theme/css/icons/icomoon/fonts/icomoon.woff?3p0rtw="

==> debug.log <==
2024-11-13 11:46:11 notice: PaginatorComponent is deprecated, use a Cake\Datasource\Pagination\NumericPaginator instance directly.
/var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php, line: 133
You can disable all deprecation warnings by setting `Error.errorLevel` to `E_ALL & ~E_USER_DEPRECATED`. Adding `vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php` to `Error.ignoredDeprecationPaths` in your `config/app.php` config will mute deprecations from that file only.
Request URL: /app-notification/app-notifications/check/0
Referer URL: https://eramba.fqdn.com/dashboard
Client IP: AAA.BBB.CCC.DDD
Trace:
deprecationWarning /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Core/functions.php, line 328
... removed warning trace log for brevity ...
Cake\Http\Server::run() /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Http/Server.php, line 90
[main] /var/www/eramba/app/upgrade/webroot/index.php, line 40

==> access/access.log <==
2024-11-13 11:46:11 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /app-notification/app-notifications/check/0 "https://**domain**/app-notification/app-notifications/check/0"

==> reports.log <==
2024-11-13 11:46:12 debug: ------
2024-11-13 11:46:12 debug: Report (id:29) initialized with model: `Dashboard.DashboardReports`, type `1`, params `[  'user' => 'User::1',  'reportId' => (int) 29,  'dashboard' => true,  'preload' => true]`
... removed generated reports details for brevity ...
2024-11-13 11:46:12 debug: Reports\Block\ChartBlock (1138) initialized with config: `[  'size' => '12',  'model' => 'CompliancePackageRegulators',  'chartId' => '4',  'visualisations' => '1']`
2024-11-13 11:46:12 debug: Report (id:29) rendering

==> access/access.log <==
2024-11-13 11:46:12 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /dashboard "https://**domain**/dashboard?reload=1&_=1731458768350"

==> reports.log <==
2024-11-13 11:46:12 debug: ------
2024-11-13 11:46:12 debug: Report (id:29) initialized with model: `Dashboard.DashboardReports`, type `1`, params `[  'user' => 'User::1',  'reportId' => (int) 29,  'dashboard' => true,  'preload' => true]`
... removed generated reports details for brevity ...
2024-11-13 11:46:12 debug: Reports\Block\ChartBlock (783) reading from cache
2024-11-13 11:46:12 debug: Reports\Block\ChartBlock (783) rendering
2024-11-13 11:46:12 debug: Reports\Block\ChartBlock (783) writing to cache

==> debug.log <==
2024-11-13 11:46:13 notice: PaginatorComponent is deprecated, use a Cake\Datasource\Pagination\NumericPaginator instance directly.
/var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php, line: 133
You can disable all deprecation warnings by setting `Error.errorLevel` to `E_ALL & ~E_USER_DEPRECATED`. Adding `vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php` to `Error.ignoredDeprecationPaths` in your `config/app.php` config will mute deprecations from that file only.
Request URL: /app-notification/app-notifications/check/0
Referer URL: https://eramba.fqdn.com/dashboard
Client IP: AAA.BBB.CCC.DDD
Trace:
deprecationWarning /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Core/functions.php, line 328
... removed warning trace log for brevity ...
Cake\Http\Server::run() /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Http/Server.php, line 90
[main] /var/www/eramba/app/upgrade/webroot/index.php, line 40


==> access/access.log <==
2024-11-13 11:46:14 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /app-notification/app-notifications/check/0 "https://**domain**/app-notification/app-notifications/check/0"

==> reports.log <==
2024-11-13 11:46:14 debug: ------
2024-11-13 11:46:14 debug: Report (id:29) initialized with model: `Dashboard.DashboardReports`, type `1`, params `[  'user' => 'User::1',  'reportId' => (int) 29,  'dashboard' => true,  'async' => true]`
2024-11-13 11:46:14 debug: Reports\Block\TextBlock (1081) initialized with config: `[  'size' => '12']`
... removed generated reports details for brevity ...
2024-11-13 11:46:14 debug: Reports\Block\TaskListBlock (1143) rendering
2024-11-13 11:46:14 debug: Reports\Block\ChartBlock (1137) reading from cache
2024-11-13 11:46:14 debug: Reports\Block\ChartBlock (1138) reading from cache

==> access/access.log <==
2024-11-13 11:46:14 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /dashboard "https://**domain**/dashboard?reload=1&_=1731458768351"

==> debug.log <==
2024-11-13 11:46:16 notice: PaginatorComponent is deprecated, use a Cake\Datasource\Pagination\NumericPaginator instance directly.
/var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php, line: 133
You can disable all deprecation warnings by setting `Error.errorLevel` to `E_ALL & ~E_USER_DEPRECATED`. Adding `vendor/cakephp/cakephp/src/Controller/ComponentRegistry.php` to `Error.ignoredDeprecationPaths` in your `config/app.php` config will mute deprecations from that file only.
Request URL: /app-notification/app-notifications/check/0
Referer URL: https://eramba.fqdn.com/dashboard
Client IP: AAA.BBB.CCC.DDD
Trace:
deprecationWarning /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Core/functions.php, line 328
... removed warning trace log for brevity ...
Cake\Http\Server::run() /var/www/eramba/app/upgrade/vendor/cakephp/cakephp/src/Http/Server.php, line 90
[main] /var/www/eramba/app/upgrade/webroot/index.php, line 40

==> access/access.log <==
2024-11-13 11:46:16 info: ad****n (1) - AAA.BBB.CCC.DDD - GET (200) /app-notification/app-notifications/check/0 "https://**domain**/app-notification/app-notifications/check/0"

Any advice on how to turn up or tune the logging would be welcome.

Hello,

Yes, it looks all correct to me.
I can also confirm what steelem wrote, that eramba is simply pairing the email saved on the eramba side with the email from saml response.
It looks like, with the new login page, we lost logging in other than local metods. We will try to include this in the current release. Unfortunately, there is no option to enable this logging.
You will have to wait for the release :frowning:

No worries, mate, all good on that front.

I note that your post is on the 13th, and there was a release on the 14th; Software Releases but no notes about what’s coming.

I updated anyway, just in case the fix was undocumented in the release, from:
App Version: 3.24.2 | DB Schema Version: 20240605095337 | Community
to
App Version: 3.24.3 | DB Schema Version: 20240605095337 | Community

however failed SAML login attempts still do not log anything on the authentication.log

Let me know if there’s anything more I can do, otherwise, I will await a release with a fix and notes, and we will continue testing with local users.

Hello,

Yes, additional logging is included in release 3.25.0.
Hopefully, the release will go out tomorrow. Once it’s live, we can continue with the investigation.

My own configurations mirror what you shared. What do you have on the “Settings” tab of your Keycloak client? In particular, did you set the “Client ID” field to “https://<fqdn>/samlConnectors/getMetadata” ?

Thanks for the heads up about the update, Sam.

I’ve updated to 3.25.0 and now there’s logging. \o/

==> authentication.log <==
2024-11-29 12:28:01 error: `FAILURE_CREDENTIALS_MISSING` for [N/A] on Main portal with errors: [0->Found an Attribute element with duplicated Name] [1->Login credentials not found].

All of the other log files (error.log, etc) all seem to be the same.
I’ll dig into this error and see whether I can work out what it’s trying to tell me.

@steelem I believe I set this based on your original thread; it was the only way Keycloak could establish a relationship:

Solved.

There was a buried Keycloak setting: the logged error is a common error with the user_saml library, which I found a case discussed in the NextCloud github:

https://github.com/nextcloud/user_saml/issues/222

The solution in my case was that the SAML packet was providing information to Eramba in an incompatible format - changing how the client sends the information via SAML is as simple as changing one option:

(Realm) → Client Scopes → role_list (saml) → Mappers tab → role list → ‘Single Role Attribute’. and toggle from “Off (default)” to “On”.

Changing this option to “ON” from “Off” has this working for me now, straight away.

Thanks again for your help @sam and @steelem.

1 Like

Lovely. Thanks for sharing!

Thanks for sharing the solution. That setting was set to “Off” in our environment.