Redirect not happening for multiple SPs

[maurocolella]

Hi.

I am seeing an issue where our default config "My Provider", when saved, seems to literally slip through.

It is not persisted as is. When saved, it is included in the service providers list instead, and the settings under "My Provider" revert to default (entity id: $SAML_ENTITY_ID, etc).

I am picking up an existing installation. I can only assume that the plugin has been installed through the marketplace, although the installation is maintained via git (so I am not certain that it hasn't been altered); I can see that the CraftCMS configuration yaml contains these defaults ("My Provider", "$SAML_ENTITY_ID", and other general plugin configurations, such as whether to require signatures).

Other than this, I have added explicit routing directives in the config/general.php,

'*' => [
        'loginPath' => '/sso/login/request/<idp-uuid>/<sp-uuid>
    ],

And these don't seem to do anything.

Attempting to login in all cases gives us:

Application with identifier '$SAML_ENTITY_ID' was not found in the directory <...>

Whether using a manually crafted login url that contains the relevant uuids, or the SAML login button.

Finally, I have a question. Would this loginPath setting supersede and replace password-based (direct) login? Or would SAML login and standard login still exist side-by-side?

In advance thank you for your help.

[dsmrt]

:wave: @maurocolella ,

So that $SAML_ENTITY_ID should be an environmental variable set somehow. I would check to see if that is set on the Craft instance first. I bet it's not set.

Also, Application with identifier '$SAML_ENTITY_ID' was not found in the directory <...> doesn't look like one of our errors so I'm assuming that's getting to the IdP instead of it being a string (usually a url).

Finally, I have a question. Would this loginPath setting supersede and replace password-based (direct) login? Or would SAML login and standard login still exist side-by-side?

If the loginPath is set to a saml sp endpoint, then the public logins (not cp admin logins) will go through the saml plugin.

[maurocolella]

@dsmrt thanks. This does clarify things a bit.

The question then is why does this setting from the project's config/project/project.yaml seem to take precedence as the default SAML configuration (entity id) for the website, even when I explicitly try to set a login path?

$SAML_ENTITY_ID is indeed defined explicitly as a string as part of the config.

Any of the custom login paths I use to match one of the sps defined under "providers list" ends up reporting the same error; so probably ends up attempting to use the same (incorrect) default.

[dsmrt]

$SAML_ENTITY_ID is indeed defined explicitly as a string as part of the config.

This might be set explicitly in the config but is the env var be set some where? Has anything changed since you took this over with deployments or .env? From what I'm seeing above, SAML_ENTITY_ID isn't getting set as an environmental variable. That's where I think there's a disconnect.

The sso request endpoint has the IdP and SP explicitly mapped in the loginPath but when the AuthnReqest document is sent to the IdP, the SAML_ENTITY_ID env var isn't set nor parsed, and $SAML_ENTITY_ID is just getting shoved in there as a string. I'm working on verifying this.

I don't know if this helps but I do have some docs here on this: https://saml-sp.flipboxfactory.com/configure/settings.html#plugin-settings

[dsmrt]

Here's what I did to mimic the setup you have...

Set the SAML_ENTITY_ID in the dot env in the root .env

Set the config in config/saml-sp.php

Create the "My Provider" sp. Note: I didn't edit the Entity ID shown in the following screenshot, it showed up like this due to the settings just configured in the previous steps.

After save this is what I see in the listing:

Lastly, I added the explicit login path:

[maurocolella]

@dsmrt thanks.

For the record, I am pretty familiar with linux-type environments.

The config/saml-sp.php was non-existent. I created it, hard-set it to the desired entity id (the site's url), and removed the ENTITY_ID ($SAML_ENTITY_ID) stored in the project.yaml file.

This lets me coerce the default service provider to the last one I've saved. As in your example, my provider now appears in the list with the (My Provider) mention next to it.

Still, if I go and manually save a new provider, it overrides the default, and no service provider in my setup is designated as the default anymore.

I think I am seeing two issues:

• $SAML_ENTITY_ID indeed wasn't set to anything in the runtime environment.
• Manually saving my default provider unregisters whichever default was defined previously.

In fairness, I can't conclusively say that the latter has anything to do with the plugin. This is a containerized microservice infrastructure ("modern app"). I am not sure what happens during CI (nothing obvious, but not all of the CI is visible to me), how env vars are propagated, and whether the plugin files have been modified or not.

I have a workaround / way to coerce the desired result, which lets me troubleshoot sign-on. That's enough for now.

I'll investigate our CI and the rest, and let you know if I come up with anything.

Thanks again.

[dsmrt]

@maurocolella Sounds like you got past this immediate issue. Please let me know if this needs to be reopened but I'm closing this for now. Also, let me know if you run into anything else!

[maurocolella]

For the record @dsmrt , we've worked around the issue. This is on Craft Pro 3.7.37.

We've determined that anytime composer install is re-run as part of CI, the config somehow fetches the last SP that was inserted as its default, while it fails to persist/elect a default when it is entered directly.

Is it due to a plugin conflict? Possibly.

Fwiw, I have partially cleared the plugin config from the project.yaml (entity id and the options to require signatures for responses/assertions), and moved that to config/saml-sp.php instead.

Before that, the default SP was never persisted. Options from project.yaml always took precedence.

[dsmrt]

It's a little confusing what is going on there. I know you took this project over so I'm sorry it seems overly complicated but if there's something happening in CI during composer install it's not a plugin conflict. The plugin doesn't have any composer hooks. Seems like there are some custom operations happening there.