Learn how to increase the operational efficiency of the assets you manage, and improve overall equipment effectiveness by using IoT data and AI.



Reduce the operational costs of the facilities you manage, and create more engaging occupant experiences through the application of IoT data and AI.



Learn how IoT data and AI are being applied to transform the end-to-end engineering lifecycle.

Expand all | Collapse all

Exposing Maximo to public url

  • 1.  Exposing Maximo to public url

    Posted Thu July 16, 2020 01:50 PM
    We are trying to figure out approach for exposing our existing Maximo environment to public url so that it can be accessed outside the org network. Maximo (v7.6.0) infrastructure is on premise with physical servers. We understand the high level approach could be as below.
    - With the help of ISP get a public IP.
    - Use route mechanism to translate public ip into private ip (dns name for maximo)

    I feel that there would be some steps to enhance the security since the app is exposed to public.
    Any suggestion for above/alternate approach?



  • 2.  RE: Exposing Maximo to public url

    Posted Fri July 17, 2020 03:24 AM
    Edited by Kevyn Williams Fri July 17, 2020 03:33 AM
    You should also consider if your SSL/TLS settings - these can be updated in the httpd.conf file if you're using IBM HTTP Server (IHS). At minimum you should be enabling TLS 1.2 only, and disabling all others, but you should also ensure you are using a secure cipher suite too. Something like this (please test first!):

    	SSLProtocolEnable TLSv12
    	SSLProtocolDisable SSLv2 SSLv3 TLSv1 TLSv11
    	#Prefer ECDHE-RSA ciphers
            SSLCipherSpec ALL NONE
            SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
            SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
            SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
            SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384​

    Kevyn Williams

  • 3.  RE: Exposing Maximo to public url

    Posted Fri July 17, 2020 09:34 AM
    Agreed with @Kevyn Williams. Also, you should consider securing attachments and disabling the default login for integrations.
    • mxe.doclink.securedAttachment: This will serve the attachments via servlet, requiring authentication before allowing the document to be served.
    • This will prevent default unauthenticated access via the integration framework.


    Alex Walter

  • 4.  RE: Exposing Maximo to public url

    Posted Fri July 17, 2020 08:56 AM
    Most of what should go into securing Maximo would fall under standard security for any web application.

    First and foremost, SSL is critical. If you're not using SSL with a certificate issued by a trusted certificate authority, that should be your first step (even on-premises). SSL should also be required with a redirect (not a rewrite) from HTTP to HTTPS to avoid users accidentally transmitting sensitive information in plain text. You'd be surprised how often users type http when providing the URL and it defeats the purpose of having a SSL certificate if they're allowed to use it. Disabling it entirely often has negative side effects (users think the application is down) which is why we leave it on but do a permanent redirect (301) to the same URL with https.

    As Kevyn mentions, restricting it to the most secure protocols & ciphers you can is good. Anyone utilizing modern browsers or clients should not have an issue with TLS 1.2. NOTE: WebSphere 8.5 doesn't utilize TLS 1.2 out of box for outbound connections but can be configured to do so. 

    Also relevant whether on-premises or not, ensure your application server only has access to other internal systems on ports it needs and nothing else. Its purpose is to serve the Maximo application, and anything not required for that shouldn't be allowed. That means for example you should have connectivity to your database server on its specific port (such as 1521 for Oracle or 1433 for SQL Server), but you should not have access to the database server on any other port (such as RDP) or access to any other database servers. By restricting communication on your internal network you can minimize the ability for a malicious actor to compromise other systems. 

    It seems like you're planning it already based on your message, but the next thing is to ensure you don't give a public IP to your actual application server. This should be routed through a load balancer of some sort (ideally also look at intrusion detection/prevention options). You want to minimize things that operate outside of the DMZ to minimize your attack surface and help ensure that some sort of mistaken configuration on the application server (such as opening the RDP port) isn't accidentally exposed publicly.

    There are quite a few more things that can be done, but that's my high level for general web applications. Then some specific Maximo things to be aware of:

    Ensure that your SOAP web services are secured. By default, these were NOT secured if using native authentication. Restrictions can be configured either via a system property in newer versions or by modifying the ejb-jar.xml. See here:

    Ensure you're using secured attachments for doclinks and not exposing them via the web server (IIS or IBM HTTP Server). For a very long time, IBM has supported the concept of secured attachments but we still see quite a few Maximo customers who weren't using it on-premises. The Maximo system property mxe.doclink.securedAttachment tells Maximo to use secured attachments. You also need to disable if using secured attachments. What this does is generates a one-time link inside of Maximo to access the attachment file, which ensures security restrictions are enforced. When using the web server to serve doclinks, anyone who has access to the URL can access the attachment which is especially problematic when your Maximo system is publicly exposed but should be configured on-premises as well.

    Consider utilizing SAML/OpenID Connect instead of Native/LDAP authentication. Maximo has supported native authentication (username/password managed inside of Maximo) & LDAP (most commonly Active Directory) for a long time. LDAP is an improvement over native authentication because the password is centrally managed, but neither are extremely secure because it still consists of only a username & password. If you configure your Maximo system to use SAML/OpenID Connect, these identity providers have much stronger security controls including requiring 2 factor authentication. Most even have controls to conditionally require additional validation or prevent access depending on where the system is being accessed. This isn't a simple flip of a switch as you have to evaluate integrations and third party products you depend on, but can greatly improve security. 

    Consider enabling object structure security. Similar to above, this requires review, but can greatly improve security if someone is able to compromise a username/password. Maximo before allowed users to do quite a bit with object structures if they had a valid username/password. Most object structures out of box weren't even restricted to an application (meaning any authenticated users could use them), but even those that were restricted to an app could allow way more users use it than intended. Now you can configure it at the object structure level which ensures that only groups that should be able to utilize that object structure are allowed. If you enable system property this will prevent users from utilizing any object structure that doesn't have security configured. This requires Maximo, but should be considered.

    The least popular thing, but the most important thing, is to stay current with the software. That includes the middleware components, but I'm going to focus mostly on Maximo as a lot of customers like to leave it alone unless something is broken. Maximo like any software product has defects. Waiting years to patch the product means that vulnerabilities that exist in the product are potentially exposed to the world to exploit. I won't cover the specific vulnerability, but there was a serious issue in that could be used to access data in the system without authentication. Staying informed about issues identified, and coming up with at a minimum mitigation strategies, but ideally a strong patching strategy, is an important aspect to running an application. This only becomes more pronounced when the application is exposed publicly. This is not to say that you must take every patch and apply it within weeks of the release like you would for an Operating System patch. It's more about staying informed so you can make the right decision for your organization.

    Steven Shull
    Director of Development
    Projetech Inc
    Cincinnati OH

  • 5.  RE: Exposing Maximo to public url

    Posted Thu July 23, 2020 09:11 AM
    Aakash, thank you for posting this question. It's been very helpful.

    And thanks to Kevyn, Alex, and Steven for your answers. The content in your replies will save me from a lot of headaches/risks/issues down the road.



  • 6.  RE: Exposing Maximo to public url

    Posted Thu July 23, 2020 05:08 PM
    Thanks everyone for the detailed information.

    Aakash Saxena