Skip to Content.
Sympa Menu

shibboleth-dev - Re: authentication authority

Subject: Shibboleth Developers

List archive

Re: authentication authority


Chronological Thread 
  • From: Tom Scavo <>
  • To: Scott Cantor <>
  • Cc:
  • Subject: Re: authentication authority
  • Date: Sat, 8 Oct 2005 11:33:18 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XdbB/tFMwIssX+R4/UCaR1tqjawRlA6qrSad2f4GvRkGSfxx7OnTFafgbdrAfeT5PjEewbdgcLW2edCPEf3M1xYQ3pLl+0SdaaBtBmkkitvoRVlS4zxJaqj7k4f7NxY9hTsbDW9v9U8EOwGyhzGwuOPP/j1xxLB2XbUrYlw7j/g=

On 10/6/05, Scott Cantor
<>
wrote:
>
> - supporting pseudonymity using transient subject names

We've considered every NameIdentifier under the sun. ShibHandle is
just one possibility but X509SubjectName is still a strong contender.
As long as proxy certs remain transparent (with respect to identity),
X509SubjectName makes a lot of sense.

> - getting a subject name into the certificate that will be understood by the
> SAML authority later

Yes, and as Jim has pointed out, if we're going to issue EECs at the
IdP, we may as well let the IdP choose the DN.

> Those goals are separable, of course.

Yes, but if MyProxy and the IdP are in the same administrative domain,
it may well be one and the same problem.

> One way of doing this that solves both issues is essentially what the
> LionShare CA does, using the self-encrypted handle generator to build an ID
> at the CA that can be decrypted by the SAML authority. Personally, I think
> that's the easiest solution.

Me, too. :)

> Alternatively, this seems more like a use case for the SAML 2
> NameIdentifierMapping protocol, perhaps extended a bit. What you want isn't
> an authentication assertion, you just want a NameID that is valid for a
> particular principal in a particular format. Then you can just put that name
> in the certificate subject.

Yes, there's more support for NameIDs in SAML 2.0, but I don't think
that's relevant for us since we're hoping for an implementation by the
end of the calendar year. Thus SAML 2.0 doesn't seem to be in the
cards for us.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page