save and restore certificate / metadata configurations, and metadata previews

[giuliogatto]

I am not sure this is the right place for this, but I am trying to sum up the actions needed from a Service Provider point of view, in chronological order and trying to automate as much as possible:

STEP 1: install plugin/module STEP 2: certificate generation with openssl, either from command line or php/openssl inside the plugin STEP 3: if command line was used, manual input of .crt and .key files from the plugin interface STEP 4: Service Provider must now register with Identity Provider by sending a metadata .xml file with all correct data, including the certificate. This is the file that will have to be published to https://dominioServiceProvider/metadata. This file will have to be manually sent to the IDP but we can automate it's generation and download inside the plugin logic. For this purpose the plugin will allow to input some data like the entityID

[simevo]

I agree ! two clarifications:

STEP 3: there is a default location for the certificates, if they are generated externally just move them there and the plugin will pick them up STEP 4: actually the entityID is currently the same as the WordPress ‘home’ option; the data that impact the SP metadata are in the "metadata" tab of the settings oage

[simevo]

This issue is about making the life easier for plugin users in managing the different versions of the metadata, or externally generated metadata.

Here are a few use cases:

1. service provider development and testing: the plugin user will need to try different options until the correct settings are found; each config is saved and can be later restored
2. import/export: you have a locally running, dockerized instance of your production enviroment and you want to export the full configuration from production to development or vice-versa
3. metadata hot-swap: service provider is in production, and the admin needs to change something (i.e. organization name, refresh the certificates that are about to expire etc.); she will then need to create a provisional metadata and register it with the Identity Providers; while this administrative procedure is ongoing, the service should still operate using the previous metadata / certificates
4. federation: smaller entities (schools, small townships ...) may run wordpress sites which require SPID login, but will probably not directly operate a SP: the SP may be operated by a higher-level entity (i.e. region / metropolitan area), who will be in control of the metadata. With a separate administrative procedure, each of the lower-level entities will send their acs (attribute consuming service) endpoint (for a WP site with this plugin it would be something like: https://example.com/wp-login.php?sso=spid), the higher-level entity will assemble a single metadata which includes them all, and register it with the IdPs. It will then send back to each of the lower-level entities the config (metadata + certificate/key pair). What we need in our plugin is the capability to import that federated medata, and configure the plugin to send the SPID AuthRequest with the correct assertion consumer service and attribute consuming service indices

The UI would be something like this:

For the implementation, we would save the certificates and all the metadata-impacting settings in the WP database; the currently active certificates would still be on the disk so that the spid-php-lib can find them.

[giuliogatto]

As a note: step 2 and 3 (generation of the certificate and its location ) will probably be automated in a future release of spid-php-lib.