The TAS3 SSO API's primary aim is supporting SAML 2.0 SSO (and SLO) with attribute and bootstrap passing. Not all COTS SAML 2.0 SP APIs (or IdPs) are capable of this out of the box. Thus being SAML 2.0 compatible is a prerequisite, but additional properties, such as specific functions, session level attribute pool, and bootstrap cache, must be satisfied as well to be TAS3 API compliant. The TAS3 SSO API is likely to support in future (as of 2009) in a transparent way InfoCard specification [CardSpace], and may be able to support other SSO specifications as well.
Some alternatives for supporting SSO:
mod_auth_saml and (Apache) subprocess environment provides a complete solution for SSO layer if using Apache httpd or compatible web server. In such case the SSO is handled without any programming simply by editing httpd.conf (and in some cases zxid.conf). The mod_auth_saml configuration directives are the same as in zxid.org and they are introduced to httpd.conf using ZXIDConf directives.
tas3_sso() API as complete solution. tas3_sso() API implements a state machine that the calling application must crank by making repeated calls (one per HTTP request until SSO completes). This approach has a benefit of isolating the calling application from protocol flow specifics and allows the API to support multiple SSO protocols in a transparent manner.
tas3_sso_servlet.class: Java servlet that can be configured to Tomcat or other servlet container to implement SSO for payload servlets. Internally the SSO servlet calls tas3_simple();
Deprecated Alternative: by steps approach using medium level APIs (deprecated because the logic of the specific SSO protocol flow would be hardwired into the calling application)