Development help - Is exchangeInfo.xml the right config file to use to store a new feature for per-endpoint SAML format changes?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Development help - Is exchangeInfo.xml the right config file to use to store a new feature for per-endpoint SAML format changes?

jonb_at_zen
This post was updated on .
I am implementing a change similar to https://github.com/msweaver/CONNECT/tree/OneAttributeStatement . The gist of this change is to send all (most) SAML attributes in one AttributeStatement as opposed to one AttributeStatement per Attribute.

I have successfully made my change against master and tested it with my team. It works for our own use cases as a global change.

To complete this change and make it good enough to submit a patch or pull request I also want to be able to configure this behavior on a per-endpoint basis. For example Endpoint A might prefer the current format while Endpoint B would REQUIRE the new format.

My change will default to the current one-attribute-per-attribute-statement behavior present in master. The configuration would be an override.

I reviewed the following config files to determine what might be the best fit:
 - exchangeInfo.xml - this is definitely a per-endpoint configuration, however adding custom attributes would require changes to the exchanges schema. That seems excessive for what I want to accomplish
 - gateway.properties - this seems more flexible, I could add a custom property that is a list of OIDs that would cause a different SAML behavior when communicating with that endpoint
 - a new properties file - very flexible but this then requires documentation for this custom properties file

Is there some other location I should use to configure this option?

I have not yet determined what marker would be best for triggering this behavior. Something present in the CallbackProperties object passed to gov.hhs.fha.nhinc.callback.opensaml.HOKSAMLAssertionBuilder#createAttributeStatements such as an organization OID seems best. I am investigating that next.

Thank you for the advice. I appreciate the time to help me learn the standard for CONNECT so I can do this job correctly and submit a good patch the first time!
Reply | Threaded
Open this post in threaded view
|

Re: Development help - Is exchangeInfo.xml the right config file to use to store a new feature for per-endpoint SAML format changes?

jonb_at_zen
I dug out some additional notes. The issue I am resolving or re-implementing is also documented at https://connectopensource.atlassian.net/browse/CONN-770 .

In addition the current code in master has a comment that the one-attribute-per-statement might not be needed. https://github.com/CONNECT-Solution/CONNECT/blob/CONNECT_integration/Product/Production/Common/CONNECTCoreLib/src/main/java/gov/hhs/fha/nhinc/callback/opensaml/HOKSAMLAssertionBuilder.java

The new work I'm introducing is to make this configurable per endpoint. One of my teammates is encountering systems in the wild which have issue with one attribute per statement.