attribute resolving issue
Lohr, Donald A - lohrda
lohrda at jmu.edu
Fri Feb 17 21:35:50 UTC 2023
One instance is for employees and we are using their HR# to populate
*uid* and the other instance is for students and we are using their SIS#
to populate *uid*.
One instance is for employees and we are using their HR# to populate
*employeeID* and the other instance is for students and we are using
their SIS# to populate *studentID*.
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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:type="xsd:string">8946</saml2:AttributeValue>
>> <saml2:AttributeValue
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:type="xsd:string">101639347</saml2:AttributeValue>
>> <saml2:AttributeValue
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> 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
>
--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230217/7a7ca1b5/attachment.htm>
More information about the users
mailing list