shibboleth-dev - Re: CryptoHandleGenerator
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To: Scott Cantor <>
- Cc: Shibboleth Development <>
- Subject: Re: CryptoHandleGenerator
- Date: Tue, 15 Mar 2005 19:34:04 -0500
- 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:references; b=fKSKIk/wNQGs6oiB835/dPINa7A7/DDRdJx7ZFnZRlJ4+S+OtfxLF/XBlseQ4Jp0OykhjWcLqGg8gH6zjTKvAYLfi0yICt8UQgSEKJHj2QAIPG5k45Xi9FoV8ua/Xp83rUAkta26RLwHcSLJ7U1vdmTcubDcpn74163+AvvsqpA=
On Tue, 15 Mar 2005 11:30:15 -0500, Scott Cantor
<>
wrote:
>
> But we don't *want* people making up formats. Format is a SAML concept.
We don't want to create anything new either, but unfortunately, it
looks like we have to. We have to be able to configure a Shibboleth
IdP so that it returns attributes about a subject that it knows
nothing about. Moreover, the custom configuration must be applicable
to an existing deployment (although we are free to require a minimum
version of Shibboleth).
Our first pass at solving the problem is specified in the profile
posted last week. In that profile, an attribute requester pulls
attributes from a suitably configured AA endpoint. The NameIdentifier
in the request is a DN, which the AA knows nothing about. To
compensate, we intend to write a custom implementation of
NameIdentifierMapping that reads a static mapfile on the IdP.
Suppose we had such a plugin called
edu.uiuc.ncsa.shibboleth.plugin.X509SubjectNameNameIdentifierMapping
which extended BaseNameIdentifierMapping. (No, the class in CVS of
the same name will not work for us.) Suppose further we had the
following NameMapping element in origin.xml:
<NameMapping
xmlns="urn:mace:shibboleth:namemapper:1.0"
id="..."
format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"
class="edu.uiuc.ncsa.shibboleth.plugin.X509SubjectNameNameIdentifierMapping"/>
Will this work in Shib 1.3?
Thanks,
Tom
- RE: CryptoHandleGenerator, (continued)
- RE: CryptoHandleGenerator, Scott Cantor, 03/14/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/14/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/14/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/14/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/14/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/16/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/16/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/16/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/16/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/16/2005
- Re: CryptoHandleGenerator, Walter Hoehn, 03/17/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/17/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/17/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/17/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- Re: CryptoHandleGenerator, Tom Scavo, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/15/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/14/2005
- RE: CryptoHandleGenerator, Scott Cantor, 03/14/2005
Archive powered by MHonArc 2.6.16.