0

Is there standard way to change runtime permissions for a user to be able to call certain odata resources of a SAP gateway service, other than manually writing code in every service implementation method to check if the request is allowed?

For example, based on some setting in customizing, the odata paths below /foo and /bar for user x should be forbidden, i.e. HTTP GET/POST/DELETE <host>:<port>/foo/test and HTTP GET/POST/DELETE <host>:<port>/bar/test should yield HTTP 403 for user x, but HTTP GET/POST/DELETE <host>:<port>/something should be OK.

Is there a way where this can be controlled at a single place rather than being required to implement a check in every method implementing the odata requests?

Boghyon Hoffmann
  • 17,103
  • 12
  • 72
  • 170
Sebastian B.
  • 287
  • 4
  • 19

1 Answers1

2

The proper place for the authorization check is in the backend method. Any authorization error should populate back to the service and yield a 403 for example.

If you for some reason don't want that, you could write your own HTTP handler and insert it in SICF to be called on all paths.

The standard role setup only allows access or no access to a service, the "pattern" access you are referring to is missing. But I can't really understand why you would want it? It will make your Odata services kind of un-predictable for the consumer, wouldn't it?

Mikael G
  • 712
  • 5
  • 13
  • Assume you would like to deactivate a set of functions for a set of users. Coding that check into every odata method implementing a request is kind if hideous isn't it? Especially since you would need to add it everytime you add a new odata path as well. – Sebastian B. Aug 16 '15 at 17:23
  • I would still put the authorization check in my backend method. It should be executed there anywhere before any actions that changes data. If I want to deactivate access I'd do it on the service level by removing the service from the Gateway role assigned to the user. Your request for something configurable could be implemented by adding a custom HTTP handler to the Odata node. This handler could read a configuration table with paths. Then you won't need to do any changes at all in your Odata methods. – Mikael G Aug 17 '15 at 10:36
  • 1
    Look into adding a HTTP handler and then controlling the flow: http://help.sap.com/saphelp_nw70/helpdata/en/78/98529cc06b11d4ad310000e83539c3/content.htm – Mikael G Aug 17 '15 at 10:36
  • I haven't tried doing a user-specific URL filter via Web Dispatcher or ICM, but maybe it can give you some ideas. http://help.sap.com/saphelp_nw74/helpdata/en/48/3edf38c10272d2e10000000a42189c/content.htm – Mikael G Aug 17 '15 at 10:43
  • Flow control would have been an excellent solution. However, I think that SAP Gateway supresses multiple handlers for services below ```/sap/udu/odata/sap/*``` ? I.e. it ignores any handlers other than the default handler ```/IWFND/CL_SODATA_HTTP_HANDLER ```. Is that really the case? It appears my custom handler is never invoked :-( – Sebastian B. Aug 17 '15 at 15:15
  • Haven't tried for that specific service, but in all other cases it has worked without issues. – Mikael G Aug 17 '15 at 16:44