Skip to Content.
Sympa Menu

shibboleth-dev - RE: CryptoHandleGenerator

Subject: Shibboleth Developers

List archive

RE: CryptoHandleGenerator


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: "'Shibboleth Development'" <>
  • Subject: RE: CryptoHandleGenerator
  • Date: Wed, 16 Mar 2005 19:35:15 -0500
  • Organization: The Ohio State University

> 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




Archive powered by MHonArc 2.6.16.

Top of Page