When your Administration Server, NodeManager and Managed Servers use SSL to communicate with each other you have a decent basic security for your Weblogic domain. (And NO, the default demo certs/stores do not fullfill that requirement in production).

However communication from WLST to your weblogic domain needs some small adjustment. The normal steps would otherwise result in this error:

call "D:\myDomain\bin\setDomainEnv.cmd"
D:\myDomain>java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands

wls:/offline> connect('weblogic',weblogic','t3s://myserver.local.rubix.nl:7003')

Connecting to t3s://myserver.local.rubix.nl:7003 with userid weblogic ...

<8-apr-2010 13:39:55 uur CES> <Warning> <Security< <BEA-090542> <Certificate chain received from myserver.local.rubix.nl - 10.0.0.11 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.>

Traceback (innermost last):

File "<console>", line 1, in ?

File "<iostream>", line 22, in connect WLSTException: Error occured while performing connect : Error getting the initial context. There is no server running at t3s://myserver.local.rubix.nl:7003 Use dumpStack() to view the full stacktrace

wls:/offline>

*note: I use port 7003 because the Domain Admin Port is enabled in my domain.

Anyway, the connection to the Admin Server can not be established through SSL because there is no trust between the two components. To fix this some additional arguments need to be added.

D:\myDomain>java -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.CustomTrustKeyStoreType="JKS" -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName="D:/myDomain/security/myDomain.truststore.jks" weblogic.WLST

wls:/offline> connect(‘weblogic’,'weblogic’,'t3s://myserver.local.rubix.nl:7003′)

Successfully connected to Admin Server myDomain_admin’ that belongs to domain ‘myDomain’

wls:/myDomain/serverConfig> disconnect()

Disconnected from weblogic server: myDomain_admin

No let’s try to connect to the Nodemanager as well:

wls:/offline> nmConnect('weblogic','weblogic','myserver.local.rubix.nl','5556','myDomain','d:/myDomain','ssl')

Connecting to Node Manager …

Successfully Connected to Node Manager.

wls:/nm/myDdomain>

>Weblogic allows you to store clear-text passwords in configuration files when you have a development domain, however production mode forces the use of Triple-DES block ciphers to store these password. (that’s also the reason why the encrypted passwords begin with “{3DES}”)

Often this proces is done automatically by Weblogic, but in some cases it is good to know how to manually convert clear-text to a 3DES encrypted string. You can find these 3DES strings located in the domain’s config.xml, boot.properties, the service accounts used by the Oracle Service Bus (even when you use the RDBMS Security Store under your weblogic domain), etc.

For this we will need the domain’s password salt file SerializedSystemIni.dat.
Cibergavin made a good post explaining the importance of this specific file for your Weblogic domain.

SerializedSystemIni.dat is a WebLogic domain file which contains hashes. SerializedSystemIni.dat is located in the domain directory (WebLogic Server 8.1 and earlier) or in domain/security directory (WebLogic Server 9.x and later). The SerializedSystemIni.dat is created during the creation of a WebLogic domain. The hashes in the file are created using an algorithm that binds the file to the domain in which it has been created. So, a SerializedSystemIni.dat file can be used only within the domain in which it has been created.

Due to the use of the salt file (SerializedSystemIni.dat) you should execute the utility from your domain folder:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.security.EncryptPassword: weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

You can also pass the password as an argument:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.security.Encrypt weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

And last but not least you can use WLST:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...Welcome to WebLogic Server Administration Scripting ShellType help() for help on available commands

wls:/offline> es = encrypt('weblogic')wls:/offline> print es{3DES}p2rh5zuiDsut1yNTGtUfFg==wls:/offline>

After my earlier post regarding the Triple DES encryption Weblogic uses. The next question could be, can we decrypt the 3DES hash to cleartext again ? The answer is, yes you can.

On the Internet multiple examples are available, but I found this post from Chris Vugrinec ( hi m8 ) very helpfull so muchos credits to Chris.

Off course the java code needs to include the weblogic.jar and on runtime access to the domains SerializedSystemIni.dat which encapsulates a time-variant encrypted key created with the generation of the domain.

import java.io.Console;
import weblogic.security.internal.SerializedSystemIni;
import weblogic.security.internal.encryption.ClearOrEncryptedService;

public class DrieDesDecrypter
{
  static ClearOrEncryptedService ces;
  public static void main(String[] args)
  {
System.out.println("This class decrypts the 3DES string for Weblogic");
    Console console = System.console();
    String var_folder = console.readLine("Give PATH! where SerializedSystemIni.dat for weblogic domain is located: ");
    String var_driedes = console.readLine("Give 3DES string: ");
    ces = new ClearOrEncryptedService(SerializedSystemIni.getEncryptionService(var_folder));
    var_driedes = var_driedes.replace("\\", "");
    System.out.println("Decrypted value: " + ces.decrypt(var_driedes));
  }
}

The 1st input is the Directory where the SerializedSystemIni.dat resides
The 2nd input is the encrypted 3DES String
The output  is what you wanted.
Running would look something like:

c:\Oracle\domains\rbx_dev_wls\bin\setDomainEnv.cmd
java DrieDesDecrypter

This class decrypts the 3DES string for Weblogic
Give PATH! where SerializedSystemIni.dat for weblogic domain is located: C:\Oracle\domains\rbx_dev_wls\security
Give 3DES string: {3DES}OOLr88wGSPx82H1abcYU9Q==
Decrypted waarde: welcome1

This source-code should trigger any Weblogic Administrator to make sure it’s SerializedSystemIni.dat file is secured to prevent unauthorised access and included in the backup procedure.

Update 2012.01.26:

Due to lost passwords on a DEV environment I had to test my class with the new AES encryption used by Weblogic 11g (r1PS4) instead of the older 3DES algoritm it used to store it’s passwords in. And it still works like a charm. :)

Update 2012.06.27:

Make life much easier for those DEV/TST domains: http://recover-weblogic-password.appspot.com/
Don’t think I would like to use it for my PRD domains, but you make your own choice there,

I’m blogging this to help other people who might experience the same problem. On the other hand there are some loose ends where someone out there might contribute to.

So a project required SOAP/HTTP(S) requests over two-way SSL between Oracle Service Bus and a remote service running on Microsoft IIS 6.0.

Weblogic & OSB setup:
All certicates are stored in keystores and used by the nodemgr + admin + ms.
Weblogic has a PKICredentialMapper and in the SBconsole we have our ServiceKeyProvider configured. We build our proxy and business services where:
- BS is confgured with SSL and Authentication ClientCert (http transport Tab)
- PS is configured with the ServiceKeyProvider on the Security tab

Pretty default stuff, working with other backends. The callout however fails and the IIS guys claim they never receive a client-cert.

Callout from OSB:
clientIPhere, -, 1/11/2011, 15:51:18, serviceNameHere, serverNameHere, serverIPhere, 449859, 1160, 0, 403, 64, POST, /SomeService.asmx, -,

Callout from SOAPui from client workstation:
clientIPhere, -, 1/11/2011, 16:01:21, serviceNameHere, serverNameHere, serverIPhere, 187, 918, 916, 200, 0, POST, /SomeService.asmx, -,

According to this page the 403 is a forbidden error and the 0 in front of it means 0 bytes have been send from the server to the client.

So we enable Weblogic SSL debugging with the arguments: -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true

After the next callout we see this in the logging:

</soap:Body>>   *<-------- this is the last $body logging in the ProxyService before it calls the business* <Debug> <SecuritySSL> <BEA-000000> <SSLSetup: loading trusted CA certificates><Debug> <SecuritySSL> <BEA-000000> <clientInfo has new style certificate and key><Debug> <SecuritySSL> <BEA-000000> <Filtering JSSE SSLSocket><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.addContext(ctx): 270694655><Debug> <SecuritySSL> <BEA-000000> <SSLSocket will  be Muxing><Debug> <SecuritySSL> <BEA-000000> <write SSL_20_RECORD><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: ServerHello><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: Certificate><Debug> <SecuritySSL> <BEA-000000> <Validating certificate 0 in the chain: Serial number: 130583870796631153730390131696172958331Issuer:C=xxxxxxxxxxNot Valid Before:Wed Oct 20 02:00:00 CEST 2010Not Valid After:Sun Oct 20 01:59:59 CEST 2013Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <Validating certificate 1 in the chain: Serial number: 50682576685400420811231509872710703774Issuer:C=xxxxxxxNot Valid Before:Tue Jun 07 10:09:10 CEST 2005Not Valid After:Sat May 30 12:48:38 CEST 2020Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <validationCallback: validateErr = 0><Debug> <SecuritySSL> <BEA-000000> <  cert[0] = Serial number: 130583870796631153730390131696172958331Issuer:C=xxxxxxxxxxSubject:C=xxxxxxxNot Valid Before:Wed Oct 20 02:00:00 CEST 2010Not Valid After:Sun Oct 20 01:59:59 CEST 2013Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <  cert[1] = Serial number: 50682576685400420811231509872710703774Issuer:CxxxxxxxxNot Valid Before:Tue Jun 07 10:09:10 CEST 2005Not Valid After:Sat May 30 12:48:38 CEST 2020Signature Algorithm:SHA1withRSA><Debug> <SecuritySSL> <BEA-000000> <weblogic user specified trustmanager validation status 0><Debug> <SecuritySSL> <BEA-000000> <SSLTrustValidator returns: 0><Debug> <SecuritySSL> <BEA-000000> <Trust status (0): NONE><Debug> <SecuritySSL> <BEA-000000> <Performing hostname validation checks: www.nahetvo.nl><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: ServerHelloDone><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm MD5><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RSA><Debug> <SecuritySSL> <BEA-000000> <write HANDSHAKE, offset = 0, length = 134><Debug> <SecuritySSL> <BEA-000000> <write CHANGE_CIPHER_SPEC, offset = 0, length = 1><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <write HANDSHAKE, offset = 0, length = 16><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received CHANGE_CIPHER_SPEC><Debug> <SecuritySSL> <BEA-000000> <Using JCE Cipher: SunJCE version 1.6 for algorithm RC4><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HMACMD5><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <HANDSHAKEMESSAGE: Finished><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacMD5><Debug> <SecuritySSL> <BEA-000000> <Ignoring not supported JCE Mac: SunJCE version 1.6 for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <Will use default Mac for algorithm HmacSHA1><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 321><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 839><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.findContext(sock): 270693819><Debug> <SecuritySSL> <BEA-000000> <SSLIOContextTable.findContext(sock): 270693819><Debug> <SecuritySSL> <BEA-000000> <activateNoRegister()><Debug> <SecuritySSL> <BEA-000000> <SSLFilterImpl.activate(): activated: 270693844 270909954><Debug> <SecuritySSL> <BEA-000000> <270694391 read(offset=0, length=4080)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns true><Debug> <SecuritySSL> <BEA-000000> <270694400 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <270694400 received HANDSHAKE><Debug> <SecuritySSL> <BEA-000000> <NEW ALERT with Severity: WARNING, Type: 100java.lang.Exception: New alert stack        at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)        at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)        at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)        at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)        at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)        at com.certicom.tls.record.ReadHandler.read(Unknown Source)        at com.certicom.io.InputSSLIOStreamWrapper.read(Unknown Source)        at weblogic.socket.SSLFilterImpl.isMessageComplete(SSLFilterImpl.java:202)        at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:896)        at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:840)        at weblogic.socket.EPollSocketMuxer.dataReceived(EPollSocketMuxer.java:215)        at weblogic.socket.EPollSocketMuxer.processSockets(EPollSocketMuxer.java:177)        at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)        at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)><Debug> <SecuritySSL> <BEA-000000> <write ALERT, offset = 0, length = 2><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns false 1><Debug> <SecuritySSL> <BEA-000000> <270694391 Rethrowing InterruptedIOException><Debug> <SecuritySSL> <BEA-000000> <270694391 read(offset=0, length=8192)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: false><Debug> <SecuritySSL> <BEA-000000> <264112838 read(offset=0, length=4080)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns true><Debug> <SecuritySSL> <BEA-000000> <264114219 SSL3/TLS MAC><Debug> <SecuritySSL> <BEA-000000> <264114219 received APPLICATION_DATA: databufferLen 0, contentLength 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read databufferLen 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read A returns 29><Debug> <SecuritySSL> <BEA-000000> <264112838 read(offset=29, length=4051)><Debug> <SecuritySSL> <BEA-000000> <isMuxerActivated: true><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord()><Debug> <SecuritySSL> <BEA-000000> <hasSSLRecord returns false 1><Debug> <SecuritySSL> <BEA-000000> <264112838 Rethrowing InterruptedIOException><Debug> <SecuritySSL> <BEA-000000> <write APPLICATION_DATA, offset = 0, length = 29>

Just before the dump we see a: Warning, Type 100. The TLS protocol states informs us that this alert 100 would mean NO_RENEGOTIATION:

A.3. Alert messages

    enum { warning(1), fatal(2), (255) } AlertLevel;

        enum {            close_notify(0),            unexpected_message(10),            bad_record_mac(20),            decryption_failed(21),            record_overflow(22),            decompression_failure(30),            handshake_failure(40),            bad_certificate(42),            unsupported_certificate(43),            certificate_revoked(44),            certificate_expired(45),            certificate_unknown(46),            illegal_parameter(47),            unknown_ca(48),            access_denied(49),            decode_error(50),            decrypt_error(51),            export_restriction(60),            protocol_version(70),            insufficient_security(71),            internal_error(80),            user_canceled(90),            no_renegotiation(100),            (255)        } AlertDescription;

    struct {        AlertLevel level;        AlertDescription description;    } Alert;

So we use Wireshark which is one of the coolest free software tools out there. And even better, did I mention it’s free? With a Wireshark capture you can get a lot of information about the connection.

Essentially, what is going on here can be summarized as:

- Step 4: The client makes a hello request
- Step 8: The server responds with its certificate
- Step 10: The client key is send to server
- Step 11+12: Clients send a change of cipher spec and handshake message
- Step 14: Server send a change of cipher spec and handshake message
- Step 19: We see another server triggered handshake message followed by
- Step 20: Encrypted Alert

Since we are looking for something interesting, this Encrypted Alert is it. The problem here is that you can see an Alert but cant see the exact alert type.

I was hoping for a CERT_CHAIN_UNTRUSTED or BAD_CERTIFICATE since that would give me a good direction. But it looks like Weblogic logging shows an alert 100 (no_renegotiation) and we had to go with that.

no_renegotiation:
Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters
(key length, authentication, etc.) at startup and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.

I’m still not fully convinced of a no_renegotiation. Because for the client to trigger a renegotiation, it should send a new Client Hello message (in the encrypted channel, like any other handshaking message) which then the server responds with a Server Hello, and negotiation goes exactly as above. Other case when the server initiates a renegotiation it will send the client a Hello Request message on which he client simply sends a new Client Hello, exactly as above, and the process goes as usual. In the wireshark captures this behavious is not visible.

<update.2011-01-27>
I found this Wireshark capture in a document called “Renegotiating TLS” by Ray and Dispensa which shows the process of renegotiation.

</update.2011-01-27>

So as a fix we tried switching over from JRockit to Sun JDK, tried some arguments but in the end rolled everything back since 1 simple options seem to solve the issue:

With older version of Weblogic you can use these arguments for the jvm:
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
-Dssl.SocketFactory.provider=com.sun.net.ssl.internal.SSLSocketFactoryImpl
-DUseSunHttpHandler=true
-Dweblogic.wsee.client.ssl.usejdk=true (for webservice clients)

With the latest versions of Weblogic there is a “Use JSEE SSL” setting. The setting is located on the SSL (advanced) tab of the managed server.

So now our Wireshark capture looks like this:

The difference looks to occur after the server sends an encrypted handshake (ERR-capture step 19 & OK-capture step 42). In the OK-capture you can see the client sending an encrypted handshake after that (step 43), however the ERR-capture results in a Alert (step 20).

Focusing on the Weblogic logging and the NO_RENEGOTIATION message a guess would be that the different client implementations handle these renegotiations differently.

The Oracle Support Knowledge base mentions something like this (ID 1078957.1). The trace mentioned there isn’t identical as our error, however the solution seems to point in the same direction.

ERROR = HANDSHAKE_FAILURE
CAUSE = This may happen when the WebLogic server connects a remote Microsoft server.
SOLUTION =
This happened before the client got the ServerHello message. The Microsoft Server was refusing the handshake because the cipher suites given to the remote server were not 128 bits – the remote server wasn’t allowing anything lower. If the client license is changed on the WebLogic Server side, it will then work.

Our issue however is not identical (i think), because I can see that the client (weblogic) sends 19 cipher specs (among them TLS_RSA_WITH_RC4_128_MD5) and that the server agrees with this specific 00 44

TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA= { 0x00,0x63 }TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }TLS_DHE_DSS_WITH_NULL_SHA = { 0x00,0x67 }TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }

So our problems seems to be solved by using the Sun SSL implementation instead of the default Certicom one.

However that still leaves questions unanswered for me as:
- how come that other 2-way SSL trusts succeed with the default, but in this case with IIS6.0 as a service provider fails
- where does the 2-way SSL trust exactly fail, and how can I pinpoint this with tools like Wireshark ?
- what is the exact difference between Certicom and Sun’s implementation off TLS 1.0 ?

>This is just a reminder for myself, the code is not mine but can be found at multiple places on the web so I have no idea who the initial owner is and who to give credits.

export configuration:

java weblogic.WLST
connect('weblogic','weblogic', 't3://somedomain:7001')
domainRuntime()
cd('/DomainServices/DomainRuntimeService/DomainConfiguration/FirstDomain/SecurityConfiguration/FirstDomain/DefaultRealm/myrealm/AuthenticationProviders/DefaultAuthenticator')
cmo.exportData('DefaultAtn','/tmp/export.ldif', Properties())

import configuration:

java weblogic.WLST
connect('weblogic','weblogic', 't3://someotherdomain:7001')
domainRuntime()
cd('/DomainServices/DomainRuntimeService/DomainConfiguration/SecondDomain/SecurityConfiguration/SecondDomain/DefaultRealm/myrealm/AuthenticationProviders/DefaultAuthenticator')
cmo.importData('DefaultAtn','/tmp/export.ldif', Properties())

Default Weblogic DemoIdentity and DemoTrust keystore:

I always forget the default passwords, so a quick reminder:

Location: %WL_HOME%/server/lib
File = DemoIdentity.jks

• keystore password = DemoIdentityKeyStorePassPhrase
• key password = DemoIdentityPassPhrase

keytool -list -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase

File = DemoTrust.jks

• keystore password = DemoTrustKeyStorePassPhrase

	keytool -list -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

keytool -genkey -keysize 2048 -keyalg RSA -alias myhostname01 -keystore myhostname01_identity.jks

keytool -certreq -alias myhostname01 -file myhostname01.csr -keystore myhostname01_identity.jks

keytool -importcert -trustcacerts -alias rootCA -file rootCA.cer -keystore myhostname01_identity.jks -storepass mySecretPassword
keytool -importcert -alias chaincert1 -file chaincert1.cer -keystore myhostname01_identity.jks -storepass mySecretPassword
keytool -importcert -alias myhostname01 -file myhostname01.cer -keystore myhostname01_identity.jks -storepass mySecretPassword

keytool -v -importkeystore -srckeystore somecert.p12 -srcstoretype PKCS12 -destkeystore mytruststore.jks -deststoretype JKS

With the use of Oracle Web Service Manager (OWSM) we can easily configure Oracle Service Bus (OSB) services with different message security polices. This configuration can be done from Eclipse (OEPE), OSB SBConsole or the Enterprise Manager. One of the most common WS-Security mechanismes and therefor also OWSM policies is the UsernameToken where a username and password are send along with the message.

In this blog we will:

• part I: how to enable authentication of users against the list of all known users
• part II: how to enable authorisation of only a specific subset of users to access a service

First we configure a proxy service in OEPE with the OWSM UsernameToken policy oracle/wss_username_token_service_policy:

And make sure we process the WS-Security header:

After deployment we call the service with a request that is missing the WS-Security to test the result.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GreetingRequestMessage>
         <in>I say hello ...</in>
      <GreetingRequestMessage>
   </soapenv:Body>
</soapenv:Envelope>

As expected the result is an error because the OWSM policy requires a WS-Security segment in the SOAP-header which contains a username and password:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>BEA-386200: General web service security error</faultstring>
         <detail>
            <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
               <con:errorCode>BEA-386200</con:errorCode>
               <con:reason>General web service security error</con:reason>
               <con:location>
                  <con:path>request-pipeline</con:path>
               </con:location>
            </con:fault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

So to make sure we can send a UsernameToken we add 2 users to the Weblogic security realm called userA and userB.

The request to the proxy service containing the WS-Security UsernameToken for userA

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>userA</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcomeA1</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <GreetingRequestMessage>
         <in>I say hello ...</in>
      </GreetingRequestMessage>
   </soapenv:Body>
</soapenv:Envelope>

This results in a successfull response from the proxy service:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GreetingResponseMessage>
         <out>HelloWorld</out>
      </GreetingResponseMessage>
   </soapenv:Body>
</soapenv:Envelope>

So part 1 is complete, we succesfully implemented a proxy service that requires a WS-Security UsernameToken and authenticates these users against the Weblogic security realm. But in our case we have a tight security requirement and need to make sure the user is not only authenticated, but also authorized to access this specific service.

The result from part 1 means this is not the case, both userA and userB would be able to access this service. So let’s start part 2 where we will limit the access to the proxy service to only userB. For this we have to login to the sbconsole, since the OEPE does not allow you to make Message (or Transport) Access Control settings.

• Login the sbconsole
• Select Project Explorer
• Select the the proxy service
• Go to the Security Tab

• Click on Message Access Control option (either for the whole service or just a single operation).
• Click on Add Condition
• Select User from predicate list
• Type userB at the User Argument Name
• Click on Add and Finish
• Click on Save and Activate to finish the OSB session

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>BEA-386102: Message-level authorization denied</faultstring>
         <detail>
            <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
               <con:errorCode>BEA-386102</con:errorCode>
               <con:reason>Message-level authorization denied</con:reason>
               <con:location>
                  <con:path>request-pipeline</con:path>
               </con:location>
            </con:fault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Part 2 is completed and we finished with a proxy service that has both Authentication and Authorization enabled.

Remarks:

• You can also use groups and roles (rather than users) to authorize access to services.
• If you implement and configure an external LDAP (like Oracle Internet Directory) in Weblogic you can control ACL with groups central in your company LDAP instead of in each Weblogic security realm.
• The SOAP fault for Message Level Authorization denied (BEA-386102) contains a faultcode value of ”Server” which is not correct if you look at the w3c definition. This should be the value ”Client” because: “….. the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change”

Update 2011-08-10:
Added 3rd remark regarding the SOAP Fault code

Update 2012-01-13:
Using the OWSM username token policies you get some additional information on runtime in you $inbound variable. See this blogpost for more details.
References:

• OASIS: Web Service Security UsernameToken Profile 1.0
• ORACLE: Message-Level Access Control Policies for Proxy Services
• ORACLE: Securing Oracle Service Bus with Oracle Web Services Manager
• W3C: SOAP Fault Codes

I was debugging a OSB 11.1.1.5 proxy service which had a OWSM UserName token policy attached to it (read this blogpost how to configure your OSB). When I noticed the $inbound variable had some interesting information which I never noticed before.

The $inbound variable holds a big data-set regarding transport and usually a small data-set regarding security. In a “normal” unsecured proxy services this would result in something like this:

<inbound>
 <con:endpoint name="mySomething" xmlns:con="http://www.bea.com/wli/sb/context">
 <con:service>
 <con:operation>getEmployeeDetails</con:operation>
 </con:service>
<con:transport>
........
</con:transport>
 <con:security>
 <con:transportClient>
 <con:username>anonymous></con:username>
 </con:transportClient>
 </con:security>
 </con:endpoint>
</inbound>

So there is just a transportClient reference which normally just contains the value “anonymous”. Not really interesting.

However in the situation where the proxy service uses the OWSM policy it contains a new messageLevelClient element:

<inbound>
 <con:endpoint name="mySomething" xmlns:con="http://www.bea.com/wli/sb/context">
 <con:service>
 <con:operation>getEmployeeDetails</con:operation>
 </con:service>
<con:transport>
........
</con:transport>
 <con:security>
 <con:transportClient>
 <con:username>anonymous></con:username>
 </con:transportClient>
 <con:messageLevelClient>
 <con:username>weblogic</con:username>
 <con:principals>
 <con:group>AdminChannelUsers</con:group>
 <con:group>Administrators</con:group>
 <con:group>IntegrationAdministrators</con:group>
 </con:principals>
 </con:messageLevelClient>
 </con:security>
 </con:endpoint>
</inbound>

Pretty good information for tracing/logging your service calls.

We are using Oracle Service Bus for SSL communication to an external party. Due to security regulations we use a proxy server configuration (note: not proxy service, but proxy server) on these specific business services.

After upgrading our OSB to 11g PS4 we wanted to use the JSSE implementation for SSL because in the near future we will need to implement SHA2 certificates. After enabling JSSE (weblogic console -> managed server -> SSL -> Advanced) the outgoing connections still seem to work. However when we send a large message (in our case > 20kb) we receive the following error in our logging:

<Debug> <Socket> <someHostname> <someManagedServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <3fe931....> <13...> <BEA-000400> <buffer underflow in doHandshake>

The source of all knowlegde Wikipedia tells us that:
In computing buffer underrun or buffer underflow is a state occurring when a buffer used to communicate between two devices or processes is fed with data at a lower speed than the data is being read from it. This requires the program or device reading from the buffer to pause its processing while the buffer refills. This can cause undesired and sometimes serious side effects because the data being buffered is generally not suited to stop-start access of this kind.

After enabling Weblogic SSL logging we see the below output (simplified) in the logfiles when sending a small message. The SSLEngine both shows wrap and unwrap methods.

<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: >
<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: configured to defer to the admin>
<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: outbound = true>
<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: style = BuiltinSSLValidationOnly>
<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: returning false>
<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.certificateCallback: returning true because the CertPathValidators should not be called>
<Debug> <SecuritySSL> <BEA-000000> <weblogic user specified trustmanager validation status 0>
<Debug> <SecuritySSL> <BEA-000000> <SSLTrustValidator returns: 0>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: No trust failure, validateErr=0.>
<Debug> <SecuritySSL> <BEA-000000> <Performing hostname validation checks: remote.website.nl>
<Debug> <SecuritySSL> <BEA-000000> <Proxying through ourDMZproxyserver.local>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: Successfully completed post-handshake processing.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 304 bytesProduced = 325.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 2167 bytesProduced = 2188.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.unwrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 164 bytesProduced = 143.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.unwrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 1036 bytesProduced = 1015.>

When sending a larger message the logging seems identical, however the logging stops after the outbound communication (wrap method) and no inbound traphic seems to return (unwrap method).

<Debug> <SecurityCertPath> <BEA-000000> <CertPathTrustManagerUtils.doCertPathValidation: >
<Debug> <SecurityCertPath> <CertPathTrustManagerUtils.doCertPathValidation: configured to defer to the admin>
<Debug> <SecurityCertPath> <CertPathTrustManagerUtils.doCertPathValidation: outbound = true>
<Debug> <SecurityCertPath> <CertPathTrustManagerUtils.doCertPathValidation: style = BuiltinSSLValidationOnly>
<Debug> <SecurityCertPath> <CertPathTrustManagerUtils.doCertPathValidation: returning false>
<Debug> <SecurityCertPath> <CertPathTrustManagerUtils.certificateCallback: returning true because the CertPathValidators should not be called>
<Debug> <SecuritySSL> <weblogic user specified trustmanager validation status 0>
<Debug> <SecuritySSL> <SSLTrustValidator returns: 0>
<Debug> <SecuritySSL> <[Thread[[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: No trust failure, validateErr=0.>
<Debug> <SecuritySSL> <Performing hostname validation checks: remote.website.nl>
<Debug> <SecuritySSL> <Proxying through ourDMZproxyserver.local>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: Successfully completed post-handshake processing.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 306 bytesProduced = 327.>
<Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]...SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 16384 bytesProduced = 16405.>

At a very high level, the SSLEngine works like this (source: Class SSLEngine @ Oracle):

                |           ^
                |     |     |
                v     |     |
           +----+-----|-----+----+
           |          |          |
           |       SSL|Engine    |
   wrap()  |          |          |  unwrap()
           | OUTBOUND | INBOUND  |
           |          |          |
           +----+-----|-----+----+
                |     |     ^
                |     |     |
                v           |

Remember when we disable JSSE and use the Certicom implementation the process still works perfectly. So everything pointed to the direction of a combination: JSSE + large message = error. Sadly the .log and .out didn’t help in the problem solving here so experimenting with a few tuning parameters did the trick for us.

After configuring the Business Service to use Chunked Streaming Mode the problem was solved and we again succeeded in sending out messages of multiple MB’s to our external trading partners.

When I initially used Google and Oracle Knowledge base to look for the “BEA-000400 buffer underflow in doHandshake” error this was not very helpfull. So hopefully this blogpost is helpfull for others in the future when they have the same problem as us.

In our Oracle BPM 11.1.1.6 process we need some calls to Oracle UCM/WCC. Since UCM requires basic authentication we need to make sure the BPM process sends a token.

So in our composite we right-click the UCM webservice reference, select configure WS policies,

We select the oracle/wss_http_token_client_policy from the security list.

Now there are multiple ways options to configure the username + password:

• In JDeveloper we can configure the default value (handy for quick DEV deployments)

We need to configure a binding property, however the thing is that the oracle.webservices.auth properties are not there in the LOV.

However if we go to the composite source we can just manually add both
oracle.webservices.auth.username
oracle.webservices.auth.password

  <reference name="sourceUCM" ui:wsdlLocation="CheckIn.wsdl">
    <interface.wsdl interface="http://www.stellent.com/CheckIn/#wsdl.interface(CheckInSoap)"/>
    <binding.ws port="http://www.stellent.com/CheckIn/#wsdl.endpoint(CheckIn/CheckInSoap)"
                location="CheckIn.wsdl" soapVersion="1.1">
      <wsp:PolicyReference URI="oracle/wss_http_token_client_policy"
                           orawsp:category="security" orawsp:status="enabled"/>
      <property name="oracle.webservices.auth.username" type="xs:string" many="false" override="may">weblogic</property>
      <property name="oracle.webservices.auth.password" type="xs:string" many="false" override="may">welcome1</property>
    </binding.ws>
  </reference>

When deploying the project the settings are automatically set.

• Through Enterprise Manager (can be used to override the default)

If we navigate to our SOA Composite -> Dashboard tab ->  Services and References you can find a list of all webservice references.Click on it and go to the properties tab

Check the HTTP Basic Authentication segment and use this to override any DEV default settings (if necessary)

In our Oracle BPM/SOA project we initially started with 1 process which had a service call out to Oracle UCM/WCC. Since WCC uses basic authentication by default we enabled an OWSM policy on the external reference and made sure the username and password were set in the composite.xml. With the help of Oracle config plans we were able to transfer the SCA through the different OTAP environments.

<interface.wsdl interface="http://www.stellent.com/CheckIn/#wsdl.interface(CheckInSoap)"/>
<binding.ws port="http://www.stellent.com/CheckIn/#wsdl.endpoint(CheckIn/CheckInSoap)" location="oramds:/apps/rubix/references/UCM.wsdl" soapVersion="1.1">
<wsp:PolicyReference URI="oracle/wss_http_token_client_policy" orawsp:category="security" orawsp:status="enabled"/>
<property name="oracle.webservices.auth.password" type="xs:string" many="false" override="may">welcome2</property>
<property name="oracle.webservices.auth.username" type="xs:string" many="false" override="may">ucmuser</property>

However when there became more and more processes, with increased complexity and all with numberous callouts to backends with authentication enabled, the delivey of our release through the OTAP environment became more complex as well.Besides that, our Oracle ADF task screens needed connection to many of the same endpoints as well so we ended up with username and password properties in that deployment as well.

So to centralize the username and password in our environment we decided to use the full potential of the Oracle Credential Store Framework (CSF) for both BPM and ADF. Oracle CSF is part of the Oracle Platform Security Services (OPSS).

Since Oracle BPM relies heavily on the SOA-INFRA structure used by Oracle SOA Suite the functionality works identical. Lucky for us Edwin Biemond already blogged about this feature regarding Oracle SOA Suite which we could simple re-use for Oracle BPM.

Next step was Oracle ADF where our task has functionality to call web services which have the same basic authentication. Again we have a quick start by using this blogpost from Wilfred van der Deijl. In this blogpost he explains how to use a key to the credential store and how to retrieve it from your ADF application.

With the help of these 2 fellow Dutch Oracle techies blogs this turned out to be the smoothest user story in our last sprint ;-)

References:

• Blog Edwin Biemond – HTTP Basic Authentication with SOA
• Blog Wilfred van der Deijl – Credential Store Framework (CSF) with Oracle ADF
• Oracle – Configuring the Policy and Credential Store
• Oracle – Developing with the Credential Store Framework
• Oracle – About Oracle Platform Security Services

Not an Oracle blog for a change, but when an organization uses both Amazon Web Services (AWS) and Microsoft Office 365 it is possible to allow single sign-on with the internal LDAP Microsoft uses (Azure AD). Since RubiX uses both cloud products since day 1, I decided to look into integration between both products when Microsoft recently allowed SAML federation.

In this blog I will demonstrate how to connect Amazon Web Services (AWS) to the internal Azure Active Directory (AAD) that is used by Microsoft. As a result of this blog your users should be able to login to AWS from the Office 365 menu.

1. Configure Microsoft Office 365 / Azure Active Directory (AAD)

Go to your Administration console and select Azure AD from ADMIN

In the Azure AD console select “Active Direcory”, click on your Office 365 domain name and the AD menu should open. Click on “Applications” from the top menu

By defaut you will see a lot of Microsoft web applications, so we click on “Add+” on the bottom menu. Then select “Add application from the gallery”

The AWS application will be added to your list. Select Configure Single Sign-On next.

We will select the 1st option (MS AAD SSO) to establish federation between AAD & AWS. The Federated Single Sign-On enables the users in your organization to be automatically signed in to a third-party application like AWS by using the AAD user account information. In this scenario, when you have already been logged into Office 365 the federation eliminates the need for you to login again to AWS.

In this case, we don’t need to perform any extra advanced settings. So NEXT

Download the metadata XML and store it for future use and make sure to accept the checkbox

Go to the users tab and assign (bottom button) your users that are allowed to login to AWS

Before we can finalize our SSO from AAD, we first need to setup AWS.

2. Configure Amazon Web Service (AWS)

Login to your AWS account and select the Identity & Access Management

First we will create an Identity Provider for AAD.
Select SAML as Provider Type and choose a logical name (I use “Office365” in my example).
Browse to the exported metadata we downloaded from the AAD console earlier.

Important: check your metadata xml file

• The exported metadata XML file from Azure might be encoded as UTF-8 with byte order mark (BOM). Make sure to convert it to UTF-8 without BOM otherwise the AWS console will not be able to import it.
• Make sure to remove the <?xml version=”1.0″?> on line 1, otherwise AWS will not be able to parse the file

As a result we now have a SAML provider configured, so time to set some roles.
Select Roles in the IAM menu, select “Create New Role” and give your role a logical name (I use “RubixUsers” here)
In the Role Type select “Grant Web Single Sign-On (WebSSO) access to SAML providers“.

• Select the SAML provider we trust, so we use the earlier created “Office365” provider here.
• Next step we can customize the policy, which we won’t do so next.
• In the next step we can select the policy you want to attach to your SSO users.
  You can go fine grained with policies, but for now I will use the default PowerUser policy
• The last screen you will receive a review of the configuration, make sure to note down the Role ARN and Thrusted Entities
  Role ARN = arn:aws:iam::[customerID]:role/[RoleName]
  Trust = arn:aws:iam::[customerID]:saml-provider/[ProviderName]

3. Configure Microsoft Office 365 / Azure Active Directory (AAD) – part 2

Go back to the AAD management console (https://manage.windowsazure.com).
Select applications -> Amazon Web Services (AWS) -> Attributes

Add the following 2 attributes:

• name = https://aws.amazon.com/SAML/Attributes/Role
• value = arn:aws:iam::[customerID]:role/[RoleName],arn:aws:iam::[customerID]:saml-provider/[ProviderName]

• name = https://aws.amazon.com/SAML/Attributes/RoleSessionName
• value = user.userprincipalname

4. Result

With these configuration steps you are now able to login to AWS from your Office 365 apps tile.

After playing around with the CLI it’s time to run some instance on the Oracle Compute Cloud Service. Oracle offers a broad range of images divided in 3 categories namely: Oracle images, Private images and Marketplace. The marketplace holds almost 400 turn-key solutions (from PeopleSoft to WordPress) where the category Oracle images are mostly Oracle Enterprise Linux distributions.

For this blog I will start a Oracle Linux 7.2 machine on the Oracle Compute Cloud and connect through SSH from my own machine.

Setting up security (SSH)

First we need to create a private and public keypair to authenticate against the Linux instance. Where the private key is safely stored on my desktop, the public key will be uploaded to the Oracle Compute Cloud. Run the following command:

jvzoggel$ ssh-keygen -b 2048 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/jvzoggel/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): verySecret1
Enter same passphrase again: verySecret1
Your identification has been saved in /Users/jvzoggel/.ssh/id_rsa.
Your public key has been saved in /Users/jvzoggel/.ssh/id_rsa.pub.

In the Oracle Compute Cloud Service console we select Network -> SSH Public Keys.
Select the generated .pub file (which holds your public key and is safe to share).

Now that the Oracle cloud knows our public key it can allow secure authentication to it’s instances. However we need to do some security configuration to make sure the SSH traffic will be able to passthrough. This can be done during the instance creation, but I think it’s better to do it upfront.

Creating a secure ip list (source)

Under Network -> Shared Network -> Security IP-Lists we add a new entry. Any entry can hold multiple IP ranges, but in our case we will just add 1 IP address which is our public IP address on the internet. If you don’t know what your IP is entering the WWW then google on “what is my IP address” and many sites will help you out. Enter your address as shown below and select create.

Creating a secure list (target)

The next step is to create a security list. A security list is a bundle of 1 to many instances that you can use as source or destination in security rules. Before we create our security rule and even instance, we create the list upfront that will hold that 1 instance for security rule destination.

Creating a secure rule (bring it all together)

You can use security rules to control network access between your instances and the Internet. In this case we will create a rule that allows only SSH traphic, from our own machine to the soon to be created instance in our (now empty) security list. Oracle Compute recognises a lot of default security applications among them SSH. Make sure to select the IP list as source and list as destination.

Security should be all set, let’s start our first instance.

Creating a secure Instance on Oracle Compute Cloud

Under Instances -> Instance we select Oracle Images and get a latest version of Oracle Enterprise Linux. Make sure not to select Review and Create but use the “>” button on the right of it. My opinion the UX is not really explanatory here, it would be better to label it “Configure and Create” or something.

Go through the wizard and during the Instance step make sure to add the public SSH key we uploaded earlier. This will allow access to our instance with SSH without the need of a password.

In the Network step of the wizard we add the new instance to our freshly created security list. With this, the instance will inherit all the security rule configurations we made earlier.

Finish the wizard and wait for the Compute Cloud Orchestration to complete. After that your instance should be running.

Proof of the pudding

Check the public IP of your Oracle Compute Cloud instance and use it in your shell to connect with the SSH command.

And voila…

jvzoggel$ ssh -i /Users/jvzoggel/.ssh/id_rsa opc@120.140.10.50 
[opc@bd8ee6 /]
[opc@bd8ee6 /]$ whoami
opc
[opc@bd8ee6 /]$
[opc@bd8ee6 /]$ cat /etc/oracle-release
Oracle Linux Server release 7.2

References

• Oracle: Using Oracle Compute Cloud Service (for PaaS) – Generating an SSH Key Pair
• Oracle: Permitting SSH Access to Oracle Compute Cloud Service Instances

>Yesterday something strange happened while configuring a Service Key Provider in the OSB SBconsole.

The following error occured:
Security:090802 PKI Credential Mapper has got an LDAP exception.
And it was impossible to activate the SBconsole session.

Because we use a RDBMS security store running on a Oracle Database the DBA had run a script named “rdbms_security_store_oracle.sql” as deliverd by Oracle/BEA.

However apparently the default length of some fields in table BEAPRMP (VARCHAR256) apparently is not enough.

After dropping the table and recreating it with larger (VARCHAR1024) values the problem was fixed.

*update* I received an email that in another case they only got the problem fixed by using 2048 instead of 1024.

In this case we need to publish messages from the OSB 10.3.1 to Siebel 8.1.1.2 where Siebel supports different options for authentication of incoming HTTP webservice requests.

• passing the user name and password in the URL (basic authentication)
• A sort of custom Siebel Soap Header token like:

<soap:Header>
     <UsernameToken xmlns="http://siebel.com/webservices">user</UsernameToken>
     <PasswordText xmlns="http://siebel.com/webservices">hello123</PasswordText>
     <SessionType xmlns="http://siebel.com/webservices">None</SessionType>
</soap:Header>

• And last but not least; Siebel claims to support the WS-Security UserName Token mechanism. However Siebel only supports the PasswordText option so the password will still be send in clear text.

We concluded that the URL or the custom header option was not acceptable due to the customers security requirements. The only acceptable solution for them would be the WS-security UsernameToken. Within the OSB this can be arranged by using a WS-policy and a Service Account and connect them to the outgoing business service. Since the password will still be in cleartext, we will use SSL to protect the password on it’s journey over the dark trenches of our WAN.

So here we start off:

1st the Siebel configuration for inbound services. Make sure the authentication type is set to username/password clear text.

2nd the WS-policy used (very basic):

<wsp:Policy wsu:Id="WS-Policy-Siebel"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <wssp:Identity xmlns:wssp="http://www.bea.com/wls90/security/policy">
    <wssp:SupportedTokens>
      <wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken">
        <wssp:UsePassword Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"/>
      </wssp:SecurityToken>
    </wssp:SupportedTokens>
  </wssp:Identity>
</wsp:Policy>

<soapenv:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
    <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="unt_hzo9Xh2IiCqSYGaH">
      <wsse:Username>SADMIN</wsse:Username>
      <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SADMIN</wsse:Password>
    </wsse:UsernameToken>
  </wsse:Security>
</soapenv:Header>

<Body>
  <Fault>
    <faultcode>SOAP-ENV:MustUnderstand</faultcode>
    <faultstring>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</faultstring>
      <detail>
          <siebelf:siebdetail xmlns:siebelf="http://www.siebel.com/ws/fault">
          <siebelf:logfilename>EAIObjMgr_nld_0014_14680077.log</siebelf:logfilename>
          <siebelf:errorstack>
          <siebelf:error>
          <siebelf:errorcode>SBL-EAI-08000</siebelf:errorcode>
          <siebelf:errorsymbol/>
          <siebelf:errormsg>Unable to process SOAP Header child element 'wsse:Security' with 'mustUnderstand="1"'((SBL-EAI-08000)</siebelf:errormsg>
          </siebelf:error>
          </siebelf:errorstack>
          </siebelf:siebdetail>
      </detail>
    </Fault>
</Body>

After contact with Oracle Support I received confirmation from the Siebel Team that this is a limitation from Siebel, as it is not accepting the latest WS-Security definition. The option they give you is that for now it’s the caller’s responsibility to change the header to conform to the namespace Siebel is expecting.

So a new challenge for the OSB. The project looks something like this:

The solution for it is the fn-bea:lookupBasicCredentials function. We use an Assign Action to get the expression
fn-bea:lookupBasicCredentials(‘myRubixProject/security/SA.Siebel.MyRubixProject’)
result in a variable named $varBasicCredentials with the following content:

<con:UsernamePasswordCredential xmlns:con="http://www.bea.com/wli/sb/services/security/config">
  <con:username>SADMIN</con:username>
  <con:password>SADMIN</con:password>
 </con:UsernamePasswordCredential></pre>
We edit the Replace action to use the username and password elements.
<pre class="brush: xml"><soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" soapenv:mustUnderstand="1">
   <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsse:Username>{$varBasicCredentials/con:username/text()}</wsse:Username>
     <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{$varBasicCredentials/con:password/text()}</wsse:Password>
    </wsse:UsernameToken>
   </wsse:Security>
 </soapenv:Header>

Don’t forget to add the con namespace to the Replace action.

Finally, succes at last !!! :)
Off course this is just a workaround to make sure that Siebel and OSB speak te same “namespace language”. Let’s hope that Siebel 11g fixes this. After all, when it runs on Weblogic it must be good ;-)

Special thanks to Anuj Dwivedi for pointing me out the posibilities of the  fn-bea:lookupBasicCredentials function

When your Administration Server, NodeManager and Managed Servers use SSL to communicate with each other you have a decent basic security for your Weblogic domain. (And NO, the default demo certs/stores do not fullfill that requirement in production).

However communication from WLST to your weblogic domain needs some small adjustment. The normal steps would otherwise result in this error:

call "D:\myDomain\bin\setDomainEnv.cmd"
D:\myDomain>java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands

wls:/offline> connect('weblogic',weblogic','t3s://myserver.local.rubix.nl:7003')

Connecting to t3s://myserver.local.rubix.nl:7003 with userid weblogic ...

<8-apr-2010 13:39:55 uur CES> <Warning> <Security< <BEA-090542> <Certificate chain received from myserver.local.rubix.nl - 10.0.0.11 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.>

Traceback (innermost last):

File "<console>", line 1, in ?

File "<iostream>", line 22, in connect WLSTException: Error occured while performing connect : Error getting the initial context. There is no server running at t3s://myserver.local.rubix.nl:7003 Use dumpStack() to view the full stacktrace

wls:/offline>

*note: I use port 7003 because the Domain Admin Port is enabled in my domain.

Anyway, the connection to the Admin Server can not be established through SSL because there is no trust between the two components. To fix this some additional arguments need to be added.

D:\myDomain>java -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.CustomTrustKeyStoreType="JKS" -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName="D:/myDomain/security/myDomain.truststore.jks" weblogic.WLST

wls:/offline> connect(‘weblogic’,’weblogic’,’t3s://myserver.local.rubix.nl:7003′)

Successfully connected to Admin Server myDomain_admin’ that belongs to domain ‘myDomain’

wls:/myDomain/serverConfig> disconnect()

Disconnected from weblogic server: myDomain_admin

No let’s try to connect to the Nodemanager as well:

wls:/offline> nmConnect('weblogic','weblogic','myserver.local.rubix.nl','5556','myDomain','d:/myDomain','ssl')

Connecting to Node Manager …

Successfully Connected to Node Manager.

wls:/nm/myDdomain>

>Weblogic allows you to store clear-text passwords in configuration files when you have a development domain, however production mode forces the use of Triple-DES block ciphers to store these password. (that’s also the reason why the encrypted passwords begin with “{3DES}”)

Often this proces is done automatically by Weblogic, but in some cases it is good to know how to manually convert clear-text to a 3DES encrypted string. You can find these 3DES strings located in the domain’s config.xml, boot.properties, the service accounts used by the Oracle Service Bus (even when you use the RDBMS Security Store under your weblogic domain), etc.

For this we will need the domain’s password salt file SerializedSystemIni.dat.
Cibergavin made a good post explaining the importance of this specific file for your Weblogic domain.

SerializedSystemIni.dat is a WebLogic domain file which contains hashes. SerializedSystemIni.dat is located in the domain directory (WebLogic Server 8.1 and earlier) or in domain/security directory (WebLogic Server 9.x and later). The SerializedSystemIni.dat is created during the creation of a WebLogic domain. The hashes in the file are created using an algorithm that binds the file to the domain in which it has been created. So, a SerializedSystemIni.dat file can be used only within the domain in which it has been created.

Due to the use of the salt file (SerializedSystemIni.dat) you should execute the utility from your domain folder:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.security.EncryptPassword: weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

You can also pass the password as an argument:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.security.Encrypt weblogic{3DES}p2rh5zuiDsut1yNTGtUfFg==

And last but not least you can use WLST:

cd d:\myDomain\binsetDomainEnv.cmdjava weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...Welcome to WebLogic Server Administration Scripting ShellType help() for help on available commands

wls:/offline> es = encrypt('weblogic')wls:/offline> print es{3DES}p2rh5zuiDsut1yNTGtUfFg==wls:/offline>

After my earlier post regarding the Triple DES encryption Weblogic uses. The next question could be, can we decrypt the 3DES hash to cleartext again ? The answer is, yes you can.

On the Internet multiple examples are available, but I found this post from Chris Vugrinec ( hi m8 ) very helpfull so muchos credits to Chris.

Off course the java code needs to include the weblogic.jar and on runtime access to the domains SerializedSystemIni.dat which encapsulates a time-variant encrypted key created with the generation of the domain.

import java.io.Console;
import weblogic.security.internal.SerializedSystemIni;
import weblogic.security.internal.encryption.ClearOrEncryptedService;

public class DrieDesDecrypter
{
  static ClearOrEncryptedService ces;
  public static void main(String[] args)
  {
System.out.println("This class decrypts the 3DES string for Weblogic");
    Console console = System.console();
    String var_folder = console.readLine("Give PATH! where SerializedSystemIni.dat for weblogic domain is located: ");
    String var_driedes = console.readLine("Give 3DES string: ");
    ces = new ClearOrEncryptedService(SerializedSystemIni.getEncryptionService(var_folder));
    var_driedes = var_driedes.replace("\\", "");
    System.out.println("Decrypted value: " + ces.decrypt(var_driedes));
  }
}

The 1st input is the Directory where the SerializedSystemIni.dat resides
The 2nd input is the encrypted 3DES String
The output  is what you wanted.
Running would look something like:

c:\Oracle\domains\rbx_dev_wls\bin\setDomainEnv.cmd
java DrieDesDecrypter

This class decrypts the 3DES string for Weblogic
Give PATH! where SerializedSystemIni.dat for weblogic domain is located: C:\Oracle\domains\rbx_dev_wls\security
Give 3DES string: {3DES}OOLr88wGSPx82H1abcYU9Q==
Decrypted waarde: welcome1

This source-code should trigger any Weblogic Administrator to make sure it’s SerializedSystemIni.dat file is secured to prevent unauthorised access and included in the backup procedure.

Update 2012.01.26:

Due to lost passwords on a DEV environment I had to test my class with the new AES encryption used by Weblogic 11g (r1PS4) instead of the older 3DES algoritm it used to store it’s passwords in. And it still works like a charm. :)

Update 2012.06.27:

Make life much easier for those DEV/TST domains: http://recover-weblogic-password.appspot.com/
Don’t think I would like to use it for my PRD domains, but you make your own choice there,

Since we both use Azure AD (Office365 / LDAP) for the companies user management and AWS for our hosting we already enabled federation between these cloud providers. This works perfectly by assuming an IAM Role through the Azure AD credentials and have console access through single-sing-on.

However to use the AWS CLI a user would need programmatic access and it’s access and secret keys. Luckily for us there is an excellent open-source project for that called aws-azure-login. And since it’s on npm very easy to run on Mac, Linux and Windows.

What do we need ?

• install the package as mentioned: npm install -g aws-azure-login (or not global if you fancy that)
• you will need your Azure Tenant ID which the Azure administrator can supply ( Azure AD -> Properties -> Directory ID )
• and the Azure Application ID and again the Azure administrator ( Enterprise Applications -> Amazon Web Services -> Properties -> Application ID )
• you might want to know the AWS IAM Role max session duration to prevent some trial on error which your AWS administrator can supply (default is 1 hour)

First we will create an Azure profile:

jvzoggel$ aws-azure-login --configure --profile rubix
Configuring profile 'rubix'
? Azure Tenant ID: some-guid-you-will-need-part-1
? Azure App ID URI: some-guid-you-will-need-part-2
? Default Username: jvzoggel@rubix.nl
? Default Role ARN (if multiple):
? Default Session Duration Hours (up to 12): 2

The max session duration on the AWS IAM Role is the last parameter, if you enter a to high value you will receive an error but only after the next step login. So ask first, or trial on error.

Then we actually login on Azure:

jvzoggel$ aws-azure-login --profile rubix --no-prompt
Logging in with profile 'rubix'...
? Password: [hidden]
Please type in the code displayed on your authenticator app from your device
? Verification Code: 424242
Assuming role arn:aws:iam::42:role/rbx-sso-myrole

Since we configured MFA on Azure AD there is also the Verification Code besides the password to provide. When we succeed the aws-azure-login actually generated a profile in the AWS credentials configuration which holds the access and secret key. So let’s check.

Connect to AWS

jvzoggel$ cat /Users/jvzoggel/.aws/credentials

[rubix]
aws_access_key_id=A..............
aws_secret_access_key=X.............
aws_session_token="F......."
aws_session_expiration=2019-01-31T23:01:14.000Z

jvzoggel$ export AWS_PROFILE=rubix
jvzoggel$ aws s3api list-buckets
{
    "Buckets": [
        {
            "Name": "awsamplify-20181220092431-deployment",
        .....