SSO with Shibboleth not working

[fluca1978]

I’m using 6.3.1, and Shibboleth 3.4.1 over nginx 1.22.

I’ve protected the /auth/sso URL and configured the Settings → Security → Third party application → SAML apt.
It seems to work, except that when I try to login I got the error:

401: Unauthorized
User 'luca@xxxx.it' could not be found.

This apparently is ok, since I’ve not created the user in the users list.
I then create a user with the above email, and also enable the automatic linking.
Then, if I try to do SSO login (in a private window, to avoid caching), I cannot login and got immediatly redirected to the login page without any error message. In the log I cannot find anything useful.
What to search for to solve the issue?

[MrGeneration]

You may want to use the correct endpoint. It is not sso but saml.
Or you just use the existing button in Zammad instead of manual fiddling your way around.

[fluca1978]

Thank @MrGeneration , shame on me, I was using the wrong endpoint.
However, I still have problems, maybe your or someone else can help me.

I’ve protected /auth/saml, and in fact if I point my browser to such URL I’m redirected to the IdP login page. So far, so good.
I do the login, then the browser is redirect again to /auth/smal and the error:

404: Requested resource was not found
No route matches [GET] /auth/saml

appears. The same 404 errror appears in the nginx logs.
Please note that in the /atuh/saml section of my ngnix I’ve placed:

location  /auth/saml/ {

    shib_request /shibauthorizer;
    shib_request_use_headers on;

    more_clear_input_headers 'displayName' 'mail' 'persistent-id';

         proxy_read_timeout 300;
         proxy_pass http://zammad-railsserver;
}

with zammad-railserver being the upstream, I’m not sure the above is correct:

upstream zammad-railsserver {
    server 127.0.0.1:3000;
}

Do I have to specify the upstream server as in the above at the end of the /auth/saml block? Or something else?

[fluca1978]

Removing the proxy_pass from the /auth/saml makes the login page to work but to redirect over and over to the login form.
I’m pretty sure I don’t need the proxy_pass because once I’ve authenticated the user I need to pass to the main page via a redirection, but I cannot dig why I’m going redirected (without any error message) to the login form again.
In the production.log there is nothing helpful.

Any idea about what to search for?

[fluca1978]

I’m still fighting with this issue, so I raised the log level to debug and I captured the following trace:

I, [2024-07-15T09:01:10.648109#51368-148900]  INFO -- : Started POST "/auth/saml" for 192.168.1.12 at 2024-07-15 09:01:10 +0200
D, [2024-07-15T09:01:10.668530#51368-148900] DEBUG -- : (saml) Request phase initiated.
D, [2024-07-15T09:01:10.669996#51368-148900] DEBUG -- : Created AuthnRequest: <samlp:AuthnRequest AssertionConsumerServiceURL='https://zammad-test.me.org/auth/saml/callback' Destination='https://zammad-test.me.org/Shibboleth.sso/Login' ID='_68990709-eea6-451b-b3c5-734e091dfd35' IssueInstant='2024-07-15T07:01:10Z' Version='2.0' xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion' xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'><saml:Issuer>https://zammad-test.me.org/auth/saml/metadata</saml:Issuer><samlp:NameIDPolicy AllowCreate='true' Format='urn:mace:dir:attribute-def:mail'/></samlp:AuthnRequest>
I, [2024-07-15T09:01:10.830220#51368-149020]  INFO -- : Started GET "/" for 192.168.1.12 at 2024-07-15 09:01:10 +0200
I, [2024-07-15T09:01:10.835453#51368-149020]  INFO -- : Processing by InitController#index as HTML
D, [2024-07-15T09:01:10.838136#51368-149020] DEBUG -- :   User Load (0.7ms)  SELECT "users".* FROM "users" WHERE "users"."id" IS NULL LIMIT $1  [["LIMIT", 1]]
D, [2024-07-15T09:01:10.840090#51368-149020] DEBUG -- :   CACHE User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" IS NULL LIMIT $1  [["LIMIT", 1]]
D, [2024-07-15T09:01:10.841503#51368-149020] DEBUG -- :   User Load (0.2ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
D, [2024-07-15T09:01:10.847495#51368-149020] DEBUG -- :   Permission Pluck (0.9ms)  SELECT "permissions"."name" FROM "permissions" INNER JOIN "permissions_roles" ON "permissions"."id" = "permissions_roles"."permission_id" INNER JOIN "roles" ON "permissions_roles"."role_id" = "roles"."id" INNER JOIN "roles_users" ON "roles"."id" = "roles_users"."role_id" WHERE "roles_users"."user_id" = $1 AND "roles"."active" = $2 AND "permissions"."active" = $3  [["user_id", 1], ["active", true], ["active", true]]
D, [2024-07-15T09:01:10.851996#51368-149020] DEBUG -- :   Rendering layout layouts/application.html.erb
D, [2024-07-15T09:01:10.852220#51368-149020] DEBUG -- :   Rendering init/index.html.erb within layouts/application
I, [2024-07-15T09:01:10.853217#51368-149020]  INFO -- :   Rendered init/index.html.erb within layouts/application (Duration: 0.8ms | Allocations: 437)
I, [2024-07-15T09:01:10.855111#51368-149020]  INFO -- :   Rendered layout layouts/application.html.erb (Duration: 2.9ms | Allocations: 1722)
D, [2024-07-15T09:01:10.860130#51368-149020] DEBUG -- :   Setting Load (0.6ms)  SELECT "settings".* FROM "settings" WHERE "settings"."area" = $1 ORDER BY "settings"."name" ASC  [["area", "Transaction::Backend::Sync"]]
I, [2024-07-15T09:01:10.860793#51368-149020]  INFO -- : Completed 200 OK in 25ms (Views: 4.9ms | ActiveRecord: 3.3ms | Allocations: 7885)
I, [2024-07-15T09:01:10.959790#51368-149320]  INFO -- : Started POST "/api/v1/signshow" for 192.168.1.12 at 2024-07-15 09:01:10 +0200
I, [2024-07-15T09:01:10.965215#51368-149320]  INFO -- : Processing by SessionsController#show as JSON
I, [2024-07-15T09:01:10.965421#51368-149320]  INFO -- :   Parameters: {"fingerprint"=>"1689343078"}
D, [2024-07-15T09:01:10.966632#51368-149320] DEBUG -- :   User Load (0.3ms)  SELECT "users".* FROM "users" WHERE "users"."id" IS NULL LIMIT $1  [["LIMIT", 1]]
D, [2024-07-15T09:01:10.967388#51368-149320] DEBUG -- :   CACHE User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" IS NULL LIMIT $1  [["LIMIT", 1]]

Apparently the login is successful, If, after being redirected to the login page, I inspect /Shibboleth.sso/Session, I can see my Shibboleth login being performed well.
Is it zammad not understanding some session variable hence requesting the login over and over?

[fluca1978]

So far, I’m at the point where I discovered that omniauth-saml is the library used to manage SAML authentication. Studying the configuration of such library, helped me to perform a login succesfully, even if it was unclear to me, in the beginning, that the IDP target URL for login and logout have to be used as GET.

In any case, now omniauth.saml is logging errors (when they occurs).

So in the end, I guess that a summary of this thread could be: if there are no logs or evidence of SAML authentication in the logs, it is because the omniauth-saml is misconfigured or not invoked at all (due to idp problems).