• State Verified Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 96 subscribers
  • Views 1157 views
  • Users 0 members are here
Options
Related

Invoking a Script over REST-API with admin permissions

martin ehlert
over 2 years ago

Hello everyone,

I try to invoke a script on the Rest-API with administrative permissions for the script and not the permissions of the user.

The idea is, that users can only communicate with a published Script API but cannot change objects in Identity Manager over the other generic REST methods.

In this way, it would be possible i.e. to write setter on attributes, but only set this value, if it is not filled yet.

Or to force the user to use a transaction instead of 3 separated calls for single objects. 

Is this possible with some annotation in the script or similar?

Thank you

Parents
  • +1 over 2 years ago

    The objectlayer supports only set of permissions at a time, which combine REST-script-access and underlying database permissions. The design principle is: If a user can do it via script, it can also be done via the "low-level" objectlayer. For the script to do anything sensible, you will need to give the user access to some data. This will then be available via the standard endpoints.

    I can see the following ways:

    • provide the minimal set of table premissions, with appropriate conditions, so that it does not matter if it is done via script or low-level calls. This might include template, table- and formatscripts to ensure data integriy checks
    • an option might be to only provide minimal permissons to insert a job. But you will loose the ability to give a sensible synchronous reply
    • you can have a wrapper script callable from outside, which then internally calls the real script using internal, elevated credentials
    • You might be able to provide dedicated views or statging tables for the script to work on. 
    • You might be able to use the API-server (from the Angular-WF). Permisision issue is the same, but the low-level functions may not be exposed. (I'm not too knowledgable about that yet)
  • 0 over 2 years ago in reply to Klaus Müller

    Hi Klaus,

    thank you very much. Similar thoughts have crossed my mind and this makes all sense to me.

    The overhead with middleware/wrapping services is for my case too much overhead/implementation effort, because the invokers are all in my own company, so I trust them to a certain level :) . 

    In this case I set the minimal permissions needed fot the action and use the good old "security through obsucurity" idea. The end user just don´t knows how the tables and columns in One Identity Manager are named and hopefully does not use the generic calls or at least asks before doing so.

Reply
  • 0 over 2 years ago in reply to Klaus Müller

    Hi Klaus,

    thank you very much. Similar thoughts have crossed my mind and this makes all sense to me.

    The overhead with middleware/wrapping services is for my case too much overhead/implementation effort, because the invokers are all in my own company, so I trust them to a certain level :) . 

    In this case I set the minimal permissions needed fot the action and use the good old "security through obsucurity" idea. The end user just don´t knows how the tables and columns in One Identity Manager are named and hopefully does not use the generic calls or at least asks before doing so.

Children
No Data