Shibboleth Developers

[Von Welch <>]

Scott,

 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)?"

 Tom, Jim and I have come up with 2-3 different ways of going about  
it. One, which I think you suggest towards the end of your response,  
is indeed to put one or more extensions into the certificate that  
says (in general terms) "Here is an AA you can talk to and here is  
the subject name to use with that AA".

 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.

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

 Does that help clarify?

Von


On Oct 4, 2005, at 11:51 AM, Scott Cantor wrote:

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