Shibboleth Developers

["Von Welch" <>]

My take on this is that there are two conceptual classes of X509
NameMappers:

 -Those that map DNs which can be algorithmically mapped to the the
local Principal name. These DNs were most probably issued by the IdP
itself.

 -Those that map DNs which cannot be algorithmically mapped to the
local Principal name. These were most probably issued by a CA not
associated with the IdP. In this case you need some sort of
administratively configured mapping.

The Grid will fall into the second category for the forseeable
future. We will develop a mapp that acts as described for that
category.

As pointed out we will run into problems if we run into a IdP that
needs to do both types of mappings, as despite the fact the names are
the same format, they really are different types of names. In this
case, we'll dig in then and write a wrapper as Scott suggests.

Von

Tom Scavo writes (19:49 March 16, 2005):
 > 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
 > > 
 > >