Shibboleth Developers

[Brent Putman <>]

Tom Scavo wrote:

> 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.
>
>  
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"), maybe 
a small Java program, that could do this.  It would seem to be not a 
whole lot of code and fairly straightforward, although I realize that's 
not your main issue...



> 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're basically in the same situation with respect to Sentinel, 
including the technical issues and timeframe (a little less time left, 
actually).  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.


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.  Seems a reasonable trade-off to actually make 
something work in the short-term.  But I understand your concerns about 
inventing new things.  Our project is probably a little more 
"proof-of-concept" than yours is.



> 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.
>  


Doesn't this assume that the IdP and MyProxy share the same symmetric 
key used to encrypt the handle?  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.


> 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.
>
>  


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?


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).


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... :-)  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...).



> 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.
>
>  

Yes, agreed!


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

Unfortunately, yes.  :-)


Thanks,
Brent