Throttle and / or Block a users Rest API connection from third party apps.

[Steve Rowe]

Hi,

Is anyone aware of a method of blocking or throttling an end users rest api connections from third party applications?

Consider the following scenario
User is set-up in a TM1 DB with read write access to the DB as part of their normal day to day activity.

They are also competent with the Rest APIs in general.

Is there any security method available that would block the access from an external Rest API source whilst preserving that users native TM1 access?

This could be achieved by setting the fire wall up on the PAW machine to not allow connections from the IP of the third party app but if this is running on the users machine then this would block their TM1 access too.

Another question, which is probably an order of magnitude harder, are there methods that could be applied at the TM1 DB / PAW side that would limit the volume of transactions that this user could process.

Cheers!

[lotsaram]

I think the answer is "not really". As far as the server is concerned it is all Rest API and all treated equally.

In the http header you can include client information for the session. This is useful in monitoring to identify that a session is PAW, vs Arc, tm1Py, Apliqo UX, etc. In theory you could write a monitoring application that would kill threads that aren't from "appproved clients" ...
BUT
- many rest requests are in and out too fast for an external monitoring app to recognize and terminate them
- you can program yopur app to write anythgin you want as the client id in the header. So my connection cound say "Workspace" even though it is a custom tm1py app

[Steve Rowe]

Thanks Lotsa,
That's what I figured, unless IBM put some controls into the security layer there is no way to manage access from third party apps.

Except for managing in the firewall which isn't going to work in all circumstances.

All this openness is great until you don't want it! Time for an RFE....

[scrumthing]

I must admit I don't see how IBM could limit that. As lotsaram pointed out you could put anything in the header.

If you have users with such bad intentions limit their general access to the database. Make sure they can only have 1 connection at a time.

I must admit that right now I am not 100% sure how the traffic is routed when they connect via PAW and via PAfE. Both need a connection to the workspace server but are they afterwards connect directly to TM1? If not, you could easily limit the port access from the users local machine. But maybe I am wrong and you already ruled that out.

[Steve Rowe]

Yes, I think it's a tricky problem too.

I don't think users can be set with a single connection, I think this breaks PAW as a connection is required for each widget?

Just for clarity this isn't about users having bad intentions or being malicious in anyway, the users wish to go in a particular direction because its the most conveient for them. From the IT / TM1 owners side it is about control and a "trust but verify" approach to the security and integrity of the data.

In this organisation TM1 is the trusted source for "Dataset A". There are a large group of users (~30) who are skilled technically and have a preference for using the data in a third party application.

For a long list of reasons from control and security (i.e. how do we know the users of your third party app are following correct security) to business process (i.e. at the moment TM1 is the end point for the data so change control is less restrictive) the TM1 Owners wish to able to control this access route.

If you were able, as a minimum, to specify what headers can be used for each client then you can then control the access. This is a start, the fact that the headers can be spoofed is important but if users do that then they are in "bad intentions / malicious" place which would put jobs and careers at risk. This isn't really an InfoSec issue for the customer, it is a control issue.

Open access and the rest api is great but it should be able to be managed as well.

I do have a wider concern that this seems to be genuine hole from an InfoSec point of view, it would be extremely difficult / impossible to check if a user who has legitimate access to TM1 was using the RestAPI to pull data and sitting outside of the planning analytics infrastructure.

[Adam]

I do have a wider concern that this seems to be genuine hole from an InfoSec point of view, it would be extremely difficult / impossible to check if a user who has legitimate access to TM1 was using the RestAPI to pull data and sitting outside of the planning analytics infrastructure.

Nefarious users will find a way regardless of limitations.

May I ask more of a process question? If the concern is data traveling to outside of TM1, how would you practically prevent someone from taking data in Excel files elsewhere?

[ykud]

In this organisation TM1 is the trusted source for "Dataset A". There are a large group of users (~30) who are skilled technically and have a preference for using the data in a third party application.

For a long list of reasons from control and security (i.e. how do we know the users of your third party app are following correct security) to business process (i.e. at the moment TM1 is the end point for the data so change control is less restrictive) the TM1 Owners wish to able to control this access route.

If you were able, as a minimum, to specify what headers can be used for each client then you can then control the access. This is a start, the fact that the headers can be spoofed is important but if users do that then they are in "bad intentions / malicious" place which would put jobs and careers at risk. This isn't really an InfoSec issue for the customer, it is a control issue.

Put a reverse proxy that accepts the requests from the third party application and routes them to PA and expose only that proxy to third-party instead of PA server (essentially this proxy is your DMZ boundary). Then you can do filtering on the headers, source IPs, number of requests, traffic logging to your hearts content, all proxy servers have such capabilities

[Steve Rowe]

Hi Adam, Ykud,
Thanks for responding.

Put a reverse proxy that accepts the requests from the third party application and routes them to PA and expose only that proxy to third-party instead of PA server (essentially this proxy is your DMZ boundary). Then you can do filtering on the headers, source IPs, number of requests, traffic logging to your hearts content, all proxy servers have such capabilities

I guess combining this with blocking the path from the third party app to PA or TM1 (the app in question talks directly to TM1) would force the traffic through the proxy. Conceptually this works but requires significant (?) effort and a skill set that isn't traditionally assocaited with TM1. This would also give the full set of metrics on the activity.

I still feel that something that allowed access according to the header at the user level that was native to TM1, would get us 75% of the way there in a pretty simple manner. Easy to say of course.

May I ask more of a process question? If the concern is data traveling to outside of TM1, how would you practically prevent someone from taking data in Excel files elsewhere?

At face value you are right the user can't do anything that they can't do anyway. This is really a Big Corporate control, process and infrastructure problem not a concern about a single user doing something wrong security wise. A group of users want to do something, IT don't want to allow them to do it but can't enforce or monitor it.

Cheers,

[ykud]

I guess combining this with blocking the path from the third party app to PA or TM1 (the app in question talks directly to TM1) would force the traffic through the proxy. Conceptually this works but requires significant (?) effort and a skill set that isn't traditionally assocaited with TM1. This would also give the full set of metrics on the activity.

Hm, IIS has a reverse proxy module as well and you're probably setting it up for Cognos Analytics already? It a lot simpler than the big words make it look.