Shibboleth Developers

[Von Welch <>]

Scott,

 This is complicated enough it might take a phone call, but let me  
take a run at it...

 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.

 So that's all and good if we're just thinking about authentication,  
but if I preach to the choir, that's just the start. Imagine for a  
moment that a site is running Shibboleth - we can probably use PAM or  
SAS to leverage their existing authentication service (just like the  
SSO does), but if we want to query for attributes, we're still left  
with the message name translation issue (from X509 DN to what ever  
name the site uses locally).

 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.

 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.

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

 What we need to make this work though is a standard (network)  
interface to the SSO/authentication assertion service.

Von


On Sep 30, 2005, at 1:31 PM, Tom Scavo wrote:

> On 9/30/05, Scott Cantor 
> <>
>  wrote:
>
> > It seems like it suffers from the same basic problem as all the  
> > other use
> > cases I've seen for the query do...why would you do it? If you've  
> > already
> > authenticated to the grid service, why does it need a SAML assertion?
>
> Well, our use case requires the value of AuthenticationMethod so the
> first thought was to obtain an authentication assertion.  I can see
> now, however, that may be fruitless since MyProxy will have to
> communicate AuthenticationMethod when it registers the DN, so it may
> as well just store AuthenticationMethod in the cert itself.
>
>
> > About the only reason I could think of would be to do something  
> > with the
> > AuthnContext feature, so it would be a SAML 2.0 thing,
>
> We're stuck on SAML 1.1 for the foreseeable future, so
> AuthenticationMethod is the best we can hope for.
>
>
> > and it would still be
> > something you could ship as a set of attributes anyway.
>
> Yes, I suppose so.  Either that or put it in the cert.
>
>
> > There is a lot of downside to SAML separating AuthnStatement from
> > AttributeStatement. In practice, I think it doesn't work real  
> > well, and
> > that's one reason AuthnQuery always seemed silly to me.
>
> You're right, I guess.  It doesn't make much sense to process an
> authentication assertion for a single attribute value.  If the
> authentication assertion had some other use, that might be a different
> story.
>
> Thanks,
> Tom