Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



Some assumptions/tips:

  • This works best if requires Shib authentication as well.  This allows the user to get "logged in" the usual way, within their normal browser environment, to get an IdP session established.  Then you don't need to worry about the IdP returning login forms or the like to your XmlHttpRequest.
  • The IdP and SP must support the HTTP POST SAML binding for both requests and responses.  XmlHttpRequest will follow redirects, but doesn't propagate the CORS headers along the way, which results in failures.
  • The SP is assumed to be configured to use the same IdP as  In theory, it is possible to use this in a federated context, but requires being able to request a particular IdP at the SP (for example, by having a discovery service that can be fed the entityID from the Shib-Identity-Provider variable/header from, or a parameter on the web service that can be dropped into a SessionInitiator URL).
  • The client JavaScript from needs to be aware of the SAML transaction, since it needs to perform the FORM POSTs.
  • You might want to think about how to handle a situation where there is no valid IdP session (perhaps it expired). One possible option is to have the SP set the isPassive flag on the SAML authentication request, so you get a SAML error instead of a login form as a response.  It's probably a Bad Idea to display the login form to the user and mediate a real login, as it makes the user's IdP look like it's on

Filter by label (Content by label)
cqllabel in ("cors","xmlhttprequest","cross-origin","ajax") and type = "page" and space = "IDP30"
labelsajax XmlHttpRequest cross-origin CORS