I have created an API Controller which gets called successfully
var partnerName = “TestServiceProvider”;
var relayState = “<a href=“https://xxx/samltest.aspx” ;”=“”><a href=“https://xxx/samltest.aspx";">https://xxx/samltest.aspx”;
SAMLIdentityProvider.InitiateSSO(System.Web.HttpContext.Current.Response, userName, attributes, relayState, partnerName);
the log shows —
‘Initiation of SSO to the partner service provider TestServiceProvider has completed successfully.’
however it does not redirect to the url i set in the relaysate
On the SP end i tried using an api controller and a aspx page to ‘Receive-SSO’
public HttpResponseMessage AssertionConsumerService()
{
// Receive and process the SAML assertion contained in the SAML response.
// The SAML response is received either as part of IdP-initiated or SP-initiated SSO.
bool isInResponseTo;
string partnerName;
string authnContext;
string userName;
IDictionary<string, string> attributes;
string relayState;
SAMLServiceProvider.ReceiveSSO(System.Web.HttpContext.Current.Request
,
out isInResponseTo,
out partnerName,
out authnContext,
out userName,
out attributes,
out relayState);
// now force a redirect!
var response = Request.CreateResponse(HttpStatusCode.Moved);
response.Headers.Location = new Uri(relayState);
return response;
now the aspx version
protected void Page_Load(object sender, EventArgs e)
{
try
{
bool isInResponseTo = false;
string partnerIdP = null;
string authnContext = null;
string userName = null;
IDictionary<string, string> attributes = null;
string targetUrl = null;
// Receive and process the SAML assertion contained in the SAML response.
// The SAML response is received either as part of IdP-initiated or SP-initiated SSO.
SAMLServiceProvider.ReceiveSSO(Request, out isInResponseTo, out partnerIdP, out authnContext, out userName, out attributes, out targetUrl);
if (string.IsNullOrEmpty(userName))
{
throw new ArgumentException(“A SAML Name ID is expected to be returned by the identity provider.”);
}
// If a target URL is supplied, ensure it’s local to avoid potential open redirection attacks.
if (targetUrl != null && !IsLocalUrl(targetUrl))
{
targetUrl = null;
}
// If no target URL is provided, provide a default.
if (targetUrl == null)
{
targetUrl = “~/”;
}
// Login automatically using the asserted identity.
// This example uses forms authentication. Your application can use any authentication method you choose.
// There are no restrictions on the method of authentication.
//FormsAuthentication.SetAuthCookie(userName, false);
// Save the attributes.
Session[AttributesSessionKey] = attributes;
// Redirect to the target URL.
Response.Redirect(targetUrl, false);
}
catch (Exception exception)
{
// In production application, we recommend logging the exception and redirecting the user to a generic error page.
throw exception;
}
}
I have updated the saml config on the IDP end AssertionConsumerServiceUrl and tried both SP end points and forced a RelayState in the config
I have made sure the saml.config is correct on the SP end.
but the Redirect does not happen.
Do you have any troubleshooting , debug tips on the ServiceProvider end that it has hit the AssertionConsumerServiceUrl?
I will email you the IDP log file to support@componentspace.com
thanks
Thanks for the log. It shows a SAML response being sent by your IdP using the HTTP Post SAML binding.
SAML SSO is a browser based protocol. What this means is that the HTTP Post binding results in an HTML form containing the encoded SAML response as well as some JavaScript being returned in the HTTP response. The browser should execute the JavaScript which automatically submits this form. The result is an HTTP Post of the SAML response to the SP’s assertion consumer service.
I think the issue is that you’re performing this in the context of an API controller. Even if the HTML form and JavaScript is returned successfully in the HTTP response, the caller of your API method would have to handle this correctly.
It’s much easier to let the browser handle the SAML SSO flow and not initiate SSO from within the content of a web API call. The same applies at the SP side as well.
I suggest using the browser developer tools (F12) to take a look at the network traffic to see what I mean.
SAML SSO is a browser based protocol. What this means is that the HTTP Post binding results in an HTML form containing the encoded SAML response as well as some JavaScript being returned in the HTTP response. The browser should execute the JavaScript which automatically submits this form. The result is an HTTP Post of the SAML response to the SP's assertion consumer service.
I think the issue is that you're performing this in the context of an API controller. Even if the HTML form and JavaScript is returned successfully in the HTTP response, the caller of your API method would have to handle this correctly.
It's much easier to let the browser handle the SAML SSO flow and not initiate SSO from within the content of a web API call. The same applies at the SP side as well.
I suggest using the browser developer tools (F12) to take a look at the network traffic to see what I mean.
SAML SSO is a browser based protocol. What this means is that the HTTP Post binding results in an HTML form containing the encoded SAML response as well as some JavaScript being returned in the HTTP response. The browser should execute the JavaScript which automatically submits this form. The result is an HTTP Post of the SAML response to the SP's assertion consumer service.
I think the issue is that you're performing this in the context of an API controller. Even if the HTML form and JavaScript is returned successfully in the HTTP response, the caller of your API method would have to handle this correctly.
It's much easier to let the browser handle the SAML SSO flow and not initiate SSO from within the content of a web API call. The same applies at the SP side as well.
I suggest using the browser developer tools (F12) to take a look at the network traffic to see what I mean.
Thanks for the response. I have converted my webapi to mvc controllers. now in the browser dev tools i receive the following error
the error message:
Since your browser doesn't support JavaScript, you must press the Continue button to proceed.
<input type="hidden" name="SAMLResponse" value="............."
The HTML form etc being return in the HTTP response looks correct. If this is processed by the browser it will send an HTTP Post of the SAMLResponse to the SP.
The error indicates JavaScript is trying to interpret the HTML as JSON as if this is still a web API call.
Please ensure it’s the browser that’s handling the HTTP response. Don’t use JavaScript to make a web API call to initiate SSO at the backend.
The error indicates JavaScript is trying to interpret the HTML as JSON as if this is still a web API call.
Please ensure it's the browser that's handling the HTTP response. Don't use JavaScript to make a web API call to initiate SSO at the backend.
understood, I am using Angular as the front end client. In one of your teams post reply. you mention that this can be done with Angular using asp.net core by using JWT from Core to Angular app. Do you have examples of this working using Asp.Net (not core).?
reply from one of your teams post
We have an example ASP.NET Core application (ExampleWebApi) that acts as the service provider and handles SAML SSO on behalf of an Angular app.
This is documented in our Examples Guide.
https://www.componentspace.com/Forums/8236/Examples-Guide
Once SSO completes, the ASP.NET Core application returns a JWT to the Angular app so it can make authorized web API calls.
The JWT can include claims retrieved from the SAML assertion.
We don’t have an example using ASP.NET. However, you could take a similar approach as that used with the ASP.NET Core example. The flow between the Angular app and the backend app would be the same. The difference is that the backend app would be implemented in ASP.NET rather than ASP.NET Core.