The Web Service client user agent, usually a web browser, attaches a Security token with valid SAML assertions to a SOAP message using WSS: SOAP Message Security by placing assertion elements inside a <wsse:Security> header and sending the request to GWWS as shown in figure below:

SALT will not accept these assertions unless it has successfully validated the integrity of the assertions. The only supported subject confirmation method is currently sender-vouches, in this case SALT must also have TRUST relationship with the attesting entity. When all these requirements are satisfied, the user is granted access to Oracle Tuxedo resources.

An Oracle WebLogic Server instance security can be a SAML issuer. In a WLS environment the typical intermediary is Web Service, but a web browser can also be an intermediary. To establish a TRUST relationship with an attesting entity, GWWS must have access to either a shared secret with attesting entity or its public key.

The SAML issuer is the party creating the SAML assertion, and "intermediary" is the party that attaches the SAML security token to the SOAP message before it is forwarded to GWWS.

The general flow is as follows:

1. Client sends request to WLS.
2. WLS authenticates the client.
3. WLS forwards all necessary login information to the issuer (WLS Web Server).
4. WLS Web Server issuer creates the SAML assertions and returns to WLS.
5. WLS attaches the SAML security token with SAML assertion to the SOAP message and forwards it to GWWS.
6. GWWS returns the reply/fault to WLS.
7. WLS returns the reply/fault to client.

There is a trust relationship between GWWS and WLS/issuer.