make saml tolerant to issuerDBSAMLPath
When these conditions are filled:
- multiple authentication methods (SSL, Kerberos, LDAP)
- a redirection URL between two authentication methods (for example Kerberos portal and LDAP portal have different URLs)
- LemonLDAP as a SAML IdP
- LemonLDAP::NG < 2.0 there is a problem of "not recognition of SAML URL". The user is then directed to LemonLDAP portal whereas the SAML process should have brought him back to the SAML SP application.
The problem is SAML has a unique set of metadata including URLs that match for one of these URLs: the Kerberos one and the LDAP one, but not both.
However, we do have a possibility to make LemonLDAP::NG tolerant to the URL thanks to issuerDBSAMLPath. We can imagine issuerDBSAMLPath contains a regex that can match more than one URL.
I suggest a patch doing the following :
- looking at the calling url and ensuring it is matching the SAML Path
- reconstructing the path of the calling URL as if it was the one in metadata.
In the patch, the normalized URL should be manipulated to match the URLs in metadatas. Thereby the URL passed to checkDestination function would be manipulated to match the URL in SAML message. (which is the same as the URL in metadata)
In my case, the Destination parameter would be "http://auth.example.com/kerberos/saml/..." Schematically :
- http://auth.example.com/kerberos/saml/...
- [kerberos auth failed, so redirection to:]
- http://auth.example.com/saml/...
- [Patch : does this URL match SAMLPath: ^/(kerberos/saml/|saml/)]
- [Patch : yes it does, so transform /saml/ into /kerberos/saml/]
As he always did, the administrator has to choose a unique URL for his SAML IdP. (in the example: /kerberos/saml) And as before, the URL must be the one of the first authentication method. (else other methods won't be called) What is brought by the patch is the possibility to make the SAML process to happen for different URL identified by a regex.