Move SAML configurations to a table of their own

[blizzz]

• adds user_saml_configurations table and migrates existing configuration
• Controller methods are added since appconfig endpoints cannot be used
  anymore. THIS IS A BREAKING CHANGE.
• Frontend code is adjusted to use new endpoints.
• security-sloWebServerDecode was changed from global to provider specific
  setting. It being global seemed to be unintended.
  • Similar case for 'sp-name-id-format'

• fix »Primary index name on "oc_user_saml_configurations" is too long.«
• set security-sloWebServerDecode to each configuration keep as is, the setting had only effect on the first configuration. Doing anything else might result in different behaviour than before, this should be avoided.
• adjust unit tests
• adjust integration tests, too
• added OCC commands
• consider OCS endpoint for configurations as replacement for appconfig endpoint → OCC
• smoke testing

---

occ commands

• saml:config:create

reserves and returns an new ID for the new SAML configuration. Not necessary to use, but if useful if there is a unknown number of confiugrations. Example:

$ php occ saml:config:create
12

• saml:config:delete

Deletes the config identified by the provided ID. No output on success.

$ php occ saml:config:delete 12

• saml:config:get [-p|--providerId PROVIDERID] [--output [OUTPUT]]

Returns all configuraitons or the one optionally specified by the --providerId parameter. Support the usual output formats (plain, json or json_pretty as of now). Example:

$ php occ saml:config:get --providerId=11 --output=json_pretty

{
    "11": {
        "general-uid_mapping": "http:\/\/schemas.xmlsoap.org\/ws\/2005\/05\/identity\/claims\/name",
        "general-idp0_display_name": "Byzantia II",
        "idp-entityId": "https:\/\/sts.windows.net\/0c4f0808-1234-abcd-9db8-1234abcdef56\/",
        "idp-singleSignOnService.url": "https:\/\/login.microsoftonline.com\/0c4f0808-1234-abcd-9db8-1234abcdef56\/saml2",
        "idp-singleLogoutService.url": "https:\/\/login.microsoftonline.com\/common\/wsfederation?wa=wsignout1.0",
        "idp-x509cert": "-----BEGIN CERTIFICATE-----\nMIIC8DCCAdigAwIBAgIQHH1B50eN+K1H4MDKJGt34jANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQD\nEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yMDExMDUxNDE5...\/iS\n-----END CERTIFICATE-----",
        "security-sloWebServerDecode": "0"
    }
}

• saml:config:set [options] [--]

Sets the specified configuration parameters for the given SAML provider. See --help for a complete list of configuration parameters. On success, the output is empty. Example:

$ php occ saml:config:set --general-idp0_display_name="My favorite IdP"  --security-lowercaseUrlencoding=1  11

[blizzz]

yeehaw, integration tests giving green lights :)

[skjnldsv]

Tests are failing on clone 🤔

[PVince81]

Apart from the POST/PUT potential mixup the rest is only minor comments.

Note: I only have very limited knowledge of this app and don't have an env to test it

[PVince81]

dejavu from SAMLSettings, or are we duplicating these on purpose to not class-load the other class before running the migration ? (please answer in a PHPDoc that clarifies if applicable)

[CarlSchwan]

The two lists are not exactly the same. lib/SAMLSettings.php contains more entries. I'm not sure if this is expected or not. @blizzz

[blizzz]

It is sort of duplicate for we cannot rely on new classes on migration as old ones may have been autoloaded. Also, when new keys are added to SAMLSettings, they are not required in the Migration class for they cannot have been added in the past. Therefore this snapshot is also reasonable.

@CarlSchwan thanks for pointing out the differences! They should be there indeed.

There is also an existing issue with security-sloWebServerDecode which is IdP-sensitive but was always read from the first config. So, tasks:

• fix security-sloWebServerDecode – set globally, but IdP sensitive
• migrate sp-x509cert, sp-name-id-format, sp-privateKey, security-sloWebServerDecode
• evaluate reading of sp-name-id-format in AdminSettings getForm (before, it took the first from config).

[CarlSchwan]

Tested locally and for me the migration wasn't run :/ I'll see if I'm able to find there the bug is

[CarlSchwan]

Tested locally and for me the migration wasn't run :/ I'll see if I'm able to find there the bug is

Found the issue: providerIds was not in the oc_appconfig table for me. The UI worked correctly for me since in that case getAppConfig for it used the default value of 1, but the migration didn't handle this case. Fixed now :)

[CarlSchwan]

I looked into details in the code, fixed a few small issues and this looks fine to me now :)

[CarlSchwan]

Found one more small issue: this PR change the min-version from 21 to 22 because of the executeQuery/executeStatement. This changes should be either reverted or indicated inside the Changelog/appinfo.xml file

[blizzz]

Appreciate all the work done on this. I am wondering where this stands? I would like to be able to use the SAML plugin with version 23.

see the comment above…