[Prev]

4.1 Frontend and Web Services Client Integration Model (Non-normative)

The tasks to be accomplished on the Frontend, in the direct line of call, include

  1. Detect need for login (done by payload servlet)

  2. Perform SSO (SP side)

  3. Perform SSO, IdP side including authenticating user and shipping attributes

  4. Gater additional attributes, if needed ("Attr")

  5. Authorize access to FE (PEP-Rs-In of FE) ("PEP")

  6. Populate session of the payload servlet ("ses")

  7. Redirect user to protected resource he was trying to access on the protected resource.

  8. Application dependent PEP calls PDP if needed. ("PEP")

  9. Call web service, including

    1. Application dependent processing steps ("etc")

    2. Authorize the call (PEP-Rq-Out) ("PEP")

    3. Discover suitable service, performing Trust and Privacy Negotiation (may need interaction at frontend web gui) if needed. ("DIC")

    4. Decorate request with TAS3 specific SOAP headers and sign. ("WSC")

  10. Perform network I/O ("HTTP"). This also includes TLS certificate authentication of the Responder and may include Client-TLS certificate authentication of the Requester.

The SSO integration is expected to be a single module, appearing as a servlet in Java realization and as an authentication module in web server realization, that handles steps 2-7 automatically. The integration is accomplished by configuring the web server without modifying the application except to add the initial detection and redirect (1) and to make use of the attributes that were populated to the session. ((In mod\_auth\_saml realization even step (1) can be accomplished by configuring the web server.)) The TAS3 binary modules for SSO are generically called T3-SSO-*.

The WSC integration is expected to be a single module. It will appear as AXIS2 module in Java realization so that it can be just hooked in by configuration without any modification to the existing web service (the "etc" module illustrates that even other modules than TAS3 can be hooked in without interference ((Non-interference depends on other modules following certain common sense conventions, such as not signing SOAP element and not trying to create SOAP headers that TAS3 creates (e.g. ).))).

The API realization of WSC is a function, tas3_call() (see TAS3 API), that the application can call directly. If this approach is chosen, the entire web services call is handled by the API without any regard to servlet environment's or framework's hooking or modules. This is the most common approach in PHP, Perl, C#, C++, and C worlds.

A possible variant of WSC integration is to call tas3_call_prepare() to obtain the serialized SOAP envelope, then do the I/O part in application dependent way, and pass the response to tas3_response_validate(). Effectively tas3_call() does these steps with a built-in HTTP client performing the I/O part. ((In ZXID realization the HTTP client is libcurl from curl.haxx.se))


Fig-8: API and modules for SSO and web service call.

[Prev | Next]