02-06-2014 11:56 PM
Hello Security Gurus -
Before I start with my question - here's a lil background.
We are on EHP7 for SAP ERP 6.0 with release 740 SP level 0004, SAP_UI 740 SP level 0005.
We have a very peculiar requirement for Field level authorizations on SAP UI5. End users will not have access to SAP GUI, they will all logon to SAP via the web browser ONLY (All these screens are developed using the SAP's UI5 technology).
Now the questions is How can we implement field level security in the ABAP back end system that can reflect on the UI front end?
Our approach/idea is to
However, with this approach we may end up with a huge table with all the available fields and grouping them together would be a big challenge and a huge maintenance overhead.
Does anyone know if there is a better approach to attain this level of security? Any valuable thoughts,ideas you could share would be highly appreciable.
Thanks for your time
Kiran Kumar
02-07-2014 12:18 AM
Hi,
you probably already understand this but I want to put stress on this. In case of UI5 you can't trust client. So for example if you a have a service that gives you PO details and it is consumed by UI5. You want to hide some fields (e.g. pricing) based on user's authorization. You can't send all data to client and then hide some fields based on user's authorization in UI5. You have filter out data in backend service if a user does not have authorization for them. Same is true for authorization checks for various activities. So your UI5 team should read info about user's authorization to hide the fields/buttons that are not available for a user, But even if they don't do it the user won't see any values in these fields because the backend service won't send any data.
Regarding your original question. If you want to have a really granular access control then you have to pay for it. There is no magic trick to avoid this. You can split your fields into multiple groups and assume that if field does not have a group then it's displayed to every users regardless authorization. This should minimize number of records. Also lower number of groups means less maintenance.
Cheers
02-07-2014 12:18 AM
Hi,
you probably already understand this but I want to put stress on this. In case of UI5 you can't trust client. So for example if you a have a service that gives you PO details and it is consumed by UI5. You want to hide some fields (e.g. pricing) based on user's authorization. You can't send all data to client and then hide some fields based on user's authorization in UI5. You have filter out data in backend service if a user does not have authorization for them. Same is true for authorization checks for various activities. So your UI5 team should read info about user's authorization to hide the fields/buttons that are not available for a user, But even if they don't do it the user won't see any values in these fields because the backend service won't send any data.
Regarding your original question. If you want to have a really granular access control then you have to pay for it. There is no magic trick to avoid this. You can split your fields into multiple groups and assume that if field does not have a group then it's displayed to every users regardless authorization. This should minimize number of records. Also lower number of groups means less maintenance.
Cheers
02-07-2014 1:09 AM
Thanks for the fast response and your valuable suggestions!
Yes, we did think about your first concern, so our approach is to have an additional rule layer(BRF+ or DSM rests on the same back-end system as the user and gateway). BRF+ will act a filter and send only those fields (that a user is authorized to) to the gateway service, which is consumed by UI5.
Coming to my question - what are the options if we pay?
02-07-2014 1:18 AM
Hi,
by paying I meant you will have to maintain granular control. So more complex control for access will require more effort to maintain it. It's same as with SAP security roles. If you have low number of roles and no exceptions then maintenance is much easier than when you have a unique role for each user. I am not aware of any commercial solution that would solve your problem.