V3 PrincipalConnector replacement (was: V2 to v3 Config change help)

[Cantor, Scott]

On 1/27/17, 2:45 PM, "users on behalf of James Drews" <users-bounces at shibboleth.net on behalf of james.drews at wisc.edu> wrote:

> That’s fine, I can take this as an opportunity to move forward and away from the Legacy stuff.  But I’m not seeing any
> examples that apply or what is needed to write a new plugin.

The plugin interface the NameID->principal name c14n flow runs is net.shibboleth.idp.saml.nameid.NameIDDecoder and the subtypes of that interface are the only examples available for how to do it, the ported transient ID reverse-mapping code, and the degenerate case where the NameID directly matches a principal or can be derived with a regex. An F4 in Eclipse on the interface will get you all the classes that implement it to see what they do. It's not a complicated interface, it's just a single mapping method:

> In this case, the shared identifier is essentially a second key field in the DB storing the attributes. The plugin written for v2
> did the lookup of the shared identifier and returned the primary key used by the IDP #2 for its attribute query.

I get it, that's obviously not a typical use case and implies writing code, same as before.

PrincipalConnectors remain supported/usable and porting one would not be a huge effort, mostly just some package changes. Or you turn it into a NameIDDecoder that's doing basically the same thing, either way.

> I’ve stared at
> https://wiki.shibboleth.net/confluence/display/IDP30/NameIDConsumptionConfiguration for quite some time and still
> don’t see a way to make this happen.

That's documentation on using what we have now, not on building something new. We have no documentation for that. Of course it will end up configured the same way, but it doesn't exist, so the page can't talk about it. It probably can be fleshed out a little if it's not clear how to tell it about a new plugin.
     
  > I’ve added the name format to the shibboleth.NameTransformFormats in subject-c1n.xml, but haven’t found any
> appropriate examples of shibboleth.NameTransforms. A simple reg-ex (as is the example provided) won’t work. 

That's what that bean is, it is a regex (or list of them I think). I believe that's explicit from the documentation, in the table at the end. "List of regular expression and replacement string pairs to apply to the input..."

Of course, it seems to me that perhaps a simpler solution here is to just do this database query inside the attribute resolver, and pass that second identifier pre-fetched out to an SP as an attribute. Then that SP can do its own query to the other IdP, and that IdP could be using a more direct way to reverse map the user, perhaps using the built-in capabilities.

-- Scott