Shibboleth Developers

["Scott Cantor" <>]

>   Increasingly with Grid services we're seeing the need to couple  
> them with existing authentication services, in essence creating *-to- 
> X509 translators. For example, we now have an online CA (MyProxy)  
> that offers both PAM and SASL authentication mechanisms, allowing a  
> deployment to use an existing LDAP, Kerberos (either password or  
> TGT), Radius, or other (those are just the ones we've tested)  
> authentication service to generate X509 credentials for their users.

But does the credential belong to the server or the client?

>   There are two ways to solve this that we see:
> 
>   1) allow for algorithmic mappings from DNs to local site names.  
> Then a stateless name mapper plugin could be written to convert the  
> X509 DN in the SAML attribute query to a locally meaningful name for  
> querying the local attribute DB.

If I'm issuing the certs via this proxy, why is there a name mapping issue?
I can insert a name into the cert that I can properly interpret. If I'm not
issuing them, then I don't see where any use of SAML comes into play here.

>   2) Ship a SAML authentication assertion along with the X509  
> certificate. What this would entail is instead of contacting the site  
> authentication service directly, we contact a SAML authentication  
> service (aka the Shib SSO), with both validates the authentication  
> and provides a SAML authn assertion which can then be later 
> presented back to the AA.

Who is getting the assertion and over what protocol? Is it holder-of-key or
bearer? Who's presenting it later to whom? And if you have it, why use the
cert?  A holder of key assertion essentially is an XML cert. It seems like
either/or to me, not both. This is kind of old ground, and led to the
conclusion that since the existing services were already handling certs,
that was the obvious thing to keep doing.

> The benefit to #2 is now we're completely out of the internals of  
> Shibboleth. We don't care how the site generates the SAML authn  
> assertion, what's in it, or how the AA parses it, we just carry it  
> along for the ride (just like a web broswer and SP).

That's something we do because browsers are dumb, not because it's a good
idea. Strong assertions should have real confirmation requirements. And why
couldn't you just stick something in the cert itself to use as a query key?

Basically, if the IdP is issuing the cert and the authn assertion, it could
just as easily issue a cert with the right kind of name in it. If it's not
issuing both, I don't see what ties things together. Maybe I need a more
explicit explanation of the steps.

-- Scott