> But as TFA mentions right off the bat, that's atypical.
So atypical that it borders on inconceivable. There's almost always an external party in there.
But if you somehow end up totally internal sure, try the back-channel binding. You get to toss SOAP messages around, and it might work. Of course now one of the invariants you built around no longer holds ("SAML works without having to let the IdP talk to the SPs" oh my sweet summer child...)
Just don't try SLO over the front channel, or else you'll have the joyous UX of a user clicking "log out" and all of a sudden they're bouncing logout messages back and forth between the IdP and two dozen internal applications. Hope the ninth app in line isn't down for maintenance or your <LogoutResponse> never makes it back to the IdP and the user wonders why they're staring at a server error page for an app they haven't used in hours and why half their environment is logged in and the other half isn't...
So atypical that it borders on inconceivable. There's almost always an external party in there.
But if you somehow end up totally internal sure, try the back-channel binding. You get to toss SOAP messages around, and it might work. Of course now one of the invariants you built around no longer holds ("SAML works without having to let the IdP talk to the SPs" oh my sweet summer child...)
Just don't try SLO over the front channel, or else you'll have the joyous UX of a user clicking "log out" and all of a sudden they're bouncing logout messages back and forth between the IdP and two dozen internal applications. Hope the ninth app in line isn't down for maintenance or your <LogoutResponse> never makes it back to the IdP and the user wonders why they're staring at a server error page for an app they haven't used in hours and why half their environment is logged in and the other half isn't...