4 Deployment and Integration Models (Non-normative)

Fig-7: A deployment architecture for SSO and web service call.

The above diagram illustrates a typical frontend-backend integration situation.

The TAS³ integration can be accomplished in several ways, from least intrusive to the original (legacy) application to more intrusive, but also more granular:

Proxy or mediation box approach

See also [TAS3D71IdMAnAz] Fig-8.2 "Using a Gateway for Legacy Applications". This approach is completely application independent and simply TAS³ wraps existing protocol. Limitation tends to be that TAS³ authorization and obligations have to be applied at granularity of a protocol message rather than the data in it.

Application server filter approach

Either web server module, like mod_auth_saml, or an application server module, like Servlet Filter or AXIS2 Interceptor, is inserted to the processing stack. While software realization is quite different, this is still similar to the mediation box model.

Application class dependent filter approach

Similar to the above filter approach, but the filter has some ability to "drill in" to the application protocol. For example, if all data in the application is represented in uniform format, such as Java Objects, then a generic filter can be supplied that applies authorization and obligations to all data represented in such way.

API approach

This approach relies the application programmer to instrument his application with necessary authorization and other calls. We are simply trying to make his job easier by providing readily available, TAS³ certified, APIs that make the instrumenting job easy.