3 Interoperability with Microsoft WCF/.NET

Configuring Microsoft .NET STS for WS-Trust

Microsoft .NET requires a Security Token Service (STS) to generate a SAML Assertion and supports WS-Security SAML 1.1 Token Profile for WS-Security 1.0. Microsoft .NET favors symmetric bindings for WS-Security and SAML holder-of-key confirmation methods. Oracle WebLogic, on the other hand, performs better using asymmetric bindings and SAML sender-vouches confirmation methods, using X.509 certificates to sign the message and bind the SAML assertion.

On the WebLogic Server side, the inbound policy is WS-Security SAML 1.1 Token Profile for WS-Security 1.0 and the outbound policy ensures that the message is signed by the Web service. This is required because Microsoft .NET expects that an endpoint that is protected using WS-Security will secure the response as well. To support this configuration, the WebLogic Server Security realm needs to be configured to consume and validate SAML Assertions as well as configure Public/Private Key pairs and corresponding trust stores for the message signature operations dictated by the WS-Security policies.

The flow is as follows:

1. The Microsoft .NET client calls the STS.

2. The STS generates a SAML Assertion signed by the STS that contains the name of the user as the Subject.

   The SAML Assertion uses the sender-vouches confirmation method.

3. The SAML Assertion is added to the WS-Security Header, and the message is signed by the invoking service.

4. The message is sent to WebLogic Server where the SAML Assertion is verified along with the message signature.

5. Once the message is processed, the return message is signed by the WebLogic server's identity.

6. The signature is validated by the Microsoft .NET client to ensure that the message has not been tampered and was sent by the WebLogic server.

STS needs to be configured, as follows:

• Use X509RawCertificate format for WSS1.0 instead of SHA1 Thumbprint.

• Use Sender-Vouches confirmation method instead of Holder of Key.

• Sign the assertion with the private key of the issuer, not the encrypted key. Use of the unencrypted asymmetric keys over symmetric encrypted keys improves performance.

• Include an AuthenticationStatement in the SAML Assertion. WebLogic uses this statement to access the user's identity.

• Add a wsu:Id to the saml:Assertion. Otherwise the Microsoft .NET client cannot use it as an IssuedToken with an asymmetric binding.

Configuring WebLogic Web Service

For the WebLogic Web service, use the predefined Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml to enforce SAML 1.1 sender-vouches authentication with WS-Security 1.0 for message binding.

Configuring the Microsoft .NET Client

Configure the Microsoft .NET client as shown below. The SAML token is retrieved from the STS, so the Microsoft .NET client needs to be configured to communicate with STS. Authentication using a token retrieved from an STS is called an IssuedToken.

?xml version="1.0"?>
<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
  >
  <sp:AsymmetricBinding>
    <wsp:Policy>
      <sp:InitiatorToken>
        <wsp:Policy>
          <sp:X509Token
            sp:IncludeToken=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
            <wsp:Policy>
              <sp:WssX509V3Token10/>
            </wsp:Policy>
          </sp:X509Token>
        </wsp:Policy>
      </sp:InitiatorToken>
      <sp:RecipientToken>
        <wsp:Policy>
          <sp:X509Token
            sp:IncludeToken=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
            <wsp:Policy>
              <sp:WssX509V3Token10/>
            </wsp:Policy>
          </sp:X509Token>
        </wsp:Policy>
      </sp:RecipientToken>
      <sp:AlgorithmSuite>
        <wsp:Policy>
          <sp:Basic256/>
        </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
        <wsp:Policy>
          <sp:Lax/>
        </wsp:Policy>
      </sp:Layout>
      <sp:IncludeTimestamp/>
      <sp:ProtectTokens/>
      <sp:OnlySignEntireHeadersAndBody/>
    </wsp:Policy>
  </sp:AsymmetricBinding>
  <sp:SignedSupportingTokens>
    <wsp:Policy>
      <sp:SamlToken 
        sp:IncludeToken=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
        <wsp:Policy>
          <sp:WssSamlV11Token10/>
        </wsp:Policy>
      </sp:SamlToken>
    </wsp:Policy>
  </sp:SignedSupportingTokens>
  <sp:Wss10>
    <wsp:Policy>
      <sp:MustSupportRefKeyIdentifier/>
      <sp:MustSupportRefIssuerSerial/>
    </wsp:Policy>
  </sp:Wss10>
</wsp:Policy>

Using SAML Assertions Referenced from SignedInfo

When the SAML assertion is referenced in the <ds:SignedInfo> element of a <ds:Signature> element in a <wsee:Security> header, Microsoft .NET does not support a SAML assertion that is referenced from <wsse:SecurityTokenReference>. Use of <wsse:SecurityTokenReference> is defined as a best practice in the WS-Security specification, described at http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf.

For compatibility with Microsoft .NET, you must set the WLStub.POLICY_COMPATIBILITY_PREFERENCE flag to WLStub.POLICY_COMPATIBILITY_MSFT flag in Web service client code. When the flag is set, the SAML assertion will be signed with direct reference, rather than using a SecurityTokenReference.

The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-WS Web service client:

. . .
import weblogic.wsee.jaxrpc.WLStub;
. . .
public String test(String hello) throws Exception { 
     . . .
    BindingProvider provider = (BindingProvider)port; 
    Map context = provider.getRequestContext(); 
     . . .
     . . .
    context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT); 
    try { 
       String result = port.getName(hello); 
       System.out.println("MSFT Result was: " + result);
       return result; 
      } catch (Exception e) {             
        throw new RuntimeException (e); 
      } 
}

The following provides an example of how to set the Microsoft .NET compatibility flag for a JAX-RPC Web service client:

. . .
. . .
import weblogic.wsee.jaxrpc.WLStub;
. . .
 
@WebMethod() 
public String callSamlHelloSV_WSS10_MSFT(String input) { 
     try { 
         System.out.println("Calling sayHello(" + input + ") with MSFT Ways");    
         ((Stub)port)._setProperty(WLStub.POLICY_COMPATIBILITY_PREFERENCE,
                       WLStub.POLICY_COMPATIBILITY_MSFT); 
         String result = port.sayHelloSV_WSS10(input); 
         System.out.println("MSFT Result was: " + result); 
         return result; 
     } 
     catch (RemoteException e) { 
         throw new RuntimeException(e); 
     } 
}