Resolving attributes from a SAML proxy

[Wessel, Keith]

Looks like this method hits another wall. I tried adding the attribute resolver service bean to my custom map:

<entry key="attributeResolver" value-ref="shibboleth.AttributeResolverService" />

But now, the IdP dies on start-up complaining that it can't instantiate the SAML2NameIDAttributeDefinition bean:

2021-10-08 17:31:06,976 - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:182] - Service 'shibboleth.AttributeResolverService': Initial load failed - [session=] [ip=] net.shibboleth.utilities.java.support.service.ServiceException: Failed to load [file [/opt/shibboleth-idp/conf/attribute-resolver.xml], class path resource [net/shibboleth/idp/conf/attribute-resolver-system.xml]]
        at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:387)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eduPersonTargetedID': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [net.shibboleth.idp.saml.attribute.resolver.impl.SAML2NameIDAttributeDefinition]: Constructor threw exception; nested exception is java.lang.NullPointerException
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowire CapableBeanFactory.java:1316)
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [net.shibboleth.idp.saml.attribute.resolver.impl.SAML2NameIDAttributeDefinition]: Constructor threw exception; nested exception is java.lang.NullPointerException
        at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:225)
Caused by: java.lang.NullPointerException: null
        at org.opensaml.core.xml.config.XMLObjectProviderRegistrySupport.getBuilderFactory(XMLObjectProviderRegistrySupport.java:107)

I'm doing all of this in global.xml if that makes a difference. I assume that the IdP can't initialize some of the attribute definitions at start-up because there's no user to initialize it against. I even tried adding a lazy-init to the bean with my function in it in hopes that it wouldn't try to do anything at start-up with the helper map. No change there. And I tried adding a lazy-init to the helpers map, but of course maps can't have a lazy-init attribute.

So, I'm still stuck on how do I get this authnContextTranslationStrategyEx hook to do attribute resolution?

Thanks,
Keith

-----Original Message-----
From: Wessel, Keith 
Sent: Friday, October 8, 2021 2:22 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Resolving attributes from a SAML proxy

If I debugged this correctly:

         if (input.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext") == null) {
                    logger.debug("Relying party context not found");
                }
                else {
                    logger.debug("Relying party context found");
                }

                if (input.getSubcontext("net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext") == null) {
                    logger.debug("Attribute resolution context not found");
                }
                else {
                    logger.debug("Attribute resolution context found");
                }

...then we're missing the attribute resolution context:

2021-10-08 14:14:13,167 - DEBUG [mfa_claim_to_acr:8] - Relying party context found
2021-10-08 14:14:13,176 - DEBUG [mfa_claim_to_acr:12] - Attribute resolution context not found

Is that debugging code correct?

If so, I should be able to use similar code to do attribute resolution like I'm using in my MFA function to get one, right?

                rpid = input.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext").relyingPartyId;

                resCtx = input.getSubcontext("net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext", true);
                resCtx.setPrincipal(custom["usernameLookup"].apply(input));
                resCtx.setAttributeRecipientID(rpid);
                resCtx.getRequestedIdPAttributeNames().add("adfsProxyAuthnMethod");
                resCtx.resolveAttributes(custom["attributeResolver"]);

Is that what I need to do? Or is there a simpler way?

Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Friday, October 8, 2021 2:03 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Resolving attributes from a SAML proxy

On 10/8/21, 2:59 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    Can you at least tell me if the attribute context and the relying party context should be in the profile request
> context when its assigned to the input passed into my authnContextTranslationStrategyEX function?

They should be if I'm reading the code correctly but only if it actually managed to decode anything, which should be logged.

-- Scott


-- 
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!vCYr6fklBq1K4rLGNst5NfevYrTwD5Y92hPx8jGcYOV-vIevtqpBmWmqYgsyKXT3Ww$ 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net