NativeSP - exporting full SAML assertion to protected application?

[Stephen Chan]

On Wed, Feb 22, 2012 at 4:46 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> And I guess there's PAM support for SASL or GSS?
>

   MyProxy has SASL support, so no need to jump through an extra PAM layer.

http://grid.ncsa.illinois.edu/myproxy/sasl.html

   Interestingly, you can opt to jump through the SASL layer to get
PAM support...

> That is delegation. It cannot be done properly without extending the SAML
> Browser SSO assertion to support round tripping to the IdP to acquire
> additional tokens, and then one has to apply the whole sequence of steps
> to the application protocol. When we worked on the problem, we attempted
> to address the delegation flow itself, and then the use of HTTP as an
> application protocol by way of ECP.

    There are a couple of ways to implement delegation. Using ECP was one
route that our local Shib expert suggested, but there wasn't anything
conveniently
"off the shelf" that would work with ECP and our MyProxy service.
    The CILogin derived approach has been built and tested, but it seems to
introduce a slew of additional moving parts:
http://www.sciencegatewaysecurity.org/oauth-for-myproxy

    The ShibuPortal approach you have documented seems to be Java centric
(our main application is Python based). It looks like we could write up our own
delegation implementation using the IdP delegation plugin and ECP to
get SAML tokens
and then use either a PAM or SASL plugin on the MyProxy server to authenticate
check the tokens and return a myproxy cert.
    But we were trying to avoid rolling Yet Another Shib Delegation
solution when it looked
like there were solutions laying around already.

> If you have a middle tier, then by definition that tier has to be able to
> do its thing without extra authentication from the user, since the user's
> not there. If by SSO you mean "without the Myproxy being root and trusted
> to impersonate anybody", that's what we call delegation.

   Yes, the problem is that few of the existing delegation solutions
plug cleanly
into our environment. I had been hoping that the oauth for myproxy solution
would be a relatively "drop in" solution. However it introduces an oauth service
that either prompts the user for username/password (thus defeating web SSO)
or else is trusted to impersonate anybody to the MyProxy server (which is
worrisome).

>> Is there a way
>>to pass some token from the Web SSO through ECP? On the face of it,
>>using the SAML assertion directly would seem to be roughly equivalent,
>>but skipping a connection via ECP from the myproxy server back to the
>>IdP.
>
> You cannot skip that step without violating the SAML standard or extending
> the initial assertion with foreknowledge that it's to be used as a
> delegation token to access a particular service.

   The solution that this crudesaml module seems to enable is to
use a custom relying-party profile for our SP that adds an attribute for
delegation and an appropriately short lifetime to mitigate against
replay attacks. The SAML assertion with the special delegation attribute
would be our SAML token. We take the SAML assertion and pass it along to the
MyProxy server for authentication, where is gets validated by the
crudesaml module
as a legit SAML assertion containing the delegation attribute.

   We don't need a general solution right now (and we can wait for the
fully baked, and
carefully reviewed general solution to come out later). At this point
it would only be
a single SP and a single service (myproxy). If we have a roll our own delegation
solution, I would rather that it be lightweight and specific to our
actual situation.

    For the record, I'm not particularly invested in this solution, so
if you have scathing criticisms, I'll
get over it (I'd get over it immediately if the scathing criticisms
also offered a path to a solution).
It looks like you've thought through and built a solution for Java
portlets, but that doesn't
really help our application.

> Or you can hack something up and ignore the standards like most people do
> of course. For some reason, people will pass around SAML assertions
> without regard for their content or the required security proofs, but
> presumably would not do the same thing with Kerberos tickets. Or maybe I'm
> naïve and they pass those around freely too.

    I'm sure there some example of a tgt embedded in a cookie flying
around in cleartext on the net...but would you really want to know
about it? ;-)

    Steve