Can the SP forward artifact consumption to another service ?

[Cantor, Scott]

On 11/12/14, 11:03 AM, "Matthieu Huin" <matthieu.huin at enovance.com> wrote:
>
>I've been looking into artifacts (section 3.6 of 
>http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) 
>and would like to know if shibboleth SP could support passing the 
>artifact, once obtained, to another service, through some form of 
>callback.

Not without writing code, no. Also, that would create a requirement for a 
secure interprocess communication mechanism, not to mention one people 
would be willing to actually deploy and manage. If you're not aware (I 
suspect you are), that's a non-trivial amount of work (and there's 
literally nothing people actually agree to use to solve that, which is why 
most callbacks are blatantly insecure).

And really, you're not using the SP at all there because its whole purpose 
is to be that SAML machinery, so I don't know why you'd bother with it. 
What you'd be looking to do is build your own, I guess.

>Keystone recently got support for federation through SAML (as a SP, 
>behind mod-shib), and CLI operations are possible through ECP, but 
>getting the right federated AuthN workflow through
>horizon is tricky. So using artifacts and having horizon pass them to 
>keystone could maybe solve this; or is there something else that could be 
>done ?

You can't just offload that one step. You're also offloading everything 
else the SP does because that's all done on the basis of processing the 
SAML assertion. The trust model, use of metadata, the attribute mapping 
and filtering, etc. All of that happens in the code you're suggesting be 
removed. It's not the SP at that point, it's just a shim. Building a shim 
is easy, but you'd have to reimplement the SP and then connect them safely.

-- Scott