Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrupted attribute-filter.xml file under certain (rare) conditions #2369

Open
aliaksander-samuseu opened this issue Aug 25, 2023 · 1 comment
Assignees

Comments

@aliaksander-samuseu
Copy link
Contributor

aliaksander-samuseu commented Aug 25, 2023

Description

When Federation TR's metadata is changed and some SP's metadata is removed from it, if child TR for that Federation exists in Gluu Server's configuration for this SP, that leads to generation of corrupted attribute-filter.xml IDP config file on next update of that child TR. That leads to IDP's inability to load corresponding plugin and attribute are stopped being released for the entire set of TRs (production impaired situation).

Preconditions

  1. Gluu Server with oxTrust 4.5.1sp1 is installed

  2. Functional federation TR for some test federation exists in the system (please note that due to another issue it may not be possible to create such TR in your current build; a way to circumvent this issue is also described); for metadata, use file renater-federation-test-metadata_nosig.zip attached here

  3. A regular test child TR for a singe SP is created, based on the federation from step 3; use SP with "http://aap.novia-systems.fr" entityid for this test

Steps To Reproduce

  1. Move to "SAML" > "Trust Relationships" and open your federation TR's page
  2. Click the "cross" button near the current metadata file to discard it, and upload a new metadata file (the only difference in it is that "http://aap.novia-systems.fr" is removed): renater-federation-test-metadata_nosig_spminus.zip
  3. Click the "Update" buton
  4. Wait until validation is passed
  5. Restart oxTrust: # service identity restart
  6. Move to "SAML" > "Trust Relationships" and open your federation test SP TR's page (the one with entityid of "http://aap.novia-systems.fr" entityid")
  7. Add any attribute to its list of released attributes
  8. Click "Update" button

Expected behavior

When some entity is removed from federation's metadata, at some point (either when the updated fed metadata is processed, or when the affected single SP TR is updated) oxTrust need to disable all child TRs of this particular federation that represent removed entities.

Actual behavior

It seems oxTrust is actually capable of detecting that some entity is no more in federation - as after step 8) entityid is no longer shown on the child SP TR's page. It also removes "gluuentityid" attribute from its entry in the database (which is a single value entry for regular SP). Absence of this attribute produce different issues further down the pipeline when oxTrust generates new configuration for IDP from templates, as entityid is used in many places in it, and usually as a mandatory property which will prevent IDP from starting properly at next restart. So oxTrust needs to learn to disable any TR that is modified like that - and prevent user from enabling TRs with empty "gluuentityid" attribute. Some on-page and log error messages need to be added which clearly explain to user what just happened.

In this particular case, an incomplete definition is pushed into attribute-filter.xml file, looking like this:

 <PolicyRequirementRule xsi:type="Requester" value="" />

Next errors appear in idp-process.log:
During operation:

2023-08-23 16:43:31,786 - 86.57.148.2 - ERROR [net.shibboleth.idp.profile.impl.FilterAttributes:369] - Profile Action FilterAttributes: Error encountered while filtering attributes : Invalid Attribute Filter configuration

During startup:

2023-08-23 16:49:20,234 -  - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:182] - Service 'shibboleth.AttributeFilterService': Initial load failed
net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 13600 in XML document from file [/opt/shibboleth-idp/conf/attribute-filter.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 13600; columnNumber: 64; cvc-minLength-valid: Value '' with length = '0' is not facet-valid with respect to minLength '1' for type 'string'.
        at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:377)
Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 13600 in XML document from file [/opt/shibboleth-idp/conf/attribute-filter.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 13600; columnNumber: 64; cvc-minLength-valid: Value '' with length = '0' is not facet-valid with respect to minLength '1' for type 'string'.
        at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:400)
Caused by: org.xml.sax.SAXParseException: cvc-minLength-valid: Value '' with length = '0' is not facet-valid with respect to minLength '1' for type 'string'.
        at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
@aliaksander-samuseu
Copy link
Contributor Author

aliaksander-samuseu commented Oct 20, 2023

After talking about it with Shekhar in chat, I thought I should better clarify a suggested action to prevent this and similar issues.

  1. oxTrust generates IDP's configuration files from templates in response to certain user actions. For example, if TR is updated, a new config files are generated.
  2. For each such branch of execution in code where new configuration is generated, we need to add an additional check making sure that at least one gluuEntityId attribute is present for the processed TR
  3. If this attribute is empty for some TR, it needs to be put in inactive state before new configuration is generated (so it won't be present in new configuration files).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants