Shibboleth Developers

["Scott Cantor" <>]

>   I'm not suggesting we get away from X509 as our underlying security  
> mechanism. What I'm getting at is "how can the grid service (sort of  
> an SP), having authenticated the user via X509, present a identifier  
> to the AA which the AA understands without the AA having to maintain  
> a bunch of mappings from DNs to local site principal names (which is  
> what we're doing right now in gridshib)?"

I guess I'm inclined to think the answer is for the IdP "collection of
services" to issue the certificate in the first place. I don't really
understand the current model because not doing that introduces a lot of
serious questions about the identity mapping process, speaking as somebody
who runs our IdP. I don't see where I could get those mappings or why I
would trust them.

Failing that, I guess I'd reverse the relationship and instead have the CA
insert an identifier usable by the IdP. In either case, the mapping is
handled by the CA, essentially, which strikes me as better because it's the
entity issuing the authentication credential.

>   Now the online CA could just put in whatever username that it used  
> to authenticated the user certainly. What I was exploring with my  
> question is could one leverage the Shib's SSO capability to issue  
> transitive identifiers (Handles) to support (or at least not  
> preclude) pseudonymity. In order to do this, we'd need a programmatic  
> way (i.e. non-browser based interface) to talk to the SSO.

But where does the certificate fit in? If you use SAML, then the result is a
SAML assertion, not a certificate. As Bob said, I probably need to see the
sequence of flows.

>   In further conversation, we actually think you could do this today  
> if the SSO is protected by a basic auth mechanism - in this case, one  
> could probably form a http request with username and password that  
> would return a SAML assertion (base64 encoded and wrapped in some  
> html I understand).

Yes, but that XML is a short-lived bearer assertion that is intended for use
by a browser. What you want seems to connect to a certificate somewhere, or
maybe I should say I think it probably should.

This needs to be a new profile and approached as such. That's why I tend to
react negatively to people saying they want to "use Shib SSO for X". This is
a new SAML profile. Whether existing code gets used or not is for a
subsequent conversation, I think, once something formal is at least sketched
out.

To put it another way, scraping HTML is not worth doing in my mind. You
could do a SOAP based interface to the IdP in a day, if you knew what it was
that you wanted it to return. In SAML 2.0, there's an obvious protocol to
use, but even now something can be hacked up, assuming something like
WS-Trust might not even be a better answer for it.

-- Scott