NativeSP - exporting full SAML assertion to protected application?

[Stephen Chan]

On Thu, Feb 23, 2012 at 8:05 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> Well, there's exactly one defined way of expressing it in SAML because we took the time to lay it out and write
> the documents, reusing the pieces of the standard that were designed to be used for this use case. That's not an
> indictment of others' methods, I'm just trying to be precise in my terminology so that it's clear what I mean by it.

   Point taken.

> No, it's not. It's HTTP centric from the stand-point of the code we worked on for applications to use. But the
> actual client implementation is not part of our solution. All we did was spec it out, and implement the SP and IdP
> parts. The rest is application specific. If you do Java, Unicon worked on some Java code for HTTP client calls
> using it.
>
> If you do something else, then something else is required. Here at OSU, for example, our mobile developer
> worked on a verson in the Javascript-based mobile toolkit they were using.

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

> The "implementation" involved is for the parts that involve the client. In the case of SASL, there's more work,
> of course, because we haven't finished that spec work or produced the server side code. But we're not about
> to code up ten different client side libraries either, no matter what we define and build on the server end. At
> some point, people have to help or we just go on and solve other problems and forget this one.

   I am happy to help advance the community, but like most people, I
have a bunch of other workplace
priorities (including other backlogged Shib/SAML work that might
benefit the community as well). The
question is how much work is involved in coding up the client SAML
delegation portion? All the ECP
client sample code I saw was either for direct authentication, or else
assumed the existence of the Java
delegated SAML authentication libraries. And I confess that I wasn't
really excited about wading through
the source repository of the delegated SAML authentication library.

   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.

>>  But we were trying to avoid rolling Yet Another Shib Delegation
>> solution when it looked like there were solutions laying around already.
>
> All I'm saying is that writing ECP client support in some language is not "rolling yet another solution",
> it's implementing the environmentally specific piece of the solution that was proposed and
> implemented by the project.

   Okay, I see what you are saying.

> Our solution has nothing to do with Java or portlets. If that's clear, I've made the point I'm trying to
> make about that. I understand fully why people don't use it much and would not care to write the
> client code to do so. But having been asked to come up with a correct way to do it with SAML
> alone, that's what we did.

   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. If you have a (relatively) concise
example of how to do the
client side of the delegated SAML authentication, I can evaluate out
whether we want to go down this
path.

   Steve