<div dir="ltr">Hi Scott<br><br>Thanks.<br><br>Yes, the documentation and discussion of SLO is interesting. Quite a topic. We did not incorporate it in this version of our IdP or I would be better versed in it. And we use the CAS plug-in.<br><br>Is there a way to use a generic SAML2 url by using /profile/SAML2/Redirect/SLO to satisfy their assertion requirement? I know I am grasping at straws here.<br><br>For example <a href="https://ucsantabarbara.gsc-cloud.com/genetec/auth/profile/SAML2/Redirect/SLO">https://ucsantabarbara.gsc-cloud.com/genetec/auth/profile/SAML2/Redirect/SLO</a><br><br>This is what exists in their SP metadata which must match what is configured in the application as OIDC and SAML2 logout URI's.<br><br><SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<a href="https://ucsantabarbara.gsc-cloud.com/genetec/auth/logout/">https://ucsantabarbara.gsc-cloud.com/genetec/auth/logout/</a>" /><br><SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<a href="https://ucsantabarbara.gsc-cloud.com/MobileOpenId/logout/">https://ucsantabarbara.gsc-cloud.com/MobileOpenId/logout/</a>" /><br><SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<a href="https://ucsantabarbara.gsc-cloud.com/SecurityCenterOpenId/logout/">https://ucsantabarbara.gsc-cloud.com/SecurityCenterOpenId/logout/</a>" /><br><br>OIDC and SAML2 logout URI's<br><a href="https://ucsantabarbara.gsc-cloud.com/genetec/auth/logout/">https://ucsantabarbara.gsc-cloud.com/genetec/auth/logout/</a><br><a href="https://ucsantabarbara.gsc-cloud.com/MobileOpenId/logout/">https://ucsantabarbara.gsc-cloud.com/MobileOpenId/logout/</a><br><a href="https://ucsantabarbara.gsc-cloud.com/SecurityCenterOpenId/logout/">https://ucsantabarbara.gsc-cloud.com/SecurityCenterOpenId/logout/</a><br><br>I suggested removing the SLO uri's altogether but that is not allowed. And YES this is ass backwards, supposedly this is what is stopping the redirection to our LOGIN page.<div><br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Scott Gilbert</div><div>IAM/Cloud System Administrator</div><div>Enterprise Technology Services</div><div>University of California Santa Barbara</div><div><br></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 8, 2022 at 4:07 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">I'm not sure what you're asking? Vendor's gonna vendor. You can fight them, or not, I guess, obviously there's no fundamental reason why SSO and SLO have to be intertwined. Some fights are more worth it than others.<br>
<br>
The IdP certainly supports logout endpoints and they're enabled by default, as well as documented. No, it's certainly not trivial to really try and do logout for real, but with a vendor, "your metadata" should be confined to whatever you share with them anyway, you needn't view it as a global deployment decision.<br>
<br>
But if you're asking "is it reasonable to require an SLO endpoint just to allow for SSO?", no, clearly not.<br>
<br>
-- Scott<br>
<br>
<br>
</blockquote></div>