Shibboleth Developers

[Tom Scavo <>]

Brent, I appreciate your response.

On 10/14/05, Brent Putman 
<>
 wrote:
>
> Well, yes, I understand your requirement for transport-level security
> (via Globus GSI, grid certificicates), but I don't see how this
> precludes that.  The way that I understand it, the GT-4 interactions in
> this proposal would all still be transport-level security, meaning that
> by the time the GridShib client user submits the request to the Grid
> service they have a cert, and are using the standard Globus GSI
> transport layer mechanisms.

Correct.

> It is essentially like the existing MyProxy
> model: something MyProxy-like is the security token service (STS), is
> SAML and WS-* aware, and able to issue certs based on SAML assertions as
> the credential type.

Yes, the relatively easy part is to make MyProxy Server a consumer of
SAML authN assertions.

> I wasn't actually suggesting the entire flow in Chad's model, (such as
> the ability of a Grid service to renew a proxy cert via a request to the
> STS), just the initial mechanism of conversion of a credential issued by
> an IdP into a Grid certificate by means of a SAML-aware STS (e.g.
> enhanced MyProxy).

Yes, I'm with you on that part.

> Only the GridShib client would need to be SAML and
> WS-* aware - is that a problem?

If you're referring to the MyProxy Client, no, we are not allowed to
modify the Client.  Instead, you could imagine a kind of gateway
between the MyProxy Client and the MyProxy Server, but the problem is
not in the consumption of the assertion, it is the production of the
assertion that has me concerned.

Before I go on, let me say that our target platform is Shib 1.3 and
OpenSAML 1.1.  If it can't be built with these technologies, then it
is outside the scope of GridShib (which has little more than a year of
funding remaining).  So we can't wait for OpenSAML 2.0 (although I see
Chad is busy working on it :).

So my problem is the following.  How does a non-browser client
(MyProxy Client) with only a username/password get an authN assertion
from a Shib 1.3 IdP.  It is okay to extend the IdP with custom
protocol handlers (for existing protocols) and plugins, but we should
avoid new protocols and schemas, if possible.

We've tried reducing the problem to its bare essentials, that is,
really all we need is a NameIdentifier since the full assertion is
overkill at this point, but even that leads to a new protocol unless
we follow LionShare and do CryptoShibHandle on the MyProxy Server
side.  At this point, that seems like the best way.

I really don't want to commit the CryptoShibHandle code to Globus CVS,
however.  I know about shib-util.jar but that's not readily accessible
to MyProxy Server unless we make some simplifying architectural
assumptions.  So the config is going to get messy and I'd rather avoid
that, if possible.

Also, there's this nagging issue about local principal name.  I don't
think MyProxy generally has access to that so it's not clear exactly
what should be encrypted into the handle.

All in all, I would prefer that Shib supply the handle (you know, the
"eat your own dog food" mentality) but that requires a protocol, which
again we would like to avoid.

So an elegant solution to the problem has yet to emerge.  We'll just
keep searching, I guess. :-)

> Am I missing something?

The devil is in the details, yes? :-)

Cheers,
Tom