OIDC OP v/s SAML2NameID

Cantor, Scott cantor.2 at osu.edu
Thu Sep 8 20:03:40 UTC 2022


>    I realize that xsi:type=“SAML2NameID” is deprecated and would be happy
> to replace the definition with something else that produces the same result.

Nothing will (outside of maybe an ugly script), it's a dead feature. Apps don't want to handle complex attribute values. If they do, they could never function with anything but a Shibboleth IdP and perhaps SimpleSAML, and that's hardly a desirable state for anybody, so they should just get things fixed and start consuming normal types of persistent ID forms.

Anyway, it's not getting replaced since the whole point is the feature itself, not how it's implemented. Whether we remove it is TBD, but I would certainly like to.

>    However, I don’t see why adding in the
> shibboleth.oidc.ClientSecretValueResolvers bean breaks an otherwise
> working configuration (e.g. commenting out the bean allow the attribute
> resolver to load).

Me either. I can't imagine any scenario where that could be connected. I'd strongly suspect there's something else involved masking the real problem. But given that it's an NPE, on some level there's got to be a bug.

As far as I know, there really aren't any code touchpoints between what's inside the resolver and the OP code except for those special activation conditions that are suggested for use with generating "sub".

-- Scott




More information about the users mailing list