Shibboleth Developers

[Tom Scavo <>]

Okay, now I'm following you.  In fact, Von suggested a similar "super
mapping" concept earlier today.

There is no machinery in place that does this, correct?  Is this on your 
radar?

Thanks for persisting,
Tom


On Wed, 16 Mar 2005 19:35:15 -0500, Scott Cantor 
<>
 wrote:
> > It's not.  Grid certs are issued independent of the user's preferred
> > IdP.  A typical DN might be
> >
> > /c=us/o=NCSA/cn=Tom Scavo
> >
> > yet my perferred IdP might be uiuc.edu.
> 
> Ok. Why does that change the situation? UIUC's attribute authority had
> better know how to map that DN to something it can use. That's not a
> different use case. If there's no existing plugin that addresses all the
> possible DNs that UIUC has to deal with...well, yeah, somebody has to write
> one.
> 
> I'm just not seeing why this has to be exposed at the NameMapping level (or
> even how it could be). If you want to decode the DN and then further
> discriminate into different plugins, that should be up to the primary plugin
> handling the DN format.
> 
> > > CryptoHandles *are* ordinary shib handles.
> >
> > That's my point.  How does the AA know whether or not a particular
> > handle needs to be decrypted?
> 
> Umm, ok. Can't you write a plugin that tries to decrypt the string, and if
> that fails, tries to map it into a memory-based store, and...etc. Nothing
> there even comes close to rising to the "I have to invent a new format"
> level.
> 
> > If only one of these elements is allowed, it follows that only one
> > interpretation of a handle is supported by any given AA.
> 
> One interpretation of a SAML format, yes. Handles being one such format.
> Nothing else makes any sense. Within that plugin, you can do anything you
> want to, including call into multiple pre-existing plugins until you get an
> answer back.
> 
> -- Scott
> 
>