<div dir="ltr"><div dir="ltr"><div></div><div>Thanks for the reply Scott. I was already running 4.0.1. I was able to use some of the previous posts I mentioned, along with your guidance above, to implement a responderIdLookupStrategy that works. It was far simpler than it looked and I feel stupid for even asking now. <br></div><div><br></div><div>Of course I agree with your assessment that this is a defect; unfortunately, Microsoft seems to disagree. I generally find that 95% of the time I tell an SP they've done something incorrectly, they tell me I don't know what I'm talking about. I send them copies of standards, they refer me to other "industry standard" implementations that are incorrect. Anyway, I'm preaching to the choir. <br></div><div><br></div><div>Thanks again</div><div>-Matt</div><div><br></div><div>P.S. In case anyone else finds this thread later and wants to know what I did: </div><div><br></div><div>-- in relying-party.xml:</div><div> <util:map id="microsoftOnlineRespondersIdMap"><br> <entry key="default" value="%{idp.entityID}" /><br> <entry key="<a href="http://domain2.com">domain2.com</a>" value="%{idp.entityID}/<a href="http://domain2.com">domain2.com</a>" /><br> </util:map><br><br> <bean id="microsoftOnlineResponderIdScript" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript" p:customObject-ref="customObjectsMicrosoftOnlineResponderIdScript"><br> <constructor-arg><br> <value><br> <![CDATA[<br> //Get the requested domain<br> requestedResponder = custom.httpServletRequest.getParameter('domain');<br> if (custom.microsoftOnlineRespondersIdMap.containsKey(requestedResponder)){<br> responderId = custom.microsoftOnlineRespondersIdMap.get(requestedResponder);<br> } else {<br> responderId = custom.get('microsoftOnlineRespondersIdMap').get('default');<br> }<br> responderId;<br> ]]><br> </value><br> </constructor-arg><br> </bean><br></div><div><br></div><div> <bean parent="RelyingPartyByName" c:relyingPartyIds="urn:federation:MicrosoftOnline"><br> <property name="responderIdLookupStrategy"><br> <ref bean="microsoftOnlineResponderIdScript" /><br> </property><br> </bean><br></div><div><br></div><div>-- In Powershell:</div><div>$dom = "<a href="http://domain2.com">domain2.com</a>”<br>$brand = "<a href="http://domain.com">domain.com</a>"<br>$url = "<a href="https://idp.domain.com/idp/profile/SAML2/POST/SSO?domain=domain2.com">https://idp.domain.com/idp/profile/SAML2/POST/SSO?domain=domain2.com</a>"<br>$ecpUrl = "<a href="https://idp.domain.com/idp/profile/SAML2/SOAP/ECP?domain=domain2.com">https://idp.domain.com/idp/profile/SAML2/SOAP/ECP?domain=domain2.com</a>"<br>$uri = "<a href="https://idp.domain.com/idp/shibboleth/domain2.com">https://idp.domain.com/idp/shibboleth/domain2.com</a>"<br>$logouturl = "<a href="https://www.domain.com/">https://www.domain.com/</a>"<br>$cert = "<cert-data>"<br><br>Set-MsolDomainAuthentication –DomainName $dom -FederationBrandName $brand -Authentication Federated -PassiveLogOnUri $url -SigningCertificate $cert -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logouturl -PreferredAuthenticationProtocol SAMLP <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 1:52 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/27/20, 1:13 PM, "users on behalf of Matt Brennan" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:brennanma@gmail.com" target="_blank">brennanma@gmail.com</a>> wrote:<br>
<br>
> TL;DR: Is there a guide somewhere on how to do this properly? <br>
<br>
Well, step one is filing a bug, because this is ridiculous.<br>
<br>
That aside, the way to do it is:<br>
<br>
1. Upgrade, because it's not supported In V3.<br>
2. A responderIdLookupStrategy, in some form. I can't give you a script because I have no idea on what basis the value would be derived, but the script should NOT need to do a ton of work. It certainly does not need to resolve attributes or anything like that.<br>
3. Configuring the context-check interceptor to signal back the event "UpdateSecurityParameters" when this needs to happen. This will cause the system to re-derive various settings, including the entityID, to update the outgoing message.<br>
<br>
#3 is not (well) documented, it was implemented [1] at SWITCH's request as a supported way to get all the internals to update without having to mess around with them and break abstraction. It's mentioned very briefly in [2]. I'll try and put a mention of it in the context-check topic.<br>
<br>
-- Scott<br>
<br>
[1] <a href="https://issues.shibboleth.net/jira/browse/IDP-1238" rel="noreferrer" target="_blank">https://issues.shibboleth.net/jira/browse/IDP-1238</a><br>
[2] <a href="https://wiki.shibboleth.net/confluence/display/IDP4/ProfileHandling" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP4/ProfileHandling</a><br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div></div>