Some assumptions/tips: - This works best if webapp.example.edu 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 data.example.edu SP is assumed to be configured to use the same IdP as webapp.example.edu. In theory, it is possible to use this in a federated context, but requires being able to request a particular IdP at the data.example.edu SP (for example, by having a discovery service that can be fed the entityID from the Shib-Identity-Provider variable/header from webapp.example.edu, or a parameter on the web service that can be dropped into a SessionInitiator URL).
- The client JavaScript from webapp.example.edu 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 data.example.edu 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 webapp.example.edu.
|