Zoom Integration with Shibboleth IdP v3 and non-signed logout request
Cantor, Scott
cantor.2 at osu.edu
Thu Apr 16 18:54:11 EDT 2015
On 4/16/15, 4:37 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
>
>It appears that I will want to understand how to turn off the
>requirement that the <LogoutRequest> be signed (per replying party if
>possible). If you can outline what is necessary I would be grateful.
I should open by saying, file an issue and I can probably create a property that toggles this particular requirement on or off, and if we do that like imminently, you can probably best do this by just copying what we commit and it will just keep working at the next minor upgrade because it will become part of the supplied files.
But for explanation's sake, the rules that run are in something called the "inbound interceptor" subflow and the ID of that flow is defaulted in all the profile config beans in relying-party-system.xml, so that's the pointer to what the built in behavior is.
<bean id="SAML2.Logout"
class="net.shibboleth.idp.saml.saml2.profile.config.SingleLogoutProfileConfiguration"
p:artifactConfiguration-ref="shibboleth.DefaultArtifactConfiguration"
p:inboundInterceptorFlows="security-policy/saml2-slo"
p:encryptionOptional="%{idp.encryption.optional:false}" />
That flow definition is in system/flows/saml/saml2/slo-security-flow.xml
Obviously that flow can be changed in a brute force way by editing files in system/ but changing them so they'll generally work across upgrades involves copying it into a user flow and then overriding that flow ID in your profile config beans:
<bean parent="SAML2.Logout"
p:inboundInterceptorFlows="my-security-policy/saml2-slo" />
You would create a copy of the flow in conf/flows/my-security-policy/saml2-slo/saml2-slo-flow.xml and adjust it by commenting out or deleting specific rules (in this case CheckMandatoryAuthentication).
I suspect you would need to copy over some beans files to make it work, since the imports in the system flow are relative paths and are pointing into that tree. It might work to just alter the import line in the flow file to point at ../../../../system/flows/saml/security-beans.xml (or whatever it actually is).
Obviously this is considered a "rare" use case to modify these flows, so it's not particularly simple to do. Adding a property to adjust things is usually simple and seems to be a good way of adding features that people can implement on an interim basis before the feature shows up in an upgrade.
-- Scott
More information about the users
mailing list