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

["Scott Cantor" <cantor.2@osu.edu>]

> 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).

This is what I meant in my previous response. You in fact *don't* want
bearer to be the only confirmation method in the token. And SAML 2 allows
that. You just have to figure out how to decide to put additional
confirmations in the original token.

> 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).

This is also irrelevant in SAML 2, because the bearer window is controlled
from within SubjectConfirmationData now, not from the overall token
lifetime. And that was done specifically for this use case, we just haven't
profiled it.

> 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.

This is very possible to constrain precisely, but what you do have is
privacy concerns because of all the data for SPa that might be in the token,
which is why it probably requires encryption.

-- Scott