Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Field Level Authorizations on SAP ECC - UI front end

Former Member
0 Kudos

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

  • Group those similar fields together based on properties/usage and maintain a table with this grouping
  • Create a custom Auth object with ACTVT and the FIELD GROUP NAME and  control the fields whether they are display or non-display
  • Our UI5 team will be able to read this custom object for the user's authorizations and render it on the web front end.

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

1 ACCEPTED SOLUTION

mvoros
Active Contributor
0 Kudos

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

3 REPLIES 3

mvoros
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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?

mvoros
Active Contributor
0 Kudos

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.