[Satosa-dev] PR for SAMLUnsolicitedFrontend

Hi, I just submitted a first draft of a PR for the SAMLUnsolictedFrontend class. The class provides all of the functionality of the SAMLFrontend class but also enables an "unsolicited" endpoint that can be used to initiate a SAML flow using a proprietary set of query string parameters that are not part of any SAML standard but follow closely similar functionality from the Shibboleth project. For example, one might do a GET to (line breaks added and query string not encoded for clarity) https://myproxy.my.org/saml2/unsolicited?\ providerId=https://mysp.my.org/sp/shibboleth& target=https://mysp.my.org/secure& shire=https://mysp.my.org/Shibboleth.sso/SAML2/POST& discoveryURL=https://mydisco.my.org/ This will cause a flow where https://mydisco.my.org/ is used for IdP discovery followed by a SAML <Response> being sent to the SP with entityID https://mysp.my.org/sp/shibboleth at the ACS URL https://mysp.my.org/Shibboleth.sso/SAML2/POST& and with relay state target=https://mysp.my.org/secure& The providerId query string is required. The others are optional. To prevent being an open relay the SP entityID must match one found in the trusted metadata, the ACS URL must match one found in the trusted metadata for the SP, the relay state URL must have a scheme, host, and port that matches the ACS URL, and the discovery service URL must be whitelisted in the configuration. The relay state URL condition could be more sophisticated. The functionality and the names of the input query parameters are inspired by the Shibboleth IdP functionality described at https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfigur… and the SP functionality for discoveryURL described at https://wiki.shibboleth.net/confluence/display/SP3/ContentSettings I am not married to the names of the query parameters--aligning with the Shibboleth project seems to make some sense, but they are using 'shire' for historical reasons and a better name would be something like 'acs_url' or even just 'acs'. The configuration is the same as for the SAMLFrontend base class, except that you add something like unsolicited: endpoint: unsolicited discovery_service_whitelist: - https://mydisco.my.org/ With that configuration the endpoint is exposed at <backend name>/unsolicited If instead you had unsolicited: endpoint: foo/bar discovery_service_whitelist: - https://mydisco.my.org/ then it would be exposed at <backend name>/foo/bar I have not written any tests yet nor updated the documentation. If nobody raises any objects I will proceed with doing that. All input welcome. Thanks, Scott K