Closed ghost closed 7 years ago
You are sending a string in the eduPersonTargetedID (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) attribute. That is not allowed; per the specification eduPersonTargetedID is an XML construct, being a NameID. Your IdP needs to change what it sends for the eduPersonTargetedID.
@thijskh: Is there anything we can do on our SP side? And for the IdP, how do they change this setting (and specifically for our SP)? Thanks.
We can login when we tested disable NameID lookup in "private function parseAttributeValue($attribute, $attributeName)" (tested with this particular IdP). Is it purely a string vs XML issue involved?
Should I expect the IdP to send the attribute in this way instead?
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue>
<saml:NameID NameQualifier="IdP-Entity-ID"
SPNameQualifier="SP-Entity-ID">
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
</saml:NameID>
</saml:AttributeValue>
</saml:Attribute>
Yes, that is how it should look. Not sure what your IdP config looks like, but if you're running 1.8 that might be a good idea to upgrade anyway.
I have no control over the IdP which belongs to an institution. It is one of the IdPs we get from a federation metadata stream. We spent 1.5 hours on the phone this friday afternoon, trying to solve this. If the guy has a boss (which I think he has), I would not expect any futher help. However, we would like to know how how to prevent it from happening again in the future.
Is below what the IdP need to send?
'attributeencodings' => array('urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw',),
Is below a better approach? Will this also move the NameID from Subject to AttributeValue as RAW XML?
'authproc' => array(
// Generate the persistent NameID.
2 => array(
'class' => 'saml:PersistentNameID',
'attribute' => 'eduPersonPrincipalName',
),
// Add the persistent to the eduPersonTargetedID attribute
60 => array(
'class' => 'saml:PersistentNameID2TargetedID',
'attribute' => 'eduPersonTargetedID', // The default
'nameId' => TRUE, // The default
),
// Use OID attribute names.
90 => array(
'class' => 'core:AttributeMap',
'name2oid',
),
),
// The URN attribute NameFormat for OID attributes.
'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
'attributeencodings' => array(
'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID with oid NameFormat is a raw XML value */
),
Is it possible for the IdP choose to send the RAW XML specifically to our SP? Or, can our SP to convert the "received message" to RAW XML instead? Should we have any doubt that the IdP is the only place to configure sending this RAW XML attribute? Also I can't see 'NameQualifier' from this specific IdP, could it cause a problem for NameID generation, for instance a persistent one. And at last, is version 1.8 capable and compatible with the current version and protocols?
@thijskh: Many thanks for your guidance.
I believe the approach with PersistentNameID2TargetedID sketched above should work. However, that authproc filter has only been added in SSP 1.11. Not sure how they generate the attribute now. Core of the problem is indeed that according to specification the attribute value must be an XML nameID.
It might be difficult to fix this in the SP because the error already happens at parsing the assertion.
Some possible alternative approaches:
@thijskh: Many thanks for your help. Will follow your advice.
However, I don't know if I am still mixing up our problem with this one: eduPersonTargetedId with SSP 1.14.6
That was fixed in 1.14.7 (2016) already.
Confirming "IdP stops releasing eduPersonTargetedID at all (to your SP or in general)" is a working solution.
Many thanks @thijskh
Running SimpleSAMLphp 1.15 (RC1/2) as SP, against older version SimpleSAMLphp 1.8 as IdP. Gets the following "Received message" which fails at "SAML2\Assertion::parseAttributeValue".
https://github.com/simplesamlphp/saml2/blob/v3.0.2/src/SAML2/Assertion.php#L291
https://github.com/simplesamlphp/saml2/blob/v3.0.2/src/SAML2/Assertion.php#L529