Resolving attributes from a SAML proxy

Wessel, Keith kwessel at
Fri Oct 8 15:51:37 UTC 2021


This is starting to make sense, and I’m getting enthusiastic about moving my encoders over to the registry soon. But I’m obviously doing something wrong for this attribute that I’m trying to consume from the upstread IdP.

I added the properties to and the attribute registry bean to services.xml. I currently have the line in that bean that loads attributes/default-rules.xml commented out. I decided, since I’m just adding a single attribute, to put it in a file in attributes/custom. I have conf/attribute-registry.xml uncommented in the bean in services.xml, so files in the custom directory seem to be getting loaded.

My custom attribute registry in a properties file looks like this:


I also had encoder=false in there, too, since this attribute is only being decoded from ADFS and used internally, but removing that didn’t solve my problem.

I added a subject data connector to use the attribute:

    <DataConnector id="adfsProxy" xsi:type="Subject"
        exportAttributes="adfsProxyAuthnMethod" />

I can tell that my transcoder rule is getting loaded:

2021-10-08 10:36:24,391 - DEBUG [net.shibboleth.idp.attribute.transcoding.impl.TranscodingRuleLoader:87] - Loading rule from property set in file (/opt/shibboleth-idp/conf/attributes/custom/


2021-10-08 10:36:24,566 - DEBUG [net.shibboleth.idp.attribute.transcoding.impl.AttributeTranscoderRegistryImpl:294] - Attribute mapping: adfsProxyAuthnMethod SAML2:{urn:oasis:names:tc:SAML:2.0:attrname-format:uri}< > via SAML2StringAttributeTranscoder

But when my function runs after the response comes back from ADFS, I get this:

2021-10-08 10:37:04,061 - INFO [net.shibboleth.idp.saml.saml2.profile.impl.Validate
SAMLAuthentication:456] - Profile Action ValidateSAMLAuthentication: No transcoding rule for Attribute 'http://schemas.m'

I’ve got this bean in the helpers custom object that I’m using in my function for the authnContextTranslationStrategyEx hook:

            <bean class="net.shibboleth.idp.profile.logic.SimpleAttributePredicate"
                <property name="attributeValueMap">
                        <entry key="adfsProxyAuthnMethod">

I tried this with both prerequested attributes and without. I wasn’t positive if the attribute resolution ran before the authnContextTranslationStrategyEx hook or not. In addition to wondering why this isn’t mapping my attribute, I’d love to know if prerequesting the attribute is necessary or not.

What am I missing here?


From: users <users-bounces at> On Behalf Of Michael Grady
Sent: Wednesday, October 6, 2021 5:44 PM
To: Shib Users <users at>
Subject: Re: Resolving attributes from a SAML proxy

On Oct 6, 2021, at 3:36 PM, Wessel, Keith <kwessel at<mailto:kwessel at>> wrote:

I’ll give that a shot, Mike. If I put it in the registry, I don’t need the data connector, right? Just the registry entry and the attribute filter?


It depends on why you care about "receiving it". The registry entry is sufficient  (I think) to get rid of a warning message about it in the logs, but if you want to actually base some attribute definition logic on it in the resolver, you would still need the data connector.

Michael A. Grady
IAM Architect, Unicon, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list