NativeSP - exporting full SAML assertion to protected application?

[Cantor, Scott]

>  Sorry, I read the docs and mentally rolled up your work with Unicon's Java client.

It's part of the original project, but the point is that it's purely a case study/example at this point.

> question is how much work is involved in coding up the client SAML
> delegation portion?

The client doesn't know anything about delegation per se, it's just an HTTP client that knows how to implement the ECP profile, which is mostly a lot of SAML-ignorant shuffling of bits of XML into and out of some SOAP envelopes.

The difference between a vanilla ECP client and a delegation-aware client is that we replaced the usual "basic-auth" type thing with the authentication step to the IdP with attaching the SAML SSO assertion to the SOAP envelope. We profiled things to avoid any complex signature requirements for the base use case, and just did it with mutual TLS, so it's still largely not a case of needing to write code that knows anything about SAML assertions.

I thought somewhere in the wiki was a walkthrough of the basic requirements of an ECP client, I'd have to go poking around a bit. I believe Scott K has implemented at least a prototype of one recently.

But, that's for ECP alone, which is HTTP apps. Doing something like SASL is a different thing, you need a mechanism implementation for that. The ECP part is about the same, but the additional work is obviously non-trivial. NCSA is prototyping that at the moment, but that's C. I don't know that I'm aware of any viable ways to do SASL/GSS stuff in anything but Java or C/C++. Could be wrong.

Or, you have the scenario of uncharted territory and have to define a new application substrate to plug into. In that case, what we (the project) would say is, if you want relatively out of the box support in the IdP, you can do ECP, or screen scrape bindings designed for browsers. The former we'll help as much as we can with, the latter we'll beg you never to tell us about.

> Validating the delegated SAML token seems to be simply a matter of
> looking for the "delegation" condition within the token, and it looks
> like we could re-use the crudesaml package for that.

You have to validate the token in the usual way. The delegation condition is really just a signal that if you care about the difference, you can check it. If you don't, it's implicitly valid. The rest of the token is what limits the basic security risks, the usual bearer stuff.

As far as the code there, it depends on the application, again. If it's SASL, no it's not that simple. You need a mech implementation for the server side.

>    Its clear to me now - and I also understand what it is like to be
> asked to come up with a solution, and
> then not have anyone pick up on it.

I don't mind that so much; it's more that the presumption seemed to be that it had to support every environment out of the box to be a solution, and that's not realistic for a non-browser anything.

-- Scott