Instance Based Access Control

[Former Member]

Hello folks,

Hope you are doing great.

It's been so long since I last blogged and thought of dropping one now.

And the topic I chose is "Instance Based Access Control". Even though this concept is already there for so long, there are very few discussions on this. Perhaps this is not being much used in development but the question is, are we aware of the fact that studio supports something like this in first place ???

According to me, this is a very important and useful feature that every customer loves to have.

So, lets get into the details now.

---

Scenario Selection:

Next step would be to decide what exactly am I doing here? :???:

Since I am bored seeing the example listed in the documentation for more than 3yrs for now, I am gonna cite a scenario of my own which I feel may be most wanted in projects, which is...

" An employee should only see the data he created. "

Before I proceed, I just want to highlight that the whole process can be divided into two steps.

1. Developing restrictions.
2. Assign access rights.
   

Let's discuss more on this now.

---

Step 1: Developing restrictions.

• Before you get confused with terminologies, let me make it clear that we are not going to actually "develop" any restriction here, its just that we are gonna use the existing restrictions which come with standard Business Objects.
• There are lot of standard Business Objects with an Access Context tagged to it which is nothing but the base for restriction.
• This information is available in Business Object explorer of Repository Explorer.
• The magic is to link to these standard BOs in your custom BOs with an association defined with specific annotation as this will not be a normal association anymore and used for a specific purpose.

That's all about it.

If you did get what I said, rest of the steps are just piece of cake for you.

• Considering our scenario now, since we don't want an employee to see other employee's records, its pretty clear that the restriction is on Employee.
• Next step would be selecting the appropriate Access Context which helps in my scenario and I fixed my mind to use 1000 - Employee Self Service
• So, let's get that Employee restriction now. I searched in Repository Explorer and found that Employee BO has the Access Context I want.

We are good to go..!

We have all the info in hand and so, let's start creating custom BusinessObject now.

I will create a custom BO with name "AccessControlObj" and the definition will be as shown below:

import AP.Common.GDT as apCommonGDT;

import AP.FO.BusinessPartner.Global;

businessobject AccessControlObj {

  element Employee:EmployeeID;

  element Consistent:ConsistencyStatusCode;

  [RelevantForAccessControl] association For_Access_Control to Employee;

}

Also, create screens using navigation.

Keypoints:

• Above definition has minimal set of elements which are needed for this experiment.
• [RelevantForAccessControl] is the annotation which is to be used to link association with standard objects to inherit the Access Context for your custom Business Object.
• We still didn't specify in anyway that we need Employee level restriction. So, hang on right there as we have lot more to discuss !!!

We need to create a BO Query for our custom object as there is something called ACL (Access Control List) data which will be carried only by Fast Search Index (FSI) BO query. Don't ask me "why not with default BO query?" 

Lets follow guidelines for now and flow with self experiments later. Here's the snap of the BO Query, Overview.qry I created.

NOTE: Not that I should tell but just as a tip, don't forget to activate your custom BO once done.

Let's talk more about this association now.

The question is what exactly is the base for filling association anyway?

Our association links to Employee BO meaning that every custom BO instance should have this association linked with the creator (employee) of that instance so that we can use it for restricting later on.

Stop here and ask yourself...

• Am I clear till now?
• Am I clear till now?
• Am I clear till now?

If you get Yes as an answer for all three times, then proceed with my explanation or else start from where you are lost.

We need something that can be used for filtering instances here. We are using an association relevant for access control which will be used against ACL data of BO Query we created.

Now comes the interesting part of writing code for filling our association. Create BeforeSave script for your custom BO and fill in something like this.

import ABSL;

import AP.FO.BusinessPartner.Global;

import AP.PC.IdentityManagement.Global;

if( ! this.For_Access_Control.IsSet()){

  var currUUID = Identity.Retrieve(Context.GetCurrentIdentityUUID());

  if(currUUID.IsSet()){

       var q = Employee.QueryByIdentification;

       var q_selparams = q.CreateSelectionParams();

       q_selparams.Add(q.UUID.content,"I","EQ",currUUID.BusinessPartnerUUID.content);

       var q_res = q.Execute(q_selparams);

       foreach(var emp_ins in q_res){

            this.For_Access_Control = emp_ins;

       }

  }

  if(this.For_Access_Control.IsSet()){

       this.Consistent = "3"; // Consistent

       this.Employee.content = this.For_Access_Control.IdentificationEmployeeID.EmployeeID.content;

  }

  else{

       this.Consistent = "2"; // Inconsistent

  }

}

All coding related part is done. We are good to proceed with UI Designer related enhancements now.

OWL changes:

Open OWL of custom BO now to change the query to the BO query you created in the earlier step.

• Query section under Controller tab should look like this,

• Binding under DataModel tab should look like this,

• You can see that we didn't bring the association into DataModel as ACL is an instance level feature. Save and Activate

QC/TI/TT changes:

Open these screens and change Properties as shown below under RBAMData,

• Change the Access Check Mode to "PrivilegedExceptAccessControlBusinesssObjects"
• Set Authorization Classification Code to "Application"
• Select Access Controlled Business Object and make sure you see your object having Unrestricted Access unchecked.
• Save and Activate

WC view changes:

• Open the custom wc view and change the AccessContextCode under RBAMData to the one we need which is "1000 - Employee Self Service" as shown below:

• At this point, you might wanna check if all your linked UIs are assigned to your wc view by clicking on AssignedObjects

We have successfully completed Step 1.

---

Step 2: Assign access rights.

It's time to test finally..! Whew! :grin:

Pick two BusinessUsers to test. I am gonna go with ATROCKSTAR01 and ATROCKSTAR02

Common task for both users is to assign your custom work center view.

Once you are done with that, look at the part of setting access restrictions now for both users.

I just opened for ATRock Star1 and I see the below restriction set automatically (This is NOT an auto assignment for all AccessContexts.)

You will see the same for ATRock Star2 as well.

Ok. That should be enough for time being. Lets test it now.

Login as ATROCKSTAR01 and create one instance in the custom wc view as shown below.

Once you are done, log off.

Login as ATROCKSTAR02 and now, you will not see the instance created by ATROCKSTAR01.

So, go ahead and create an instance as shown below.

Just a rain check...

Let's get back to Cloud Studio and query your CustomBO as shown below.

You should get two instances.

This functionality is called Instance Based Access Control.

---

TIP: If you are using any other Access Context, it is possible to set dynamic rules if you assign Access Restriction from a Business Role through Restriction Rule as shown below.

---

Troubleshooting: Sometimes, this feature may not work as soon as we setup everything. In our example, we took instances of ATROCKSTAR1 and ATROCKSTAR2. It may happen that an employee may see other employee's records regardless of whatever access restriction you set for your custom workcenter view.

Cause: Whenever you set some access restriction to your wc view and activate it, RBAM policies are generated for that view. In the case where it doesn't get generated, then this functionality will not work in runtime when you test it.

There is no option from studio to generate these policies. Ideally, RBAM policies are generated when the UI model is generated. Hence when you deploy and activate a solution it will be triggered. The generation itself happens as an asynchronous job in the backend. So, sometimes it may take a fortnight. If the generation is incomplete, then you will see this functionality isn't working. You should raise an incident in this case.

---

vatsav

~~~ End of Blog ~~~

[Former Member]

Hi Vatsav

Good to have you back at SCN :wink: .

A great Blog as always. Thanks

Asad

[former_member200567]

Thanks,

Really helpful and easily understandable.

And thanks for the detail and explanation.

Looking forward to your next blogs.

Fred.

[Former Member]

Hi Vatsav,

Thanks for your blog entry.

I have one question:

Where can I look up which access contexts sipport which business objects?

In the Rpeository explorer I can look it up the other way around.

I have the requirement to restict user access based on the permanent establishment which they are associated with.

Best regards,

Ludger

[Former Member]

Ledger,

Select any standard BO from RepositoryExplorer and if that BO supports any AccessContext, then you will be able to see in its detail as shown below.

[Jacques-Antoine]

As usual, this a gold mine!

Thank you so much Vatsav!

Best regards!

[Jacques-Antoine]

Hello Vatsav,

I would like to try to implement this solution on my test tenant, so as to have the user only have access to the projects they have a participation in.

If I play with the 1002-Project Participation access context, will this also filter the reports created from Project Management so that the user only have access to the relevant reports?

[HorstSchaude]

Hello Vatsav.

I would like to turn your attention to the new annotation AccessControlContext which is available since 1405.

It can be applied the keywords element and association if the type of the element resp. the Alternative Key is UUID.

This annotation competes with the above mentioned annotation RelevantForAccessControl. Both cannot be used in the same Business Object defintion together. 

Whereas the annotation RelevantForAccessControl reuses the ACL of the target of the association (Therefore you need to find a Business Objects with an access control context that suits your requirement as described above) the annotation AccessControlContext uses the value of the element / association itself. :smile:

So if you define an element like this

     [AccessControlContext(Employee)] element EmployeeUUID : UUID;

you can use this ABSL snippet to fill the element

import AP.PC.IdentityManagement.Global;

// Determine own Employee UUID

if (this.EmployeeUUID.IsInitial() == true) {

   var myIdentity = Identity.Retrieve(Context.GetCurrentIdentityUUID());

    this.EmployeeUUID = myIdentity.Person.UUID;

      }

All the other steps mentioned above are the same from here on except that the new annotation suppports only

• 1010      Employee
• 1015      Employee or Territory.

This makes a definition of an association like this possible

    [AccessControlContext(EmployeeOrTerritory)] association ToSite to AP.FO.MOM.Global:Company;

I believe this makes the definition and the setting of the correct values for instance based access control much more easier than the old annotation.

Reg. that there are only 2 access contexts available now, it is just the start. :wink:

If more access contexts are required please request them from SAP.

HTH,

    Horst

[rajiv_juarbal]

Thanks Vatsav for this blog, I already resolved my issue on this matter, it was just a matter of test users to use.

Regards,

Rajiv

[Former Member]

Hello Vatsav,

is it possible to give multiple employees the right to access the BO?

This would correspond to an [0,n] association of the access control.

In my case, multiple employees should have the right to view a custom BO; the rights should be granted by a rights administration which fills the associations.

Thanks for your help in advance!

Markus

[HorstSchaude]

Hello all,

With the release 1611 the Cloud4Customer can use additionlay the context "SalesOrganization".

We enhanced the code completion to provide also the information about the value in the UIs. 🙂

Bye,
Horst

[former_member182606]

Hi Experts,

Is it possible to restrict a custom business object data between employees and their managers. I mean only the employees manager should be able ale to see all the records created by is team members assigned in the Org.

I used above steps in the Blog and was only able to restrict it among the employees only. So the managers cannot access it too. How to allow the manager to access the data created by this team ?

 

Regards,

Chella.

[Former Member]

Hi Hortst,

If I choose this way to control access,do I need to fill in the AccessControlCode in UI designer and to do some config in UI designer like this blog?

Thanks & Regards

[HorstSchaude]

Hello Baoxiang,

Simple answer: Yes.

The main difference is that you define by yourself whet the access relevant information is.

HTH,
.   Horst

[Former Member]

Hi Experts,

I have 3 Queries.

My CustomObjects,

My Team CustomObjects,

All CustomObjects,

I want to apply Access Control  in My Team CustomObject  with criteria to Owner = current user or employee reporting directly or indirectly to current user.

If I use Access control for  Employee I am seeing below options.

 

1000 -Employee Self Service

1007 -Company

1003 -Management

2004 -Partner

2008 -Org. Unit

 

How to achieve my requirement.

Thanks & Regards,

Niranjan Patel

 

[Former Member]

 

Hi Pandian,

 

Are you getting your answer?

 

Thanks & Regards,

Niranjan Patel

[former_member182606]

Sorry Mate I was not able to achieve it yet. Then we changed the requirement. I was only able to restrict it between ( 2008 -Org. Unit ).

[former_member597274]

Hi Horst,

 

Thanks for this update.

I have a question: this solution works only for custom BO, is it possible to do the same for a standard BO?? for example I want the employee to see only the orders that he created…

 

Kind regards,

Rami Alwafaie

[HorstSchaude]

 

Hello Rami,

It is not possible to overrule the SAP delivered access control.

Either you are bale to do this with the available access context or you create your own access controller BO which models the access context and points to the resp. targets.

HTH,
.    Horst

[former_member611425]

Hi Horst,

 

Does [AccessControlContext] annotation work with SADL query?

Also, does it apply to existing instances or only for the newly created ones?

Thank you in advance!

 

Kind regards,

Timea

 

[HorstSchaude]

Hello Timea,

It works with the SADL queries created via the QueryBuilder, but not with the SADL queries from the UI Designer.

The reason is the later ones have no correspondence in the backend runtime, only in the UI runtime.

HTH,
.    Horst