attribute resolving issue

Fri Feb 17 23:25:57 UTC 2023

Sorry, that should have been AttributeEncoder, not AttributeDefinition.
AttributeEncoder ... name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid"
saml2:Attribute FriendlyName="uid" Name="urn:oid:1.2.840.113556.1.4.35"

On Fri, 2023-02-17 at 16:35 -0500, Lohr, Donald A - lohrda wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

One instance is for employees and we are using their HR# to populateuid and the other instance is for students and we are using their SIS# to populateuid.

One instance is for employees and we are using their HR# to populateemployeeID and the other instance is for students and we are using their SIS# to populatestudentID.

Since our LDAP service did not have a scheme default for employeeID and studentID attributes, we created then in LDAP starting with jmu in their names and I never create custom attributes in LDAP in upper or mixed case.

Unless I'm not understanding your question, the definition and the assertion content are as we expect.

thx

On 2/17/23 4:15 PM, Ray Bon wrote:
CAUTION:This email originated from outside of JMU. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Donald,

Your attribute names differ between AttributeDefinition and AttributeStatement for the uid friendlyName.
Is this a typo or the actual values?

Ray

On Fri, 2023-02-17 at 14:49 -0500, Lohr, Donald A - lohrda via users wrote:
Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

Back in Oct 2022 we added the config for two new SP instances (same vendor), one instance for employees and the other for students.  When I began config for these two SPs, we had two previously defined attributes in our attribute-resolver.xml file they wanted to use:

    <AttributeDefinition xsi:type="Simple" id="employeeID">
        <InputDataConnector ref="ldap" attributeNames="jmuemployeeid"/>
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.2.840.113556.1.4.35" friendlyName="employeeID" />
    </AttributeDefinition>

    <AttributeDefinition xsi:type="Simple" id="studentID">
        <InputDataConnector ref="ldap" attributeNames="jmustudentid"/>
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.2.840.113556.1.4.35" friendlyName="studentID" />
    </AttributeDefinition>

They were going to use the two existing attributes to populate on a user's AcmeLMS profile the username field.

Additionally they wanted to populate a unique id field, so we had to define two more attributes in the our attribute-resolver.xml file. I'm sure what I did was not the best practice.

    <AttributeDefinition xsi:type="Simple" id="hrNumberUID">
        <InputDataConnector ref="ldap" attributeNames="jmuemployeeid"/>
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
    </AttributeDefinition>

    <AttributeDefinition xsi:type="Simple" id="saNumberUID">
        <InputDataConnector ref="ldap" attributeNames="jmustudentid"/>
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
    </AttributeDefinition>

Once things were config'd and SSO was working (verified by the vendor), in my documentation I always grab aacli output for historical purposes.  Each instance reported:

EMPLOYEE:
<saml2:AttributeStatement>
        <saml2:Attribute FriendlyName="employeeID" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">8946</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute FriendlyName="uid" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">8946</saml2:AttributeValue>
        </saml2:Attribute>

NOTE: Notice both a employeeID and uid are in this output.

STUDENT:
        <saml2:Attribute FriendlyName="uid" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">101639347</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute FriendlyName="studentID" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">101639347</saml2:AttributeValue>
        </saml2:Attribute>

NOTE: Notice both a employeeID and uid are in this output.

Today the vendor reported that we were sending two values each in the employeeID and studentID items in the SAML message. I verified that by running the aacli command against each instance:

EMPLOYEE:
        <saml2:Attribute FriendlyName="employeeID" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">8946</saml2:AttributeValue>
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">8946</saml2:AttributeValue>
        </saml2:Attribute>

STUDENT:
        <saml2:Attribute FriendlyName="studentID" Name="urn:oid:1.2.840.113556.1.4.35" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">101639347</saml2:AttributeValue>
            <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBGckk8Isw$> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<https://urldefense.com/v3/__http://www.w3.org/2001/XMLSchema-instance__;!!N6YHze6lT7thMl0!L3DRD5vXXQJLyP-4R3h1_cHx3IfV3JKkP7RbFLgJ07NpCMqJSpVGigiETe3GrxwbdIBG-1W5XfE$> xsi:type="xsd:string">101639347</saml2:AttributeValue>
        </saml2:Attribute>

Additionally, the uid attribute was not included.

The following config for these two instances in our attribute-filter.xml file are:

<AttributeFilterPolicy id="acmeLMSemp">
        <PolicyRequirementRule xsi:type="Requester" value="urn:vector-solutions:id:sp:jmu-va-vectorlmsedu-com-saml" />
        <AttributeRule attributeID="employeeID"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="givenName"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="sn"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="mail"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="hrNumberUID"><PermitValueRule xsi:type="ANY"/></AttributeRule>
</AttributeFilterPolicy>

<AttributeFilterPolicy id="acmeLMSstu">
        <PolicyRequirementRule xsi:type="Requester" value="urn:vector-solutions:id:sp:jmustudents-va-vectorlmsedu-com-saml" />
        <AttributeRule attributeID="saNumberUID"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="studentID"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="givenName"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="sn"><PermitValueRule xsi:type="ANY"/></AttributeRule>
        <AttributeRule attributeID="jmustudentemail"><PermitValueRule xsi:type="ANY"/></AttributeRule>
</AttributeFilterPolicy>

My un-educated assumption is that since employeeID & hrNumberUID both have the same urn:oid value and since studentID & saNumberUID also both have the same urn:oid value, that's causing the issue of the uid attribute being dropped and the employeeID (or studentID) containing the same attribute value twice.

If I define the attribute-resolver.xml file with a urn:oid value that better aligns with a userid type attribue (urn:oid:0.9.2342.19200300.100.1.1) then aacli output returns back to both employeeID & studentID having a single value and uid now displaying in the SAML message.

Asking the vendor if they approximately knew when this issue started, they reported "started happening over a month ago".  One of the events that happened during mid Janurary was the upgrade of our Shibboleth IdP from 4.1.7 to 4.2.1.

I'm being asked to ask if there was anything in the upgrade we installed that could have resulted in this reported issue? I've looked at the release notes for the versions (4.2.1, 4.2.0) and nothing is jumping out at my ignorant eyes.

Thanks,
Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230217/2e16f498/attachment.htm>