delegation in IDP3

[Cantor, Scott]

On 6/8/16, 11:52 AM, "users on behalf of Hong Ye" <users-bounces at shibboleth.net on behalf of hy93 at cornell.edu> wrote:

>I saw following log entries in IDP 3 log. Does that mean IDP3 have delegation support
>implemented?

Yes, it was ported from the old extension and is in 3.2.

>Is there any documentation of how to configure delegation in IDP and SP?

There has been SP documentation on ECP and the generally unused policy controls around delegation for a long time. There is no IdP documentation. I don't know when, if ever, it will get done, it would be up to Brent.
 
Since there is no real client support for any of that work, it's not a feature anybody uses, and we understand that.

I would suggest you either use OAuth, use mutual authentication by keys and just do impersonation in-line (>>>> OAuth in my opinion), or you would need to be willing to invest significant resources in client-side code to do anything else. For non-federated cases, there's always CAS proxying too.

There's basically a triangle: simple, federated, secure. Pick two.

Using keys to secure the endpoints is not delegation, but I think when all of the trade-offs are considered, it's the best strategy. If OAuth ever decides crypto isn't the devil, then a holder-of-key version of it would be the best choice.

SAML made an assumption that standardizing the token format was going to be an important piece, but it turns out it's not. You just do callbacks on every token handoff to the issuer to validate and parse the token back into the information the service needs, and you don't need a standard token, only the API. That's just naturally a simpler approach, as long as you secure that callback. That's where OAuth gets it wrong; it's something that could be fixed, but only at a cost in complexity. And we're back to the client issue. If nobdody's going to produce client code that does anything better, you're stuck with the LCD.
 
-- Scott