Corrected Issue with upgrade 3.3 to 4.1 no attributes released

Powell, Keith A PowellKeithA at uams.edu
Fri Nov 12 19:11:15 UTC 2021


    > But my speculation from the fact that the audit log is including attributes in the output but the assertion doesn't is that you've borked the attribute encoding process in > some way. It looks as though there are no AttributeEncoders configured in the old legacy way nor are the default transcoding rules used with the Registry service introduced in 4.0 being used. The attributes are there but never get encoded to SAML syntax.

    > An upgrade done in place could not cause that unless there were no encoders present to start with. A new install could cause that if all the internal attribute IDs used by one's resolver file were not ones that the IdP defaults to recognizing in its registry of rules.

    Well this precisely where I believe the issue is. After upgrading to 4.0, the IDP would not startup without tons of error and warnings around the attribute-resolver.xml file and I had to rebuild it from scratch to clear up any warnings and present attributes that were visible to the attribute release consent form. The documentation really doesn't provide end-to-end how to encode these. If I left off the encoded parts of the 3.3 attribute-resolver.xml configurations back into the 4.0 attribute-resolver.xml configurations, I got nothing but errors or warnings. The example file provided in the documentation really doesn't provide a good example of a more complete configuration to show how that should look:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_wiki_spaces_IDP4_pages_1265631549_AttributeResolverConfiguration&d=DwICAg&c=27AKQ-AFTMvLXtgZ7shZqsfSXu-Fwzpqk4BoASshREk&r=ALmgjisEdZjuYwvQf78ccYCV50oA0rSf5tQ7KUj2gVI&m=jJj0rkTBqD1yHFMbz03I4tbCxOBJI-XqEvsypjXmU5Q&s=6rVu4rwsFU_17dbA02y5TRXEfS2jYSNiqNzZHFzjwbk&e= 

    Also, in reading the above, it states this: " In older versions of the IdP, the resolver service was also responsible for attaching so-called AttributeEncoders to the objects that were subsequently used to produce the protocol-specific "encoding" of the data into SAML and other formats."

    That led me to believe that I was not responsible for encoding the attributes in the attribute-resolver.xml file and this was be handles elsewhere.

    For example.
    My 3.3 eduPersonPrincipalName configuration looks like this:
         <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver"
             sourceAttributeID="mail">

            <resolver:Dependency ref="adLDAP" />

            <resolver:AttributeEncoder xsi:type="SAML1String" encodeType="false"
                name="urn:mace:dir:attribute-def:eduPersonPrincipalName"  />

            <resolver:AttributeEncoder xsi:type="SAML2String" encodeType="false"
                name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />

            </resolver:AttributeDefinition>

    My 4.0 and 4.1.4 eduPersonPrinicpalName looks like this since this not translated through the upgrade process and this was the best I could figure out from the documentation:

        <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Simple">
    	<InputDataConnector ref="adLDAP" attributeNames="mail" />
       </AttributeDefinition>

    So I suspect the Attribute Encoder for SAML2String or something related to the OID need to defined somewhere, I just don't have an example nor can I find clear documentation from my perspective that would indicate anything else.

    The other question I have regarding that is how do you encode attribute being returned from LDAP? That is something else I had to manually fix because the upgrade did not translate my settings and put defaults that were irrelevant to my setup. These attributes are coming through the LDAP setting rather than an attribute definition:
    exportAttributes="%{idp.attribute.resolver.LDAP.exportAttributes}". I suspect that an attribute definition needs to be setup to encode these with the same oids or encoders, but again, I could not find good example nor clear documentation from my perspective.

    Any help in understanding this and how to properly fix these two scenarios would be greatly appreciated.

    Thanks,
    Keith




    ----------------------------------------------------------------------
    Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
    -- 
    For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_wiki_x_ZYEpPw&d=DwICAg&c=27AKQ-AFTMvLXtgZ7shZqsfSXu-Fwzpqk4BoASshREk&r=ALmgjisEdZjuYwvQf78ccYCV50oA0rSf5tQ7KUj2gVI&m=jJj0rkTBqD1yHFMbz03I4tbCxOBJI-XqEvsypjXmU5Q&s=U7S2oyXxN2k300SYHn-ugFO6pgckYzSic6jopZDBQGw&e= 
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



More information about the users mailing list