Authentik configuration

[gabrielebertolucci]

I'm trying to use your plugin (v1.1.12) against our Authentik installation, but I'm collecting only failures. Probably because I'm not so expert in SSO.......
I created a SAML provider in Authentik for GLPI, but something is clearly wrong.
May someone help me?

[DonutsNL]

Can you share the failures so i get some idea of the issues you are facing? Alternatively you could pm me on discord if you dont want to share details publicly. Rgrds Chris

[gabrielebertolucci]

Here is the error I receive after authentication

And now it's "configuration time". I've added some capital letters near fields to explain better the relations between Authentik and GLPi.

First, some screenshots from Authentik.

Second, some shots from GLPI side of configuration.

[DonutsNL]

I dont know this specific IdP, but looking at the config i notice 2 things.

1. the IdpId field is present (requirement) meaning the the ACS didnt find a SamlResponse in the Post body of the redirected request.
2. I notice that associazione del fornitore di servizi is currently configured redirect looking at its translation (so it can be translated wrongly) i think this parameter should be configured post . I assume in the current configuration the SamlResponse is packed in the URL (which the plugin doesnt support) and it should be posted instead.

Also good to know is that the plugin doesnt support idp initiated authentication. This because it makes the plugin vulnerable for replay attacks. You can mimick an idp initiated authentication by posting the SamlResponse to the url with the param "https://your.glpi.server/?samlIdpId=#" This will cause an additional (automated) roundtrip to the Idp performing a regular samlAuth. If the user isnt allready authed by the idp (replay attack), then an additional auth is enforced by the idp and the response is returned with an samlRequestId that we can validate to be unique. If the user is allready authenticated (valid idp cookie), then the user is redirected back by the idp and the user doesnt notice the additional roundtrip has been performed.

[gabrielebertolucci]

Sorry for italian language on screenshots, I've switched to english interface :-)

As you suggested, in Authentik I've switched "Service Provider Binding" (it was "Associazione del fornitore di servizi") from "Redirect" to "Post" and consequently SSO and SLO URLs in your plugin settings.

Now, when I open a new ingognito window and try to surf to "https://myGLPIfqdn", I'm forced to authenticate into "https://myIDPfqdn" (as expected), but after that I receive the following error:

then I click on the "Go home" button and I'm redirected to my Authenthic dashboard, from where I can jump to all web application configured

The new (and strange) issue happens now: if at this moment I click onto GLPI icon, I'm successfully led to GLPI as authenticated user!!!!

It's a big step forward (thanks to you), but It seems something is wrong in initial phases, and I would like to solve it.

[DonutsNL]

sorry for the late reply and thanks for your patients.

The expected flow explained:

1. the saml flow is initiated by GLPI using a browser redirect.

The redirect contains a samlRequest thats packed in the URL. Obviously the setting we changed had to do with 'how' the samlRequest is send to the IDP by the samlClient. This means that with 'redirect' the IDP expects the samlRequest to be in the URL (GET) and in the request body with 'post' .

TODO: So we need to change this setting back to redirect.
TODO: figure out if there is a simular setting for the samlResponse (how the idp sends it back to the client), this should be configured a 'POST' if not already
REMARK: Login in using the ICON is what we call an IDP initiated auth, from the saml Clients perspective we call this an unsolicited samlResponse because the client cant match it with anything other then the certificate. If the response is captured you can 'replay' it to login at a later moment (or allow a hacker to perform this replay). The plugin doesnt support this. The workarrond is to make sure the button links to https://your.glpi.instance/?samlIdpId=1. This will cause the plugin to generate a requestId and perform another automated roundtrip to the IDP to revalidate the samlResponse. This should be transparant for the user (its very quick if the user is allready authenticated).

3. the IDP handles the login using the details in the samlRequest request the samlClient (GLPI) added to the request.

The samlRequest contains important instructions for the IDP. For instance that authentication using only a password doesnt satisfy the samlClients requirements. This request also contains a unique requestId that the IDP needs to add to the samlResponse (inResponseTo). Without this value the samlResponse is not accepted by the plugin. This is our default because we dont allow unsolicited samlResponses (idp initiated authentication) as explained earlier.

REMARK: It seems that the requestId is added by the IDP when you use the button. If you used the ?samlIdpId= then this is correct, if not im not sure if this should be default behaviour by the IDP. At least it shows that the IDP is presenting the samlResponse correctly in that scenario tp be authenticated.

5. The user is redirected back to the glpi ACS by the IDP.

This redirect should initially satisfy a few conditions: 1) the idpId= should be present in the ACS url, 2) the redirect should be a POST request with a valid samlResponse= in the post body. After these conditions are met the plugin will parse the samlResponse and validate it against the settings in the configuration.

Your previous error indicated that the samlResponse was missing in the redirect performed by the IDP.

7. GLPI handles the response

If everything aligns with the configuration the samlResponse is accepted and the Claim information in the samlResponse is used to match the present fields against a known user. The plugin uses predefined fields to do the matching. namely the nameId and email. one of these should match the username field an existing glpi user. If the user doesnt exist and JIT is enabled, the plugin will create a user automatically using the provided information and trigger the samlRules to be processed for assigning a profile and groups. The plugin assumes that a default user doesnt get any permissions when created (GLPI rules).

[DonutsNL]

@gabrielebertolucci Any update on this issue?

[gabrielebertolucci]

I have to thank you @DonutsNL for your attention and dedication in providing me a reply, but - I admit - it's too technical for me.
I wasn't able to understand which changes I must apply to Authentik and GLPi settings, but - again - I know it's a very my problem and I don't want to abuse your free support.
Unfortunately, at work I cannot allocate the needed time to follow the test-correct-test flow or to study and improve my knowledge about SAML protocol.
I would like to push on the use of Authentik in our municipality, but perhaps I have bitten off more than I can chew.

[DonutsNL]

Maybe ill install it and have a go at it myself and write an instruction.