Federation TR can't be created in current oxTrust build

[aliaksander-samuseu]

Description

When creating SAML TR of type "Federation" what is created is, effectively, a regular single SP TR with no option to create child TRs from it.

Steps To Reproduce

1. Move to "SAML" > "Trust Relationships" and click "Add Relationship" button
2. Follow next mandatory steps (fill the other fields as desired):

• "Display Name": "Test fed"
• "Entity Type": "Federation"
• "Metadata Location": "File"
• For metadata, use "renater-federation-test-metadata_nosig.xml" file attached here:
  renater-federation-test-metadata_nosig.zip

4. Click "Add" button and wait until validation is completed
5. Repeat step 1, and follow next mandatory steps:
   • "Entity Type": "Single SP"
   • "Metadata Location": "Federation"
   • "Federation Name": "Test fed"

Expected behavior

On step 5 you can select "Test fed" from the dropdown list of federations names and control for selecting specific SP in this federation appears on the page after that.

Actual behavior

On step 5) you can't select "Test fed" from the dropdown list of federations names because it isn't there. When found in list of TRs on "Trust Relationships" page, it can be seen that, though validation is passed, its "Relation type" is "Service Provider" instead of "Federation". Also worth noting that on step 2, when you set "Entity Type" as "Federation", the controls on the page don't change - while in previous versions doing so would remove list of released attributes and "Configure Relying Party" control, as they weren't allowed to be set for Federations

When database entry is checked for the federation TR, it can be seen that, though "gluuEntityType" is set correctly to "Federation/Aggregate", "gluuisfederation" attribute is set to "false". When changed to "true", federation TR starts to function seemingly properly (but additional research may be needed to make sure oxTrust will be using correct data structure for Fed TR after the fix).

[aliaksander-samuseu]

As our QA team has reported today, the issue doesn't happen for InCommon federation. So we could lower its priority a bit I suppose, as I don't think any of our customers deal with any other federation except InCommon.

[nynymike]

Are we sure that this sample renater-federation-test-metadata_nosig.xml metadata is correct? If InCommon works, that maybe means the federation metadata sample is incorrect.

[aliaksander-samuseu]

@nynymike
I've tried to validate it with xmllint (as popular xml validation online tools I was aware of choke on the big file like this one):

xmllint --schema saml-schema-metadata-2.0.xsd --load-trace --noout /mnt/hgfs/exch-mnt/exch/renater-federation-test-metadata.xml 
Loaded URL="saml-schema-metadata-2.0.xsd" ID="(null)"
Loaded URL="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" ID="(null)"
Loaded URL="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd" ID="(null)"
Loaded URL="saml-schema-assertion-2.0.xsd" ID="(null)"
Loaded URL="http://www.w3.org/2001/xml.xsd" ID="(null)"
Loaded URL="/mnt/hgfs/exch-mnt/exch/renater-federation-test-metadata.xml" ID="(null)"
/mnt/hgfs/exch-mnt/exch/renater-federation-test-metadata.xml validates

So it seems that it's valid structurally and adheres to schema.
Renater seems to be quite notorious organization, a French telecom company. That federation of their seems to be similar to InCommon in purpose: https://en.wikipedia.org/wiki/Renater
I doubt they could make a mistake like that, but who knows..

[aliaksander-samuseu]

According to what @shekhar16 shared with me in our last conversation on the matter, it may be due to how validation logic is codded right now in oxTrust. Both InCommon and Renater metadata files are valid, but they use slightly different approach to element's naming (in how they define namespaces, in particular)