Silent UCF. HowTo

As was promised in previous post, I describe how make webtop customers happy.

What is the problem?

It seems that when Oracle acquired Sun it also acquired a bunch of security issues in JRE, for example, it’s pretty obvious that even if applet is signed by valid certificate it’s not enough to consider it as trusted – benign applet could be potentially used for malicious purposes (for example UCF applet is capable to launch any program on user’s machine, so attacker may exploit this capability). Security measures for this issue are obvious: just bind applet to specific website, and Oracle did it: JAR File Manifest Attributes for Security. Unfortunately these “innovations” are barely suitable for self-hosted applications – URLs vary from customer to customer, which makes it impossible to create applet suitable for every customer, though, I suppose EMC’s customers pay enough support fees to have an ability to request “custom” UCF applet from EMC, “custom” means that only manifest changes are required and such procedure could be easily automated – why do not create special service on customer portal? Instead of doing correct things EMC suggests something weird:

Actually, I double-checked Oracle’s documentation and was unable to find a place where they suggest to delegate security-related questions to business users, I suppose that EMC guys think that some posts in forums/blogs/etc have a status of official documentation, that, in fact, is not surprising: for example, IIG’s director of security prefers to get inspiration from this blog instead of performing code review:

Possible solutions

Anyway, Oracle’s suggestions related to security prompts are:

Though rule sets option is straightforward I do not think that it is helpful due to following reasons:

  • it costs money: “The JAR file must be signed with a valid certificate from a trusted certificate authority”
  • it is dangerous: “The Deployment Rule Set feature is optional and shall only be used internally in an organization with a controlled environment. If a JAR file that contains a rule set is distributed or made available publicly, then the certificate used to sign the rule set will be blacklisted and blocked in Java”, i.e. you risk to loose money spent for your certificate
  • if you already have a “valid certificate from a trusted certificate authority” why do not sign all applets in enterprise? So, this option is more suitable for cases when applets are embedded in hardware devices like KVMs, iLOs, etc and you unable to replace those applets
  • I think the best case for rule sets is enable certain known applets and block all other

Second option costs money too because it requires a “valid certificate from a trusted certificate authority”, but it’s the only disadvantage of this option. So, what did I do to disable all security prompts in previous video? Obviously, at first, we bought code-signing certificate.


Let’s take a look at security prompts raising when UCF applet gets loaded:

  • Java’s standard prompt asking whether user is going to trust applet’s certificate:
  • UCF’s prompt aimed to prevent malicious usage of applet (whitelisting):
  • Java’s prompt about not following security best practices:

For the third option EMC, as we already know, suggests to tick “Do not show this again for this app and web site” checkbox before accepting security warning. Besides the fact that delegating security-related questions to end-users is not a good idea, this options does not work properly. The problem is WDK generates special URLs for applets to prevent them from caching by JRE:

here “19gmgko28” and “98th” parts of URL are just encoded values of last modified time and size of applet file:

-bash-4.1$ stat -c "Last Modified: %Y, size: %s" \
> app/webapps/wp/wdk/system/ucfinit.jar
Last Modified: 1426684797, size: 304049
-bash-4.1$ groovysh
Groovy Shell (2.4.1, JVM: 1.6.0_45)
Type ':help' or ':h' for help.
groovy:000> import com.documentum.web.util.StringUtil
===> com.documentum.web.util.StringUtil
groovy:000> StringUtil.toUnsignedString(1426684797000,5)
===> 19gmgko28
groovy:000> StringUtil.toUnsignedString(304049,5)
===> 98th

Such behaviour of WDK has following disadvantages:

  • redeploying/updating webtop changes last modified time or/and size of applet file
  • in clustered environment it’s expected that applet file has different last modified time on different nodes

also we already know that the cornerstone of UCF troubleshooting is to delete everything related to Java and Documentum, reinstall JRE, press ctrl+alt+reset, etc – these activities obviously wipe user’s settings, it’s clear that ticking “Do not show this again for this app and web site” checkbox is just a temporary workaround, so, we decided to sign applet by our certificate. The procedure is straightforward:

  • edit META-INF/MANIFEST.MF, you should get something like (note Caller-Allowable-Codebase, Application-Library-Allowable-Codebase and Codebase headers):
    Manifest-Version: 1.0
    Built-By: dmadmin
    Application-Name: Documentum
    Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
    Copyright: Documentum Inc. 2001, 2004
    Caller-Allowable-Codebase: docum-at-app
    Build-Date: January 17 2015 09:07 PM
    Ant-Version: Apache Ant 1.8.4
    Title: Documentum Client File Selector Applet
    Application-Library-Allowable-Codebase: docum-at-app
    Bundle-Version: 6.7.2220.0231
    Build-Version: 6.7.2220.0231
    Permissions: all-permissions
    Codebase: docum-at-app
  • remove old signature files, i.e. META-INF/DOCUMENT.RSA and META-INF/DOCUMENT.SF
  • run jarsigner to sign applet – do not forget to specify TSA URL

after that applet is ready for deployment in production. What about another two security prompts? I suppose it is obvious that whitelisting capability is now useless because now JRE performs the same checks, below is an example of security notice when applet gets loaded from non-trusted URL:

because of these considerations, I decided to disable whitelisting capability, unfortunately the only option to disable it in UCF is decompile class: methods isHostAllowed(String) and isHostAllowed(String, IHostVerifier) must always return true (I bet it doesn’t worth to mention that after replacing class in applet you must sign applet again).

And finally, to remove the first security prompt I read Deployment Configuration File and Properties article and decided that manipulating by User Level configuration files is not a good idea, but System Level configuration files could be easily distributed among users’ machines in enterprise using various deployment tools, so, I did following (note naming convention of certificate alias):

C:\Windows\system32>md C:\Windows\Sun\Java\Deployment

C:\Windows\system32>cd C:\Windows\Sun\Java\Deployment

C:\Windows\Sun\Java\Deployment>type CON > deployment.config

C:\Windows\Sun\Java\Deployment>type CON >\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

C:\Windows\Sun\Java\Deployment>keytool.exe -importcert -keystore trusted.certs -file G:\Users\andrey\work\cert.crt -alias deploymentusercert$tsflag$loc=http//docum-at-app:8280##docbase:http//docum-at-app:8280##from:http//docum-at-app:8280
Enter keystore password:
Re-enter new password:


Trust this certificate? [no]:  yes
Certificate was added to keystore


5 thoughts on “Silent UCF. HowTo

  1. Very interesting article.

    It is time to release a new framework for any Documentum web app. Until now, D2 and any Documentum web app, without the Java applet, are not easy for standard end user but HTML5 can implement much of the logic executed in the today applet.

    HTML5 has everything needed to replace the applet: a local database to store information about checked out files and to manage the ecm “local/temporary” file system,the drag and drop feature too. The ACS support can be implemented just as server side logic. Not sure HTML5 can manage parallel streams download but this is a feature that 90% of users does not strictly need. Regarding the other UCF features like XML application, virtual document support, most of them are not used by 80% of the standard users.

    I hope EMC will release soon a new way to manage most of the applet features…. without the applet.

    I liked your post, Andrey. Thanks for sharing.


  2. So many painful topics in just one comment …

    1. 1. I have no idea who does use ACS – in all our webtop deployments the first thing we do is disable ACS transfer. Why? The considerations are following:
      1. 1.1 JMS is an additional point of failure – I prefer do not use lifecycles, I do not code docbase methods, so in all our installations JMS do only two things: workflow processing and job methods. This means that in my case JMS failure does not cause a loss of service – try to turn off JMS in D2 installation and you get a lot of errors in web interface. Actually I use lifecycles, but all code is executed on webtop:
        private static void attachPolicy(IDfSysObject sysObject,
                IDfPolicy pObj, String stateName) throws DfException {
            IDfSession session = sysObject.getSession();
            int stateIndex = pObj.getStateIndex(stateName);
            if (stateIndex < 0) {
            IDfLifecycleUserAction userAction = getUserAction(session, pObj,
            if (userAction != null) {
                userAction.userAction(sysObject, session.getLoginUserName(),
            ((ISysObjectInternal) sysObject).setPolicyInfo(pObj.getObjectId(),
                    stateIndex, -1, sysObject.getAliasSetId(), true);
        private static IDfLifecycleUserAction getUserAction(IDfSession session,
                IDfPolicy policyObj, String stateName) throws DfException {
            int stateIndex = policyObj.getStateIndex(stateName);
            if (stateIndex < 0) {
                return null;
            if (stateIndex >= policyObj.getUserActionServiceCount()) {
                return null;
            String userService = policyObj.getUserActionService(stateIndex);
            if (StringUtils.isBlank(userService)) {
                return null;
            return instantiateService(IDfLifecycleUserAction.class, userService,
        private static <T> T instantiateService(Class<T> cls, String serviceName,
                IDfSession session) throws DfException {
            IDfModuleDescriptor desc = ClientXUtils.getModuleDescriptor(
                    serviceName, session);
            if ((desc != null)
                    && (SBO_MODULE_TYPE.equals(desc.getCategory().getName()))) {
                return ClientXUtils.getService(cls, serviceName,
            return ClientXUtils.getModule(cls, serviceName, session);
      2. 1.2 by default ACS installation is not firewall/proxy-friendly, so it requires additional configuration
      3. 1.3 exposing JMS to end-users is insecure, some examples: ESA-2014-057, CVE-2014-0622, CVE-2012-0874, etc (there is also pending issue related to arbitrary code execution on JMS)
      4. 1.4 I bet you know, that ACS tries to solve “double content transfer problem” (webtop transfers files from CS to temporary directory and then sends them to client), but this problem seems to be contrived – the root cause is webtop developers do not know about DFC capabilities.
    2. 2. HTML5 is not a panacea – UCF currently provides some very useful capabilities:
      1. 2.1 checkin/checkout operations in webtop are “seamless”: user does not care about naming convention, he shouldn’t choose a target directory for checked out files, also he should not choose files to upload during checkin. I tried to play a little with alfresco – I would prefer to use webdav rather than alfresco interface.
      2. 2.2 UCF allows you to control (get know) whether user opened file or not – sometimes it’s required


  3. Excellent article.. But can you please elaborate on the alias naming convention.


    Do i have to use deploymentusercert$tsflaf$loc and give the url of documentum webtop url and the docbase url as well exactly the same way you have done.

    Thanks in advance


  4. You know, six month ago after initial publication it is hard to say what did I really mean under “note naming convention of certificate alias” 🙂 But fact that the main idea of new security model in JRE is “we do not trust standalone certificates anymore, instead of that we want to bind specific certificates to specific sites” and the fact that I specially highlighted that naming convention makes sense make me sure that naming convention does make sense 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s