SAML in general uses the browser to keep a common "session" between two sites.
This is done as follows:
- One site A.org starts a session A in the browser.
- It sees there is no SAML authentication, and posts to the SAML identity provider. Via the browser with automatic form submission (JavaScript),
- The identity provider sees there is no SSO session, does a login form
- After login form it posts back to the site A.org with an SSO session ID (so to say).
- If the same browser now on Site B.net starts a new session B, it again posts to the SAML identity provider, which now has an existing SSO session ID to return.
The form posted to the SAML identity provider is automatically posted back, and the returned authentification is also an automatically posted form.A kinde of cross-site scripting.
A SAML servlet filter could accept this result and put a UserPrinciepal in the application request.
The configuration is not too difficult. You need your own unique key pair for your "server",
All-in-all it was rather time consuming. It helped to set up ones own Identity Provider too. Apache Shiro, a security solution outside the Java EE server world, did not have a SAML solution at the time I worked on SAML.
If you got a demo IdP and SP running, it should not be too difficult to short-cut everything. Maybe using FireFox with the TamperData add-on to inspect the communication.