2 Replies Latest reply on Dec 6, 2018 11:24 PM by DeWetTheHitmanBarry

    Options on how to expose ISM to 3rd parties?

    DeWetTheHitmanBarry Rookie

      Has anyone explored the different options on how to expose On-Premise ISM to 3rd parties externally?



      We have current and new business requirements whereby we need to " expose " our On-Premise ISM to 3rd parties externally to both push and pull data. This is becoming more and more of a reality with the growing need to accommodate for better integration between On-Premise based solutions and Cloud / Other platforms for external parties.



      As far as I know, there may be 3 x options



      1. Leverage a Cloud based instance which sits between the On-Premise solution and the 3rd party / external

          users. This will be specifically designed and configured to allow for 3rd parties to consume and push data of

          which will  then get synchronized between the Cloud and On-Premise instance.



      2.Explore the option to expose the ISM On-Premise application via the Azure AD application Proxy. This

         particular approach may most likely be the most “ cost “ effective and least effort required as opposed to the

         option 1 to create a complete new Cloud Instance and require less system maintenance and admin. We've

         briefly explored this option internally with a different application though, in this case being Confluence and

         Jira from the Atlassian Stack which largely worked quite well.

      3. Explore the option of " exposing " specifically the Self Service / Mobile Role of ISM to 3rd parties, which

          may reduce the challenge of the licensing costs, this could either be also via the Cloud or Azure proxy

          potentially.  If there is not much complexity with regards to the pushing and consuming of data via the 3rd

          parties then this would be a great option too.



          If anyone perhaps may have already or is currently exploring either of the above or some similar intiatives

          then please let me know as this would be great to share ideas and learnings where possible.

        • 1. Re: Options on how to expose ISM to 3rd parties?
          AlasdairRobertson ITSMMVPGroup

          I am assuming the 3rd party will be providing an analyst style role for the moment, other wise if just logging tickets they would use self service.


          The simplest configuration is your option 2 or NAT/Reverse proxy to the internet from your internal servers.  There is an option to put a web server in a DMZ as well depending on your security rules.  Then I would just give my suppliers domain logins or Azure AD accounts for SSO.  Other alternatives would be to provision your supplier with a VPN so then they are on your network anyway.


          Your option 1 I do not think would be practical, there is the management of the API/interface and the cost of having a cloud tenant as well as a premise tenant.


          Option 3 comes down to what you want the suppliers to do, if you are considering exposing analyst type functions via self service then I would advise reading your license agreement as I understand this not to be allowed.

          1 of 1 people found this helpful
          • 2. Re: Options on how to expose ISM to 3rd parties?
            DeWetTheHitmanBarry Rookie

            Hi Alasdair,


            Thanks and appreciate the detailed feedback that was very helpful.

            Agree 100%, Option 1 is not viable because of the effort, cost, syncing between on-premise and Cloud and maintenance and was the least preferred route.


            Option 2 via Azure platform definitely seems like best approach with the least effort, cost and and quickest time to market.

            Based on your comments we have since explored the Azure approach internally with our Security and Infrastructure team and we will be starting some DEV testing in a week or two.

            This way also means that we do not have issue a company supplied PC whereby users connect then via VPN remotely or them connecting via VPN on their personal PC's as well. Taking this out of the loop

            is great as it means there's less points of failure, maintenance and work required.


            The approach would be to expose our ISM application using the Azure AD Application Proxy publicly and then 3rd parties can access the application remotely.

            We already have this working fine with Confluence, so it would follow a similar route. At this point I don't think we explore the web server in a DMZ route, but that will depend on further discussions later

            from an internal security perspective with regards to Design and Architecture.


            This solution will though cater for secure access via AD authentication and we will also use MFA as well.


            Some challenges we have identified thus far will be around AD accounts i.e. expired passwords or accounts, lock outs  for 3rd party users.

            Also we are not yet sure as to how ISM 2017.3.1 may handle SSO via Azure reverse proxy method which will still need to test.


            If this does in fact work, then we could explore the Self Service role via the same platform, but that may have licensing implications as mentioned. We would prefer not to use the IOS / Android app in future

            but rather the URL approach as I assume that the application may have the logic to distinguish the type of device that is consuming the application i.e. Tablet / Phone etc to the render the UI accordingly.


            Mobiity is something in the pipeline but probably only late next year 2019 at the earliest of which are dependent on the our Infrastrcuture / EUC team to drive internally.