Context Solution
In the modern enterprises, its very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain infotypes (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far.
Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training infotypes and a second one with infotypes needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive infotypes for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile).
The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the corresponding switches should be set to 1. Its also customary to switch off checks(value 0) for the non context authorization objects. The relevant switches are given below
- AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON
- AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON
- AUTSW-NNCON HR:Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.
In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure).
The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below.
P_ORGINCON
| Authorization Field | Long Text |
| INFTY | Infotype |
| SUBTY | Subtype |
| AUTHC | Authorization Level |
| PERSA | Personnel Area |
| PERSG | Employee Group |
| PERSK | Employee Subgroup |
| VDSK 1 | Organizational Key |
| PROFL | Authorization Profile |
P_ORGXXCON
| Authorization Field | Long Text |
| INFTY | Infotype |
| SUBTY | Subtype |
| AUTHC | Authorization Level |
| SACHA | Payroll Administrator |
| SACHP | Master Data Administrator |
| SACHZ | Time Recording Administrator |
| SBMOD | Administrator Group |
| PROFL | Authorization Profile |
You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role.
The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increaded maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.
Hi Aninda,
I have built a PD profile (NEW-ORG) to exclude HR associates from seeing each other’s pay(IT0008), while being granted access to update non HR Associate IT0008 records. It was a tedious process since it involved statically including all ORG UNITS except HR in my OOSP entries with P_ORGINCON maintained as follows: AUTHC=R, IT=0008, PROFL= (NEW-ORG).
So far it seems to work. The only problem is that only current IT0008 records are blocked for fellow HR associates. Historical pay records for former position/org assignments are still visible. From my undersataning of CONTEXT AUTHORIZATION, the system only picks up objects defined by the evaluation path for OBJECTS, in this case OBJ=”P” and grants access in table T77UA. Why does historical assignments still show in T77UA? Is there a way to lock historical IT0008 records from a SECURITY point of view? OR this can only be done through TC PA* access?
Hi Attta,
Some things to think about….
If your PD profile doesn’t include the HR org units then how are you even getting read access to IT0008 of HR associates?
Is there are other authorizations which give access to IT 0008? According to period of responsibility/time logic principles, if you get update access to even a single infotype record for a pernr, you would have read access to all records for the pernr for the same infotype.
Were the offending pernrs ever on a default position? IF your DFCON switch is set to give access to all employees with default positions, you will have read access to all their infotype records.
Regards,
Aninda
Hi Aninda,
These are my P_ORGINCON SET UP:
P_ORGINCON 1
AUTHC–R/W
INFTY–0008
PROFL–NEW-ORG( This PD profile by-passes the HR substructure)
P_ORGINCON 2
AUTHC–R/W
INFTY–0000-0007,0009-0999
PROFL–ALL
P_PERNR
AUTHC–R
INFTY–0008
PSIGN–I
SUBTY–*
DFCON = 4 (NEVER EAVALUATE, GRANT ACCESSS BY DEFAULT). This switch setting allows retirees, Temps and Contractors assigned “99999999” position ID to be accessed…no problem with that.
RESULTS:
1. User can R/W IT0008 for all associates except HR
2. User can R/W all other infotypes for all non associates
3. User can also R/W all infotypes for HR associates except IT0008
4. User, who is also an HR associate is able to see his/her own IT0008 records.
The user cannot see any “current” infotype records of fellow HR associates but user can see “old” records if the the “PERNR” had previously been asigned other responsibilities outside of HR.
QUESTION:
How can I lock access ” from a security point of view” to old infotype records? Is it possible that the user can only access “current” records? I know I can see the LOCK/UNLOCK button in PA* EDIT-> LOCK/UNLOCK but I want the first page eg: “Display HR Master Data” to default to only current year and grey out other periods. Is there a way or can I get help with screen modification?
Hi Atta,
My Answers are below. I don’t think they will help you too much.
RESULTS:
1. User can R/W IT0008 for all associates except HR
2. User can R/W all other infotypes for all non associates
3. User can also R/W all infotypes for HR associates except IT0008
4. User, who is also an HR associate is able to see his/her own IT0008 records.
The user cannot see any “current” infotype records of fellow HR associates but user can see “old” records if the the “PERNR” had previously been asigned other responsibilities outside of HR.
As far as I understand, the time logic principle dictates that if I have ever had update access to IT 0008 of a person (when the EE was outside of HR), I would always have read access to that person’s IT 0008 (even when he moves into HR org). This is how the system is designed and I don’t believe there is a simple way around it. The sap reference around this can be accessed at “http://help.sap.com/saphelp_dimp50/helpdata/en/10/bbb83b5b831f3be10000000a114084/content.htm”
but I want the first page eg: “Display HR Master Data” to default to only current year and grey out other periods. Is there a way or can I get help with screen modification?
Again I don’t believe this is possible by a screen mod. Almost anything is possible through a core mod however I don’t think you are looking for this option.
Regards,
Aninda
Correction:
2. should read “non HR associates”
ANOTHER CORRECTION
WROTE:
“The user cannot see any “current” infotype records of fellow HR associates but user can see “old” records if the the “PERNR” had previously been asigned other responsibilities outside of HR.”
The user CANNOT see “current” infotype 0008 records of fellow HR associates but user CAN see “old” IT0008 records if the the “PERNR” had previously been asigned other responsibilities outside of HR.
Aninda,
Thank you so much for lending a voice and expertise to this task. I will take it up to the poject co-ordinators and explain the limitations of the system to them.
One thing that just came to mind is that prior to associates being transfered to the HR department, the HR associates were allowed to access the IT0008 records for all non HR associates anyway..so they already know what the “NEW” HR associate was making before the transfer and so it should not become a “federal case” if they continue to see the old pay so long as they can’t see current pay of fellow HR associates.
Again bravo for the excellent work!!
Greetings Aninda!
First of all thank you for creating this wonderful site. A lot of us have bennefited greatly from your superior knowledge in SAP security.
I have implemented CONTEXT SOLUTION for Time Administrators in different geographical areas in the organization. When I assign a time Admin role to a test user everything works okay except that the user only displays half of the PERNRS assigned in T77UA (OOSB) when he pushes the entry help (matchcode) button for a “wide search” of all possible PERNRS.
How do I display the entire list of object type “P” authorized in T77UA? I have already run the reports RHBAUS02 followed by RHBAUS00 but the user still matches only about half of the associates in the branch structure defined by the PD profile. …and yes I have assigned the PD profile in P_ORGINCON feild = PROFL.
The user is able to update records for all PERNRS even (if they are not matched) but are authorized via PD profile. How can I display all PERNRS for users to select from? Where can I verify if there is restriction for matchcode range. The PERNRS not visible start fromm “41000+”
AUSTW PERNR=1 and DFCON= 4 to allow access to non-intergrated positions
Hi Atta,
If you can see a pernr in OOSB, the PD profile is not restricting access. Check the general authorizations (roles) assigned to the user to find if something is missing.
Also in many cases, the entry help only returns the first 500 or so of the matches. This is certainly not a security error. Sure you are not facing this issue?
Regards,
Aninda
Aninda,
This is one of those instances where you think you have done everything right and yet the expected results is not what you get.
For example when I execute PPOSE, I see two “PERSONS” assigned to the same position: Two Admin. Clerks. The only thing different about them is that one has a PERNR 40473 and the other 42576. They both belong to the same PERSA, EE, ESG etc. In one of my P_ORGINCON iterations, I have customized as ff:
AUTHC—M
INFTY—0001
PERSA—*
PERSG—*
PERSK—*
PROFL—ABCD
SUBTY—*
VDSKY—*
The entry help returns all PERNRS <42000 and excludes all PERNRS above 42000. In my example, both associates' PERNRS should have been returned. My list is only 10 instead of 25 returned via PD profile in OOSB.
I have been strugling for weeks to fix this but can't seem to figure out the missing authorization. If the user enters the PERNR in the PERNR FIELD, he is able to R/W/E..etc without any problems for all PERNRS in OOSB. Is it possible to restrict a PERNR range to be returned by search help?
Hi Atta,
Search helps also use the same auth objects as the other reports but I am pretty sure that you can not actually restrict by pernr ranges. there might be a problem with config options for the search helps which are only returning certain pernrs. A quick security check will be to log in with SAP_ALL and check if you can get 10 or 25 entries in the search helps. Best of luck!
Regards,
Aninda
Just an update, today the PC support decided to install SAPGUI 720 on my machine and for some strange reason I am now able to see all PERNRS returned in OOSB. I don’t know what this patch has to do with T77UA/T77UU but I am glad it is working.
Hi Aninda,
Today I am encountering a problem reading the Authorization profiles although Ithought I understood it fairly well. In OOSB I see a PERNR under object type P.The root object asigned to the PERNR is say 9000xxxx. When I Execute PPOSE and display 9000xxxx, I expect to find the person who has been assingned PERNR 9000xxxx. I dont find him but I find him under a completely different ORG UNIT with a completely different Org unit ID. why is OOSB showing one root object for the PERNR and the ORG STRUCTURE shows the same PERNR under a totally different ORG UNIT? How do you get both to be in sync? The beginning date of the PERNR in OOSB is 07/20/2007-12/31/9999.
Thank you.
Hi Atta,
Trying to relate the views in PPOSE to what you see in OOSB will need you to have substantial understanding of Org Management and the different configuration options available in PPOSE. I will not attempt to answer your question as there is just too many things that might be happening. I would suggest getting in touch with your HCM consultants.
Regards,
Aninda
Thank you for responding. I believe that to be able to to implement CONTEXTUAL AUTHORIZATION, understanding Organizational Management is necessary. My understanding of root object is that the evaluation path (O-O-S-B) first locates the the designated root objects or start object and then access is granted to all subordinate objects untill the evaluation hits another object on the same level(rank) as the defined root object. To me this is a simple conceptif there is a clear understanding of the various inter object relationships.
I asked this question because I have built 104 PD profiles for 104 different Time Administrators in table T77PR)(OOSP). These PD profiles are maintaned as PROFL field values(P_ORGINCON) in 104 derived Time Admin roles. When I assign TESTUSERS to OOSB with designated PROFILES/ROLES the users are restricted to their designated substructures within the ORG structure. I am able to see all of the org units, jobs, positions and PERNRS that the intended authorization is designed to restrict for access. That is to say the CONTEXTUAL solution works well except that there are only two PD profiles that seem to throw me off.
I see an org UNIT that the user has access to with an assigned root object. That means the org unit is subordinate to the root object so it must BELONG to the root object or that the root object is line supervisor of the the subordinate object( org unit). Please correct me if I am not making sense of the OM concept. I just wanted to know how do you get table T77UA to update so that objects acessible by the user are in sync with permited objects in the ORG structure.
I believe without that, then the context solution will be flawed as I have discovered that two of my PD profiles grant un authorized access to an org unit which by visual inspection of the ORG structure should not be the case. For example my start object is CHICAGO so it is logical to see sub org units such as Cook county, Springfield etc. I should not see ares such as San Francisco since they belong to an entirely different branch structure.
I have run RHPROL0, RHBAUS02/01/00. Maybe there is more to OM that I am yet to grasp and I will appreciate your help as the OM consultants I have approached are also scratching their heads. My simple question is why can’t I see the org unit as a subordinate object under the assigned root object in T77UA key dates are current..did I miss a report? I notice that newly added PERSONS in the ORG STRUCTURE only updates after running RHBAUSXX reports .
Sorry for taking so much of your time.
Thanks
Atta
Hi Atta,
Please don’t think that I am trying to pick on you but there is only so much I can help you by reading through some text. And both of us obviously understand and express the same HCM topics in different words. I am still not clear what you mean by “I see an org UNIT that the user has access to with an assigned root object. That means the org unit is subordinate to the root object so it must BELONG to the root object or that the root object is line supervisor of the the subordinate object( org unit). “
From what I understand, any evaluation path is a simply a simply a chain of relationships which start from an OM object and end in another OM object. The root is the start object from where an object tree is built. For the O-O-S-P path, the start object will be an org unit and the path will evaluate all org units, positions and persons in the line hierarchy of an org till the very end. The depth of the tree to be constructed is specified separately.
The view of an organisation that you see in PPOSE is also dependent on an evaluation path which is set as part of customizing. Use PPST transaction to check the objects returned by an evaluation path. If an evaluation path doesn’t return an object, this needs to be addressed by the OM guys and not by security. Typically they would compare the definition of the evaluation path in OOAW with the org structure relationships created. If the same evaluation path and start object returns a different set of objects in OOSB, then security might need to investigate. The status vectors, depth, sign and period will all come into the picture at this stage.
Hopefully you find the above tips helpful.
Regards,
Aninda
Aninda,
Helpful as always . PPST is definitely a good tool(T-CODE) to investgate expected objects returned in OOSB(T77UA. First time using it.
Thanks.
Atta
“I see an org UNIT that the user has access to with an assigned root object. That means the org unit is subordinate to the root object so it must BELONG to the root object or that the root object is line supervisor of the the subordinate object( org unit). “
“BELONG TO” and “LINE SUPERVISOR OF” are OM terminologies based on relationship types. What I mean is that when a user is assigned to T77UA(OOSB), based on the assigned profile, T77UA returns a set of object types linked to the Start objects (root objects). So if upon clicking on “I”(OOSB) and you see an ORG UNIT (ID)under object type “O” then that org unit is at a lower level in the object tree starting from the root object. But if OOSB returns an org unit outside of the sub structure returned in PPOSE then something is not right.
If you search for the root object in PPOSE and double click then in QUAD1 (THINK QUADRANTS IN MATHS)in the PPOSE screen, you should be able to see all objects under the root object. If this is correct then an org unit returned with the said root object in OOSB should also be visible in the report tree.
In my case, this doesn’t happen for 2 out of my 104 PD profiles. For one of these two PD profiles an org unit appears which doesnt fall under the root object in PPOSE and as a result the user has access to unauthorized PERNRS.
The other PD profile returns ORG units with unexpired validity but not returned in the report tree in PPOSE starting from the root object. If objects returned in OOSB are not in sync with the report trees in PPOSE then the context solution will not work. 102 PD profiles point to the correct objects and for these two I cant figure out what is wrong. I have used the same EVALUATION PATHS, STATUS VECTOR, DEPTH, and various START OBJECTS. Is there any reports that will update the T77UA so that it is in sync with the ORG structure? I hope I have explained my situation well enough this time. I haven’t had much help with the OM consultants on hand.
Sorry for dragging this issue for days. I just can’t figure out why two PD profiles completely challenge my understanding of how CONTEXT works. Thanks for your help.
Atta
Hi Atta,
Some things to investigate.
1. Try the start objects in the two problemmatic PD profile with PPST. PPST is not a security transaction but a OM one.
2. Look at the HRP1001 table which stores relationship details for OM objects. Check for validity dates, plan versions, planning status, org changes.
Aninda
Thanks Aninda.
Aninda,
I am still strugling with OM issues. Since I have to test my PD profiles, I have to make assignments in PPOSE of PERNRS to positions. The new assignments successfully updates in T77UA. the object tree returns all of the objects visible in PPOSE. I see that if I search for an org unit with an ID, all subordinate org units, positions, persons etc are all returned with no problems. In OOSB the same set of objects are returned by the corresponding profiles.
I keep asking you the same questions…shouldn’t the Herachcal objects always be in sync with the output in T77UA? If the root object is 9000xxxx. Then if you search for 9000xxx in PPOSE then you should see all the related objects. Is this correct or not? fOR one of he PD profiles the OBJECTS(P) are missing in PPOSE. When I search for the PERNRS under the root objects I get a “no hit”. Why so?
I noticed that in PPST the root object and related objects are set up in the same hierachical arrangement as in PPOSE. So then why can’t I see some PERNRS assigned to the same Root object in PPOSE. This is making it difficult for me to pinpoint where errors are coming from. When you define a start object in OOSP you should know which objects will be returned . This is the main concept of CONTEXT SOLUTION. So my other question is which org structure should be used to guide the building of PD profiles?
If I can’t see all of the associates that I see in OOSB as in PPOSE which view will give me a better picture of the org/staffing structure? PPST shows me that the object(PERNR) is returned by the root object but PPOSE does not show all of the PERNRS. This issue is holding up my progress as there are not any reliable OM consultants on hand. Please asnwer my main question shouldn’t PPOSE and PPST and PPOME…etc all return the same set of objects if the evaluation path remain O-O-S-P PLAN VERSION =01 DEPTH=0. Is there anything I don’t understand in OM as far as seting up CONTEXTUAL AUTHORIZATION?
As I have earlier said, there are multiple views which can be shown in PPOSE. You can have the staffing view, the managerial view, the job asssignments view etc. Interpreting what you see in PPOSE can be at times be difficult. That’s why I have been suggesting that you use PPST while designing your PD profiles.
Today I got some much needed help to clarify some of my OM concerns. It turmed out the data mismatch I have been experiencing in OOSB vs PPOSE/ PPST is due to an error in the data syncing process by our HR Systems Development team. They have clarified that there is a lot of junk data in the DEV system and that data will be a lot cleaner in QAS. So to all other Consultants who may run into very challenging situations..remember it is not always configuration or customizing or even security related errors. Some errors may be purely data related too. Like the saying goes..junk in junk out.
Thank you Aninda for being there for us..
Atta.
Great that you finally found the answers that you were looking for. I was looking at my blog’s dashboard after a gap of more than a week. Seems like you have been busy 🙂
Hi Aninda,
I have created a Time Admin role which grants user access to FLEXIBLE EMPLOYEEE DATA via T-CODE PAR51 and report S_AHR_601016362. Since I have implemented CONTEXTUAL authorization, my expectation is that only PERNRS returned by the defined PD profile will be accessed by the Time Administrator when PAR1 is executed but to my suprise the time administrator is able to access flex data of all employees(all PERNRS). This comes as a suprise because all other T-CODES within the role only allow the expected restricted access by PD profile. Can you please shed some light on this this report? I have seen a few similar complaints about this reportby other consultants in other forums.
Thanks
ATTA
Do the time admin’s have any other roles with HR access? If there are roles other than the Time Admin role with access for the same infotypes with larger access, the tcodes can be run for the larger population. Check if you are using P_ABAP as well. This object can override a lot of other HR objects.
Hi Aninda,
I am only testing the single role. At the moment only the Time Admin role has been assigned to the TEST ID and P_ABAP is deactivated. The other activities within the role work flawlessly restricting access according to objects returned by the PD profile and positive/negative testing for say CATS work with no unintended access within the role except for PAR51/S_AHR_601016362.
Thanks
Atta
Currently users assigned various PD profiles in UAT client for the structural authorizations, ESS is one of them, this includes LSO course catalogue by trust, in ESS PD profile we have used the functional module ZLD_FILTER_COURSEDETERMINE which will run by the evaluation path L-D-E, so that users will see their own catalogue belongs to their trust/company code.
Problem: Since couple up days users not able to see the course catalogues even though relevant PD profile and roles assigned the users and users positions, I think this could be table T77UA table overflow kind of issue.
BUT………..
If I delete the PD profiles and re-assign the PD profile to user position and run the INDIX generation job, users able to see the course catalogues belongs to their trust/company code, this is not an additional access, only refreshing the user access by deleting and re-adding the PD profiles to the positions, this shouldn’t be the case at all, if users has PD profiles assigned to their positions and have entries in the table T77UA, all structural authorizations should work.
Since you have mentioned that re-generating the indexes for the users solve the problem I am assuming that the PD profiles are returning the correct set of objects. To confim this check RHAUTH01 report for the users who are missing course catalog entries. If this report doesn’t show up the required entries you would need to troubleshoot the function module you have mentioned.
Please note that if you are indeed indexing the users, the indexing job should be shceduled to run every day or at some other periodic interval.
Greetings,
I implemented context authorization with AUTHORIZATION MAIN SWITCHES as ff:
ADAYS=15
INCON= 1
DFCON=1
PERNR=1
All Other Switches= 0
I tested access grated for the various PD profiles for 104 Time Administrators and everything worked fine.
Now the 2nd phase of my project requires me to clean up 126 Hr Roles. I have also built Context roles for the users. I noticed today that I forgot to assign a TEST USER to OOSB and yet he is able to execute PA* T-CODES successfully without any errors.When I check ENTRY HELP for PERNRS, He is able to return all associates in the organization and maintain HR master data for the assigned employee sub group. I only assigned the ALL PD Profile in P_ORGINCON and NOT in OOSB What I expected to happen is a structural authorization failure. Why did the system fail to catch this ommission?
Also check my SWITCH SETINGS. I know these settings are good for CONTEXT. Did I miss anything?
Hi Atta,
The value of the switches are fine. If you don’t have an entry for a user in OOSB, the system interprets the user to have the same PD profile as the one assigned to SAP*. In all probablity this is what you are facing.
Thanks,
Aninda
Thanks. It seems like leaving OOSB assignment is not a good idea as this may grant unintented access.
Thank you for the excellent work.
Greetings Aninda,
I turned on CONTEXT switches in a CLIENT and now users cannot data sync. They were able to data sync with NON CONTEXT. How does the new CONTEXT settings impact HR records.All I have done is activate P_ORGINCON but kept the same authorizations and ofcourse added the ALL PD profile in the PROFL field as well as the T77UA table(OOSB). I have run RHBAUS02 followed by RHBAUSOO. I cannot locate the PERNR in PPOSE nor PPST. Everything was working untill I turned context settings on. Please help. Does context break the RFC connections which impact data sync?
Hi Aninda,
ADAYS does not see to work with context solution i.e P_ORGINCON and P_ORGXXCON.
Can I check if there is any special config setting to enable that