RE: [saml-dev] App to App SAML

1. App1 submits a SAML assertion (on behalf of a user) to App2
2. App2 
  to verifies the assertion and allows "app1" access to specific user data
3. 
  App1 makes a request for "foo"
4.  <-- response sent
5. App1 
  makes a request for "bar"
6. <-- response sent 

This 
model is anticipated (and one could correctly argue that the Browser SSO profile 
does exactly this in that App1 is the browser and App2 is the web server 
controlling a resource (your "foo" and "bar") that the browser wants to get 
to.

 

The 
Web Services Security: SAML Token Profile also shows how one app can talk to 
another using a SAML assertion as part of the security layer of a SOAP 
call.

 

One 
thing that you don't note is how step 3 and 5 are tield to step 1.  This 
would be critical for a useful protocol.  in the Browser SSO world, this is 
typically done by sending a cookie to the browser in Step 2 which comes back to 
the server in steps 3 and 5.  On the SOAP protocol layer you would need to 
either continue to include the SAML assertion or define a way to replace it (as 
Liberty has done in its ServiceInstanceUpdate and/or EndpointUpdate 
headers).

 

Conor