5-16 Understanding Security for Oracle WebLogic Server
4.
The Web service calls the SAML Credential Mapping provider, which generates an appropriate SAML assertion.
5.
One of the following occurs. Note that this list represents the most likely scenarios and that other scenarios are possible.
■
The Web service sends an unsigned assertion and uses a non-SSL transport in a SOAP message to the destination. With this type of assertion, there is no
proof material in the SOAP message so the assertion cannot be trusted nor can it be assumed that the assertion came from a trusted party.
■
The Web service uses the SSL protocol to send an unsigned assertion in a SOAP message to the destination. With this type of assertion, the client
certificate is used to establish trust.
■
The Web service signs the assertion and sends it using a non-SSL transport in a SOAP message to the destination. With this type of assertion, the signature
provides the proof material for trust but it cant be assumed that the connection was not compromised. However, modification of a signed
assertion can be detected because any change will break the signature
■
The Web service signs the assertion and uses the SSL protocol to send the signed assertion in a SOAP message to the destination. With this type of
assertion, trust is established either through the signature or the client certificate.
6.
The SAML Identity Assertion provider consumes and validates the assertion and determines if the assertion is to be trusted.
7.
If the assertion is to be trusted, the SAML Identity Assertion provider creates a Subject containing user principals and possibly group principals and returns the
Subject with principals to the Web service.
8.
The Web service returns the response to the user.
5.3.2 Holder-of-Key Assertion
In the Holder-of-Key assertion, the Web service client depends on the Web service server to ensure that the user is to be trusted.
The Holder-of-Key assertions are used in the following manner:
1.
A user authenticates to a Web service client through some undetermined mechanism. The Web service client can be local or remote and may or may not be a
WebLogic server instance.
2.
The Web service client trusts the user, generates a SAML assertion containing the certificate of the user, and signs the SAML assertion with its private key. The Web
service client returns the SAML assertion to the user.
3.
The user inserts the SAML assertion information into a wsse:Security header in a SOAP message. The message body is signed with the private key of the user.
4.
The user invokes a WebLogic Web service.
5.
The Web service sends the SOAP message to the Web service server in this case, a WebLogic Server instance. The Web service server makes a trust decision based
on whether or not it trusts the SAML assertion and the SOAP message.
6.
The Web services server receives the assertion and passes it to the SAML Identity Asserter. The SAML Identity Asserter verifies the assertion signature and verifies
trust in the certificate used for that signature.
WebLogic Security Service Architecture 5-17
If this succeeds, the Web service server can assume that the key in the holder-of-key assertion does in fact belong to the Subject of the assertion. Web
services can then use that key to verify the signature that signs the SOAP message, which establishes that the SOAP message was generatedsent by the holder of the
key. It is up to the Web service server to verify trust in the X.509 certificate itself.
The Web service server returns a Subject with principals for the SAML assertion to the Web service client.
7.
The Web service client returns the response to the user. Optionally, the SSL protocol can be used with this assertion. If the SSL protocol is used,
the client certificate can also be used as proof material.
5.4 The Security Service Provider Interfaces SSPIs
