RE: [saml-dev] SAML, trust and WS.

["Cahill, Conor P" <conor.p.cahill@intel.com>]

Title: Message

 

Could the Saml Token be used together with the SSO profile ? I'll be more clear. 

This depends on alot of factors and could be possible if a) *all* the parties are the same for both interactions (browser based SSO and web service invocation) -- which usually wouldn't be the case and b) if the security requirements for the invocation are the same (e.g. a bearer token model).

 

I think that in most cases the invocation model (parties and security context) will be different and that a token generated for browser based SSO will typically be different than a token generated for web service invocation (e.g the browser SSO token will typically have a very short consumption period since it should be a relatively instantaneous operation while the web service model will typically reuse the token for longer period of time so that the web service client can make multiple invocations).  Note that I say *typically* here as there will be cases where thse are not the case.

Browser/client  tries to access Resource A on SPA.

The SPa uses the SSo profile to authenticate the User and is going to get back an assertion.

It (if policy applies) will grant access to Resource A which actually is  aclient for a Web Service B.

resource A on SPA could use WS- or Liberty profile now to access that Web Service using the SAML assertion?  

The key here is is it really resource A on SPA or is it resource A on Web Service B accessed from SP A following the SSO on SP A (and if it is the latter, I'm assuming your question is essentially can SP A use the same token when invoking Web Service B).

 

Liberty allows you to do this kind of operation by supporting a model for bootstrapping from the SSO profile into the ID-WSF profile and getting the necessary tokens for access at Web Service B.    

 

If you're trying to use the same token from SPA on SPB, I think there are issues with specifying who can consume the token although I think you can make the token universal enough to be consumed anywhere, you end up having significant security issues with such a widely consumable token.

 

If it really is SP A's resource A  and SPA just chooses to store some underlying data in WSP B, the security model from SPA to WSP B could simply be a server to server relationship without any identity (just as if Resource A was stored in some network database, it would simply be a database opteration (such as JDBC) to get to the data).  

 

Conor