REQ#1 - ERROR - Login Endpoint not working as expected about plugin-com.dotcms.dotsaml HOT 5 CLOSED

@chrismccracken I originally put this on the metadata issue that was nearly identical to this. Apologies.

When will users be hitting this login URI? Specifically "$SPEndpointHostname/dotsaml/login/$SAML_Config_UUID". Where in the series of requests is that occuring?

Are we expecting that to be the initial GET request to begin the login process, or is it the POST request as a user is returning from an Idp after authenticating there?

When a user hits /c or /dotAdmin or something else in the includePathArray (which can be user-defined) we figure out where to send them based on if their current Site is associated with a saml configuration. When they hit /dotsaml/login/{UUID} there isn't any request that occurs before that where we hang on to, so we don't know where they should return to.

Also there is zero guarantee that they'll initiate login on the same domain which they will return on. This means we'll have lost any indication of what they were originally requesting and have to pick some sensible default place to send them.

from plugin-com.dotcms.dotsaml.

$SPEndpointHostname/dotsaml/login/$SAML_Config_UUID is the assertion consumer service (ACS) URL that receives the SAMLResponse and processes the user's login to dotCMS after authenticating to the IDP. Clients should never initiate a connection here, all authentication sessions should be initiated by a request to a protected resource that they do not have current session access to. The initiating request should be sent to the IDP as a redirect URL parameter that the IDP can then pass back as a query string param for use by the ACS. The ACS will redirect to the original resource after the dotCMS login has been processed.

There is an outstanding issue with cross-domain requests within dotCMS where the $SPEndpointHostname does not match the initiation URL hostname, which will be resolved via a future enhancement and we do not intend to address during this code effort (there are additional cross-host session security issues around this).

from plugin-com.dotcms.dotsaml.

Excellent, thanks for the clarification. I need to read up on how IDPs handle the redirect parameters.

from plugin-com.dotcms.dotsaml.

The redirect URL was something that was working in the prior plugin before this development effort, FWIW.

from plugin-com.dotcms.dotsaml.

Tested with code from ethode-sp-endpoint-acs-rework branch.

We still need to test integration with IdP, but the endpoint is at the right URL and available.

from plugin-com.dotcms.dotsaml.