I re-opened the issue.
This is a very tricky use case. Keep in mind that logout is an industry challenge--it's not specific to any vendor. In reality, logout is an asynchronous process: a person initiates a logout (somewhere), and then this requires coordination with a number of websites and IDP's. However, the user does not want to wait a long time for a logout confirmation. This is why the problem is asynchronous, you need to return quickly, and ideally some messages would be sent (or re-sent if necessary), until the logout is achieved. There is a new IETF effort called "Security Events" which is attempting to put together such a solution. However, don't hold your breath for websites and IDP's to support it. No one knows when and if that will happen.
In the meantime, logout scenarios need to be considered , and a solution designed, on a case by case basis. You need to take into consideration all the protocols. It's common that a person logs into a SAML IDP, navigates to some SAML protected websites, and then goes to sites protected by OpenID Connect. Of course, OpenID Connect and SAML have different logout mechanisms. Also keep in mind that websites have their own application session, and perhaps their own requirements for logout (which may or may not align with federated identity standards). This can lead to a toxic combination of logout requirements.
In version 3.1.6.
```
html += "<script>" +
"window.onload=function() {" +
"window.location='" + postLogoutUrl + "'" +
"}" +
"</script>";
}
html += "<title>Gluu Generated logout page</title>" +
"</head>" +
"<body>" +
"Logout requests sent.<br/>" +
iframes +
"</body>" +
"</html>";
```
When processing this code, oxAuth loads grant and find all the clients which assosciated with it.
Passport-js is connected to oxAuth via an Authentication interception script. In this script, there is a `logout` method which is invoked at logout, and could be used to make back-channel calls.
If that is not going to work, there is a custom workarounds. You can develop a custom landing page to handle the various logouts--both to the Gluu Server, and then to the respective backend IDPs. But this is outside the services provided on this support forum. Your developers, or a professional services provider would implement this solution, and ask any questions about challenges uncovered along the way here.
In version 4.1, we are considering adding another custom interception script for "Person Logout", in which we would offer the ability to overwrite the default logout behaviour described above, and to enable the generation of a page according to this business logic.
Hope that helps. We can keep the issue open, but let us know what is your specific question from here.