09 November 2015

HFM still insecure

In the last few months, I've described how HFM is not working in secure configurations (i.e. does not support encryption/SSL):
It looks like the recently-released patch .102 still does not fix this glaring omission. Clearly security is very low in Oracle's list of priorities (but I'm sure their cloud setups are really really secure, uh-uh...).

Anyway, in the previous posts I recommended to work around this problem by having all HFM components on one single well-firewalled box. This setup was already sub-optimal (it's a single point of failure, and of course it might not meet some workload requirements), but as I went through other items it became clear that it's even more untenable than I previously thought.

This is because components integrating with HFM (Financial Reporting, Calculation Manager, OBIEE and so on) will talk directly to application and cluster processes, bypassing the Weblogic-based web-application. Because of the previously-mentioned bug, communication will be completely unencrypted.

This means that theoretically, if any component uses the HFM API to integrate, it would have to run on the same single box as HFM.

You're going to need a bigger boat

The only exceptions to this rule are:
  • the EPM Architect Dimension Server service, which will go through the web-app for its own calls (all related to metadata, like deployment, lookups etc). However, EPM Architect's own DataSynchronization service (which can automatically copy data across EPM products) will again go directly to appserver processes without encryption.
  • webservices-based products like Financial Close Manager, Tax Governance etc (i.e. products built on Oracle SOA). These integrate with HFM via its web service interface exposed by Weblogic, which can be easily secured with SSL.

Bonus: a teaser

If you feel adventurous, you can figure out why HFM does not work with SSL.

  1. Create the EPM Registry properties mentioned in logs as reported in my first post.
  2. Run Process Monitor while you start the HFM JavaServer process.
  3. In the resulting capture, look for "File Not Found" containing "user_projects" in path. One of these files should look familiar...

07 November 2015

Link feeds about Weblogic, EPM, Hyperion etc

I've recently started using the excellent Pinboard bookmark manager (a wonderful throwback to the glory days of del.icio.us) to keep track of interesting posts. While I think about the best way to syndicate those links across all my public accounts, you can check out these feeds:

26 October 2015

Cluster strategies in Oracle Hyperion Financial Management

While poking around HFM for other reasons, I’ve found a bunch of interesting constants...
  • STR_HITREG_SERVER_STRATEGY = "ServerStrategy";
From other code and messages, it looks like ServerStrategy is supposed to be a property of the HFM database node in EPM Registry. It’s retrieved on startup, and will always default to 0 (”round robin”) because the property is not actually there unless you manually create it. It lseems to govern the load-distribution strategy employed by clients (i.e. the HFM web application), i.e. where to send each new login if the user has not logged on before and/or the documented StickyServer option is not enabled.

Don't raise your expectations anyway: it looks like the ”load based” strategy (2) has not actually been implemented yet, and if you choose it you’ll actually get the Round-Robin one; whereas ”Random” (1) is really random.

From what I can gather, Round-Robin will follow the list of servers specified in property serverList of the cluster node in EPM Registry, going through the list in the specified order. It’s also entirely in memory and never saved to disk or DB, from which we can deduce that:
  • each webapp or client will do its own thing, with no coordination between them;
  • each webapp or client will forget everything on restart;
  • each webapp will default to Round-Robin strategy and send logins to each appserver in the order specified by serverList
The main advice at this point is hence to keep your beefier appservers at the beginning of serverList, since they're more likely to receive traffic. Alternatively, add ServerStrategy and trust the random algorithm to distribute logins... randomly ;)

I suspect this stuff is a prelude of things to come, because it’s used in sections of code that also deal with SSL initialisation for communication with the appserver, i.e. something that is not quite baked yet but must have been added recently. It’s also pure Java, so can’t be older than Does that mean we’ll finally get real load-balanced clustering in HFM (more than 10 years after people asked for it)…?

18 October 2015

Financial Management still cannot be secured

I was hoping the recent wave of patches (.100 and .101) for HFM-- sorry, Oracle EPM Financial Management would have started to address those well-known security problems that have been plaguing this (otherwise remarkable) release. Unfortunately, that is not the case.

To begin with, the server component is still looking for the wrong properties in registry ("isSSL" and "SSL_Port" rather than the actually existing "isSslEnabled" and "ssl_port"). This means that, whichever option you select in Configuration Utility, the component will default to ssl-disabled.

If we try to trick it, by manually adding the properties it's looking for, we get the following errors and the service shuts down:

[...] [FM] [ERROR] [] [oracle.FM.HSX.SERVER.oracle.epm.fm.hsxserver.HsxServer] [...] 
[SRC_CLASS: oracle.epm.fm.hsxserver.HsxServer] 
[SRC_METHOD: startThriftServices] An error occurred while starting HSX_SERVER_NAME service.[[
org.apache.thrift.transport.TTransportException: Either one of the KeyStore or TrustStore must be set for SSLTransportParameters
at org.apache.thrift.transport.TSSLTransportFactory.getServerSocket(TSSLTransportFactory.java:99)
at oracle.epm.fm.common.BaseSeviceManager.getSSLServerTransport(BaseSeviceManager.java:121)
at oracle.epm.fm.common.BaseSeviceManager.startService(BaseSeviceManager.java:68)
at oracle.epm.fm.hsxserver.HsxServer.startThriftServices(HsxServer.java:64)
at oracle.epm.fm.hsxserver.HsxServer.init(HsxServer.java:43)
at oracle.epm.fm.hsxserver.HsxServer.main(HsxServer.java:27)
[...] An error occurred while starting HSX_SERVER_NAME service.[[
oracle.epm.fm.common.exception.HFMException: EPMHFM-66019: An error occurred while starting HSX_SERVER_NAME service.
at oracle.epm.fm.hsxserver.HsxServer.startThriftServices(HsxServer.java:70)
at oracle.epm.fm.hsxserver.HsxServer.init(HsxServer.java:43)
at oracle.epm.fm.hsxserver.HsxServer.main(HsxServer.java:27)

As you can see, it complains about missing keystores. This was always a possibility, since we never got a chance to specify such a thing during configuration; however, most SSL-aware software usually ships with demo keys preconfigured for tests, so it was not unreasonable to expect HFM would do the same. No such luck!

Hopefully both problems will be comprehensively addressed sooner rather than later. As it is, secure implementations still have to rely on both HFM web and app components running on a single box with a tight firewall, which is far from ideal.

Bonus: Peeking Under The Hood

These errors lift the veil on some of the development strategies Oracle employed to remove hard dependencies between HFM and Windows-specific DCOM.

It looks like they are using Apache Thrift, which can be roughly described as a serializer library to auto-generate network APIs for existing programs. They basically dropped DCOM network code and replaced it with a simpler network interface built on (if my speculation from the previous post is correct) some Weblogic subcomponent; this interface uses Thrift-generated serializations to pass data between appserver processes and the ADF-based web application.

In theory, such an approach could make it easier for third-party components to open connections directly to the HFM appserver, bypassing the need for specific client libraries (with their byzantine requirements) and just using Thrift to figure out necessary calls. However, I'm not really an expert in this field and I don't really know what this effort would entail; at this point, your best bet for custom integration is still likely to be the official HFM SDK.

13 October 2015

OSX 10.11 El Capitan and Kinesis Freestyle 2 Bluetooth little glitch

After upgrading to El Capitan, my Kinesis Freestyle 2 Bluetooth keyboard had a small issue, which I'm documenting here in case other people hit it.

Basically, after installing the OS update, F*/special keys were dead. Solution:
  1.  Open System Preferences -> Bluetooth
  2. Click on the X icon to the right of the keyboard, in order to un-pair it.
  3. turn the Kinesis off, then on again, and press the CONNECT button at the back of the keyboard
  4. The keyboard should pop on the screen, select it and pair it again (you will have to type a few numbers shown on screen)
All done! You should now have your special keys back.