Shibboleth Developers

["Scott Cantor" <>]

Peter Williams wrote on 2009-04-15:
> The server  side app needs to leverage several web calls (by design),
where
> access control is enforced by the several web service providers operating
on
> the internet (and who do participate as domains in an active directory
> forest, not do they have ADFS trusts, not do they have or Kerberos trusts)

I understand the problem, but the assertion in standard form without any
additional content enabling delegation isn't usable in that fashion without
requiring the WSP(s) or the STS/IdP or both to violate the standard. You can
do it wrong, and it's not my problem, but we certainly won't support such a
thing.
 
> Thus, webapp seeks to create an "open" security token that the "Shib SP"
> asserts (as _asserting_ party) has the shib assertion's subject value as
the
> token's saml subject (and which perhaps maps attributes too - from the app
> context and/or the shib session and/or the shib assertion).

Yes, I understand what you want to do, modulo the word "open", which I don't
understand. The proposal we put together is for exactly that use case.

> The reality is that websso-powered web apps are increasingly leveraging
> supporting business objects, which often have a web service API. Let's
> assume that the Shib SP and the STS client are formally under the same
> domain authority, being "being endpoints in the same communication stack
> with the same thread identity as far as the TCB is concerned".

Whether they're in the same administrative domain or not isn't relevant to
using SAML. Either you follow the specs or you don't. Allowing the STS to
ignore the constraints in the assertion is not really different, and much
more complex, than just allowing the STS to issue an assertion for any user
to that SP whenever it's needed.

It's when you follow the rules that you get additional security, because you
can constrain when the STS can issue the assertion by requiring the proper
inputs.

> There seem two obvious choices:
> 
>         1. the app itself simply impersonates the user (from the shib2
> session, creating a token than can be translated into the saml2 security
> token).
> 
>         2. the app "presents" the shib assertion for "translation" in act
of
> delegation (rather than impersonation_)

Yes, that's true. The former is more or less what "sender vouches" was
supposed to mean, though I think it's superfluous.

But for #2 to be correctly implemented, the assertion has to support that
capability and they do not today.
 
> In case 2, I can see the webapp naturally hosting the subject's signing
key,
> for use in HOK confirmation.

That would be a violation of private key secrecy, so no, that's not how you
do it. HoK confirmation when you delegate is based on the SP's key, not the
user's. Which is good since users rarely have keys.

-- Scott