WebLogic Security Service Architecture 5-15
9.
Since the request is still unauthorized, the Servlet container calls the servlet authentication filters. The Negotiate servlet authentication filter handles the
Authorization request header and calls the WebLogic Security Framework. The framework passes the token to the Negotiate Identity Assertion provider.
10.
The Negotiate Identity Assertion provider uses the GSS context to get the name of the initiating Principal. This name is mapped to a username and passed back to
the WebLogic Security Framework via a Callback handler.
The WebLogic Security Framework also determines to which groups the user belongs.
11.
The authentication is complete and the GET request is processed.
5.3 SAML Token Profile Support in WebLogic Web Services
The WebLogic Web services and the WebLogic Security Framework have been enhanced to support the generation, consumption, and validation of SAML 1.1 and 2.0
assertions. When using SAML assertions, a web service passes a SAML assertion and the accompanying proof material to the WebLogic Security Framework.If the SAML
assertion is valid and trusted, the framework returns an authenticated Subject with a trusted principal back to the web service. WebLogic Web services and the WebLogic
Security Framework support the following SAML assertions:
■
Sender-Vouches - The asserting party different from the subject vouches for the verification of the subject. The receiver must have a trust relationship with the
asserting party.
■
Holder-of-Key - The purpose of SAML token with holder-of-key subject confirmation is to allow the subject to use an X.509 certificate that may not be
trusted by the receiver to protect the integrity of the request messages.
Conceptually, the asserting party inserts an X.509 public certificate or other key info into a SAML assertion. More correctly, the asserting party binds a key to a
subject. In order to protect this embedded certificate, the SAML assertion itself must be signed by the asserting entity. For WebLogic Server, the Web service client
signs the SAML assertion with its private key. That is, the signature on the assertion is the signature of the SAML authority, and is not based on the certificate
contained in, or identified by, the assertion.
■
Bearer - The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the
SubjectConfirmationData element of the assertion.
The following sections describe how the processing of these assertions work.
5.3.1 Sender-Vouches Assertions
All the Sender-Vouches assertions are basically the same, the difference is in how trust is established meaning whether or not SSL is used for transport and whether or not
the SAML assertion and the message bodies are signed.
The Sender-Vouches assertions are used in the following manner:
1.
A user invokes a WebLogic Web service.
2.
The Web service requests a SAML assertion from the user.
3.
The user generates a SAML assertion and returns it to the Web service.
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
