Access contorl - Corporate network access

[aw2215]

Morning,

Does anyone know if it possible to lock down access to our Service Manager instance so its only accessible if you're connected to our corporate network?

Many thanks

Andy

[Gerry]

Hi Andy,

There are no controls to enable this currently. We have been increasingly asked for this capability and we are looking at adding some IP address management and restriction capabilities to an upcoming enterprise edition of the platform.  However, there are problems with restricting by IP address that means its not really fool-proof. 

Without going into chapter and verse, our UI's are served from web servers which we of course control, but we front-end our service using a Caching CDN (Cloudflare) which we have no control over, so we have no way of selectively blocking access to our UI endpoints.  (Please note.... no data flows through the cloud-flare network, only the UI/front end web pages)  The user app, portals and mobile devices all ultimately hit the same Hornbill API endpoint, this is where we would have any such controls enforced.

This means that enabling IP address restrictions you would be severely disabling Hornbill's functionality. DHCP is so prevalent there would be no realistic way of not blocking mobile devices using IP addresses, which is why we use a secure pairing scheme, unless you would only ever want the mobile device to work when you are in your own LAN environment with WiFi enabled.  In terms of the portal, the same thing, it would only work via  VPN, so if you had a home working user who needed to report a problem, say a password reset request, they would no longer have any way to access your portal because they are not emanating from an IP address you have blocked.  However, despite all of that both on the Apple and Google networks, notifications are sent via their respective gateways, so even if you did block the IP address of the phone, they would still receive notifications.  So blocking by IP only has a very specific set of use cases is the main point. 

So perhaps I can answer your question with another question?  What is it you are trying to achieve? or maybe better put what is the business requirement you are trying to meet?

Gerry

 

[nasimg]

Hi @aw2215

One idea that may achieve what you need is to use SSO (single sign on) but ensure your federation servers are not public facing (so only available on your network).

Nasim

[Gerry]

@aw2215

Nasim makes a good point, if you are using SSO, I believe most identity providers will also have controls for this sort of thing, so even if the federated service was public there are most likely administrative controls to restrict access to the service based on IP or other security policy restrictions. 

Good suggestion @nasimg

Gerry

[aw2215]

Hi both,

 

Thanks very much for the responses. We are using SSO, so the federation server idea is something we will look into.

 

Many thanks

Andy

[nasimg]

Hi @aw2215

Andy we have the opposite issue where I'm looking to enable the fed servers to be public so staff can access their tickets anywhere. So I'm sure changing your Fed server to not being public will work (which we do for other customers), only thing you may want to do is check if other applications (eg Office365) need public Fed servers. If this is the case, then just provision new Fed Server that are not public. 

If you add more Fed Servers (while you are testing), your users will get a drop down to select a server when they log on, but they can have friendly names eg. companyname, test - do not use, etc.

Nasim

 

[aw2215]

We have managed to successfully block external access using your proposed method Nasim.

 

Thanks very much for the guidance

 

Andy