Shibboleth Developers

[Peter Williams <>]

If the app can signal Shib SP to selectively perform multiple act of 
delegation (by "proper" means) on async bindings, this seems fine. Rather 
than the app having being responsible for controlling the distributed trust, 
it simply asks Shib to "setup an onward channel" (using the standard 
profile(s) that enforce the standard, controlled, delegation model.)

Just seems strange that the webSSO idp should have to know anything about 
domains/addressing/policies of the web service endpoints, first. While 
obviously the IDP should have a circle of trust that includes the web service 
providers, that a particular SP leverages a particular set of providers on 
any given transaction should not be known to or controlled by the IDP (or an 
upstream idp in idp-proxying)

> -----Original Message-----
> From: Scott Cantor 
> [mailto:]
> Sent: Wednesday, April 15, 2009 11:10 AM
> To: 
> 
> Subject: RE: [Shib-Dev] handing off assertion from websso to STS
> translating to saml2 profile of security token
>
> 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
>