SP-initiated SSO Query

SAML for ASP.NET
1

Hi,

Seem to have encountered a strange issue although odds are I’m doing something silly.

I created a simple ASP.Net Web Form which has the below code to achieve an SP-initiated login.

protected void btnSubmit_Click(object sender, EventArgs e)
{
    var ds = SingleSignOn.GetSingleSignOnUserByEmail(txtEmail.Text);

    if (ds == null)
    {
        ltErrorMessage.Text = Alert.Danger("Please check email address." + Environment.NewLine + " Please email " + General.GetSupportEmail() + "for support.");
        return;
    }

    var identityProviderName = ds.Tables[0].Rows[0]["identity_provider_name"].ToString().Trim();

    SAMLServiceProvider.InitiateSSO(Response, "", identityProviderName);

    ltErrorMessage.Text = Alert.Success("You will now be directed to login." + Environment.NewLine + " Please email " + General.GetSupportEmail() + "for support.");
}

As you can see the identityProviderName is returned from the database based on the users email address.

The strange thing is that it works exactly as expected on Firefox and I’m redirected to Microsoft to login but on Chrome and Edge I don’t get redirected at all.

Debugging and it is still reaching the SAMLServiceProvider.InitiateSSO call but as I say no redirection occurs.

Is there anything else I should be doing before or after the SAMLServiceProvider.InitiateSSO(Response, “”, identityProviderName); line?

Thanks in advance.

2

I don’t see any obvious issues with your code.

The call to SAMLServiceProvider.InitiateSSO should result in a 302 redirect HTTP response.

Make sure that there’s no code after the call to SAMLServiceProvider.InitiateSSO that writes to the HTTP response.

If there’s still an issue, I suggest using the browser developer tools to take a look at the network traffic. This should provide some clues as to what’s happening if you don’t see the 302 redirect.

You’re welcome to capture the network traffic and send the exported HAR file as an email attachment to support@componentspace.com mentioning your form post, if you’re not sure what’s happening.

3

Using the developer tools helped me identify that the issue lay with my content security policy which contained

form-action 'self';

Changing this to the below resolved the issue.

form-action 'self' https://login.microsoftonline.com;

The below URL contains the warning “Whether form-action should block redirects after a form submission is debated and browser implementations of this aspect are inconsistent (e.g. Firefox 57 doesn’t block the redirects whereas Chrome 63 does).” which explains why I was getting different behaviour on the various browsers.

CSP: form-action - HTTP | MDN (mozilla.org)

Many thanks for the help!

4

Thanks for the update and sharing this information.