Resolving attributes from a SAML proxy

[Wessel, Keith]

All,

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 services.properties 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:

id=adfsProxyAuthnMethod
transcoder=SAML2StringTranscoder
saml2.name=http://schemas.microsoft.com/claims/authnmethodsreferences

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"
        relyingParties="%{idp.saml-proxy.entityID}"
        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/adfsProxyAuthnMethod.properties)

And

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}http://schemas.microsoft.com/claims/authnmethodsreferences-< > 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
icrosoft.com/claims/authnmethodsreferences'

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"
                p:attributeContextLookupStrategy-ref="shibboleth.ChildLookup.PreRequestedAttributeContext"
                p:useUnfilteredAttributes="true">
                <property name="attributeValueMap">
                    <map>
                        <entry key="adfsProxyAuthnMethod">
                            <list>
                                <value>http://schemas.microsoft.com/claims/multipleauthn</value<http://schemas.microsoft.com/claims/multipleauthn%3c/value>>
                            </list>
                        </entry>
                    </map>
                </property>
            </bean>

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?

Thanks,
Keith

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




On Oct 6, 2021, at 3:36 PM, Wessel, Keith <kwessel at illinois.edu<mailto:kwessel at illinois.edu>> 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?

Keith

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: <http://shibboleth.net/pipermail/users/attachments/20211008/8f190360/attachment.htm>