attribute resolving issue
Lohr, Donald A - lohrda
lohrda at jmu.edu
Mon Feb 20 13:16:25 UTC 2023
I understand now.
Let me disclose that I did some wrong copy/paste actions. In my
original email the following two items should have read:
<AttributeDefinition xsi:type="Simple" id="hrNumberUID">
<InputDataConnector ref="ldap" attributeNames="jmuemployeeid"/>
<AttributeEncoder xsi:type="SAML2String"
name="urn:oid:1.2.840.113556.1.4.35" friendlyName="uid" />
</AttributeDefinition>
<AttributeDefinition xsi:type="Simple" id="saNumberUID">
<InputDataConnector ref="ldap" attributeNames="jmustudentid"/>
<AttributeEncoder xsi:type="SAML2String"
name="urn:oid:1.2.840.113556.1.4.35" friendlyName="uid" />
</AttributeDefinition>
...and this is what I change them to:
<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>
Sorry for the mistake.
Thanks,
Don
On 2/17/23 6:25 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.
> ------------------------------------------------------------------------
> 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
>> 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/20230220/cf6ff77e/attachment.htm>
More information about the users
mailing list