SLODemo

To demonstrate the features we have prepared a demo application. The main purpose of the demo is to test the UI and various error conditions.

Preparing

 * Metadata (unsigned)
 * IdP: Based on Adam's Git repository

Authentication
There are 100 demo users from, all users have the password 'demo'.

The IdP uses the UsernamePassword Login Handler. IdP logout is not possible with container-based authentication (like HTTP / X.509 / Kerberos).

How this demo works
The SLO Demo runs in a separate machine from all the SPs and IdP. So it has no information if the login is succeeded or not, it just hopes, everything goes as expected.

Below is a very brief description of the logout demo.

Selecting SPs
At first the user selects the SPs he/she wants to log in. The order of the login is currently sequential (not sure if it makes any difference).

Redirecting to SPs

 * 1) all SP sessions are initiated by using  s to the SPs SessionInitiator by specifying only the IdP entityID ( https://sandbox.slotest.aai.niif.hu/idp/shibboleth ).
 * 2) * the simpleSAMLphp login URL is somewhat similar but not the same
 * 3) the SP initiates the session (the first one gets the user logged into the IdP)
 * 4) the SP redirects to the homeURL
 * 5) homeURL redirects back to the redirection point of the demo interface (by some trivial PHP script)
 * 6) the demo interface starts over with the next SP or displays summary page

Summary page
The (supposedly) logged in SPs are displayed along with their logout urls. Logout opens up in a new window.

Logging out
User clicks on one of the logout URLs.

Start over
On page refresh you can start it over. If you are not asked for password by the IdP, it means that your IdP session was not cleared properly, therefore the logout is failed.

How to get your SP involved

 * 1) Configure the SP as you wish
 * 2) * Don't forget to set  or  , as described in the  SLO documentation
 * 3) Configure the target application (or the page which is served on homeURL) to redirect to.
 * 4) Send SP details to aai _at_ niif _dot_ hu
 * 5) * Metadata
 * 6) * SessionInitiator URL
 * 7) * Optionally:
 * 8) ** Front-channel logout initiator (if there's any)
 * 9) ** Back-channel logout initiator (if there's any)
 * 10) ** SP software & version
 * 11) ** Session handler (attribute viewer) URL
 * 12) ** Short description of what to test
 * 13) ** A funny name, of course ;)
 * 14) Configure your SP to trust slotest metadata (this will contain your SP metadata as well).
 * 15) Please inform us when your test SP is no longer functioning

Setting up a back-channel only LogoutInitiator
See this Jira entry for background. If you have a pre-2.2.1 SP, you should use:

SAML2
Single Logout profile is for SAML2 only. Therefore SP6 (Neanderthalensis) will always fail. Note that SP7 (Ancient Greek) actually speaks SAML2 although it initiates SSO with Shibboleth protocol. Therefore you cannot initiate SLO from SP7 but you can participate in SLO.

SP5 (Old Slowhand) will always fail unless the Logout request is initiated by it.

Front-channel, back-channel
The IdP can fallback to back-channel, if the logout is front-channel and the SP software does support only back-channel bindings. Not the other way, because front-channel bindings need the information held in browser cookies. Therefore front-channel SLO will work with SP4 (Backdoor) if initiated by some other SP's, but SP4 can only initiate back-channel SLO (which is not supported by many of the SP's above.)

Misc

 * Publish shibd and IdP logs on a web page (real-time?)
 * Add IPv6 addresses to the vhosts
 * Add OpenSSO test SP