Shibboleth Developers

[Tom Scavo <>]

On 10/14/05, Brent Putman 
<>
 wrote:
>
> Well, I wasn't really thinking of modifying MyProxy per se, I was
> thinking of some kind of new client (e.g. "gridshib-proxy-init"),

It's already been dubbed 'shib-proxy-init' by Jim Basney :-)

> We pretty much concluded that there just wasn't any way to
> do it with SAML 1.1, it just doesn't have anything like AuthnRequest.
> We have also considered a non-SAML-based protocol that would do
> something like I believe you or Von suggested earlier in this thread,
> i.e. form up an HTTP request to the existing IdP SSO by using HTTP Basic
> Auth, or POST to an HTML form with known URL and field names, or
> something, and have it processed by mod_whatever in Apache, or some
> existing Java container-managed security mechanism.  This would work,
> obviously, but it seems awfully kludgy to me.

Of course.  If you believe a kludgy one-off solution will happen more
quickly than a SAML 2.0 approach, there is a real trade-off here.

> We sort of came to the conclusion that if you're going to invent a
> custom proprietary protocol, it may as well be one that is based on a
> future standard (SAML 2.0) so that when OpenSAML 2.x and Shib 2.x catch
> up, we're most of the way there already.  So we're not really waiting on
> SAML 2.0 support in OpenSAML per se, we're just borrowing the bits of
> SAML 2.0 we need, since we know that's what things are going to look
> like in the future.

Well that's a reasonable approach.  I'll bet there are folks on our
team that would buy that argument.  (Not all, but some :)

> Seems a reasonable trade-off to actually make
> something work in the short-term.

There's the rub.  I'm not convinced the SAML 2.0 approach can be
realized so quickly but I may be wrong.

> >... do CryptoShibHandle on the MyProxy Server
> >side.  At this point, that seems like the best way.
>
> Doesn't this assume that the IdP and MyProxy share the same symmetric
> key used to encrypt the handle?

Yes.

> I guess that's fine if the MyProxy
> Server lives at the IdP organization, and each IdP runs its own MyProxy
> server, but it precludes the idea of a VO operating the CA and MyProxy
> for use by clients from multiple IdP's.  Just want to make sure I
> understand.

Yes, you're absolutely right.  Current thinking is that MyProxy and
Shib are in the same administrative domain.  Your point is well taken,
however.  Maybe we should rethink that.

> So the purpose of using CryptoShibHandle would just be to conceal a
> non-transient handle (EPPN, X509 Subject DN, etc) from the target Grid
> service(s), thereby providing anonymity?

Not quite.  Anonymity is not a big issue for us (yet) although
CryptoShibHandle provides that.  No, the main advantage is that
MyProxy is decoupled from the Shib IdP (except for the shared secret),
which precludes the need to invent a new protocol.

> I'm with you, it does boil down to the NameIdentifier. Seems to me you
> only have a few choices:
>
> 1) Have Shib generate the handle.  This means you have to authenticate
> to Shib first in order to get the handle to put in the cert (or
> otherwise communicate to the SP).  Requires new protocol (e.g.
> AuthnRequest).
>
> 2) Have MyProxy (or whatever) generate the handle.  This means at handle
> creation time you have to communicate the handle back to the IdP for
> later use by the AA.  Requires new protocol (e.g. SAML 2.0
> NameIdentifier mapping/management stuff).
>
> 3) Use a handle already known to both MyProxy and IdP (e.g. EPPN).  Does
> not require a new protocol, but (perhaps) precludes pseudo-anonymity
> (unless encrypted).

2 and 3 are really two variations on a theme.  There is another
approach, however---yours.  An independent 3rd party that acts as an
intermediary, whether it be an STS or Name Mapping Protocol Service
(NMPS).  The latter is less work and solves the problem at hand.  The
former is needed for the emerging grid portal use case, however.

Maybe we should solve this problem as a series of graded steps. 
First, do the kludgy one-off thing to get something out the door. 
Second, a SAML2-compliant NMPS.  Third, an STS.  Maybe by the time we
get around to the latter, there will be some standards we can
leverage. ;-)

> We are going to have to solve exactly the same issue for the second
> phase of our Condor-Shibboleth integration project, so call me when you
> have an answer... :-)

Right :-) I talked to both Chad and Arnie about this at GGF.  We're
definitely on board with you guys.

> I personally think #1 makes the most sense for
> the general non-browser case, but it does involve what is today at least
> a "custom" protocol (using our magic ball to peer into the future...).

Agreed.  Thanks, Brent.

Cheers,
Tom