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.
- Developing restrictions.
- 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 ~~~
- SAP Managed Tags:
20 Comments
