Assign single role to composite role with alternate logsys assignments

[Former Member]

Dear gurus,

In a moment of weakness I created a composite role (shame on me) and then noticed something about them which I had not noticed before... -> I was in a CUA master system and in the composite role I noticed that on the (single) roles tab of it, there was a field called "logical system". But it is greyed out.

Now composite roles from the child logical systems are known to the CUA master system and have a logical system assigned by the text comparison. Assigning the composite in the master system will assign the composite in the child system and that assigns the local single roles in the child system as well -> so far so good and by the book.

But is there some way to assign a composite role to a user in the master system which is assigned also to the master system, but the single roles of that composite have logical systems which differ from the logical system of the master system? So basically the field is not greyed out in the central composite roles and this composite role then represents an assignment beyond logical system boundaries - much like a "business role" in IDM.

Has anyone ever done that before and survived? Any pros and cons? Is it at all possible what I am seeing here before my eyes (bar that the field is greyed out)?

Cheers,

Julius

[mvoros]

Hi,

I don't think so that this is supported by current data model. The table AGR_AGRS holds all roles assigned to a composite role. The field CHILD_AGR has a foreign key to table AGR_DEFINE that holds every role. The problem is that in case of CUA the roles from child systems are not stored in AGR_DEFINE, they are in USRSYSACT. Hence you should not be able to create a composite role that have roles from child system. Another issue is that you could have same role name in two systems. Now you want to create a composite role that has one of these roles but not the other one. AGR_AGRS does not have a field for child system hence it's impossible to know which role should be used.

Cheers

[Former Member]

Hi Martin,

Thank you for helping my sanity..  🙂

Looking at the code, the search help is a local single role and the local logical system name is used.

I then ran it in the debugger to see where the "target system" = "user system" is coming from when adding a single role and hitting "enter".

Well, well, well... the plot thickens... Yes, the assignment of the single role itself is the same as the logical system of the composite role, but those single roles themselves can have "target systems" for Trusted RFC. This means when the user menu is turned on and the user in the system where he has the composite role clicks on the transaction from the single with the "target system" assignment, then the session_manager will via trusted RFC take him to that target system and start the transaction there (assuming he is authorized for the transaction there). This must additionally be turned on in SSM_CUST via switch TRUSTED_SYSTEM = 'YES' (default is 'NO').

So I am coming closer to the conclusion that this is just navigation for systems setup that way and actually has nothing to do with the CUA. The "target system" field will never assign roles from foreign logical systems and any alternate value coming into visibility there is actually an (optional) RFC connection for navigation for the user.

Has anyone ever tried this and survived?  🙂

Cheers,

Julius

[former_member298454]

HI Julius,

Thanks for bringing this thread . I seen many times this option but didn't try to make an attempt to explore more .

I tried this scenario in system but couldn't succeed as system are in non-trusted relationship  .However I understood the reason behind why it should have trusted relation.

To establish trusted rfc connection b/w systems will not require SSM_CUST entry ,but why such entry is required here , is it kind of mandate step to enable this accessing tcode via trusted rfc functionality?

Thanks,Krishna

[mvoros]

Hi Julius,

just found note 1263259 - PFCG: Error in role menu maintenance. Based on text from there it seems to be used for menu import.

Cheers

[mvoros]

Hi,

it seems like SAP developers decided that not every customer would like to have this behavior so they give us an option of controlling it with an entry in SSM_CUST.

Cheers

[Former Member]

Hi Martin,

Yes, I noticed that as well when debugging. Assigning a target system to the role attempts to import the menu of the role from the source system into the role in the target system as the authorization will actually be needed there, and not in the client system where the user clicks on the menu.

Sort of makes sense, because the user must be authorized for the tcode in that target system, but technically in the call it does not have to come from that role as the target system knows naught about the client system role - only the SMT1 trust must be setup.

The gotcha in the thing however is that if you set it up like that between a CRM and ERP system, then the client system pushes the role menu. The transaction to be called in the target system must also exist in the client system - which is often not the case if that step involves processing for a transaction which does not exist in CRM -> you cannot build the role, user menus must be turned on, the role names must contain a logical system identifier and activating redundancy compression with a well thought out menu structure is not avoidable.

I can understand the theory of this, but would be curious to know whether anyone ever did this in a system landscape and survived to tell the tale? 🙂

As a side note: I would also like to draw folks attentions to S/4HANA platform from SAP -> the component type systems are relaxed and the data model is revised and runs on SAP's HANA database. Basically you have all components in one box (ERP, CRM, SRM, SOLMAN, BW) so it eliminates all the integration programming and external RFC because everything in in the same real system and not a bundle of separate logical systems with the same identity from a trust perspective. So client = target. This seems like a much better idea and the centralization of authorization administration, monitoring and strategy to keep it secure is a much better approach than crowd sourcing security in many managed systems.

But I would still be curious to know whether anyone actually used this (target system assignment of single roles and building composite roles which have different subsystem assignments)?

Cheers,

Julius

[mvoros]

I think you are walking really close to the edge. You might be even over with this solution. I guess most of folks try to stay close to standard especially when we are talking about security. Or at least they should. So chance of finding somebody who used this and survived is really slim IMO.

Regarding S4/HANA I think it's too early to say if merging all systems (ECC, CRM) is a good idea and customers are going to adopt it. Even if they adopt it the IT landscapes are much more complicated and you should start looking into implementing IdM solution. SAP is also pushing for hybrid approach (cloud with on premise). For this you definitely need a dedicated system that manages identities. Centralization from security point is a good idea but I don't think it's feasible in todays world.

Cheers

[Former Member]

Hi Martin,

I am completely with you!

I have known about this remote trusted navigation targets for some time in single roles, but when I noticed it in composite roles on CUA I thought (initially) it might in fact be a logical system assignment of the single role under the composite -> that would have been interesting. Hence my question whether it is an intention for a "Business Role" definition centrally (in the same sense as IDM systems have it).

But it is not the case as it turns out. It is menu synchronization between (incompatible) component systems of different types with prerequisites which are hard to achieve. Much too clever even if the theory works.

S/4HANA: Yep, I am also watching it. Customer often kept separate regional systems and HR separate as well because the development and patching cycles are different and the customizing is different because the business processes are different. Good point! The data model even changed in S/4HANA so the customizing options might have relaxed to consider local requirements which did not fit into the same box before. I have several international customers on EHP7 now rolling in the US, Asia, Zimbabwe and even Italy to the same system... 😉 Local requirements are more reporting related and less customizing that interferes with others. Roles are more complicated as some use release codes on purchase requisitions and others on the purchase orders, Others want a 3 way match, others 2 way match, and in Timbuktoo there is only 1 person so even workflow and UWL is not an option.

A nice thing about S/4HANA is that taking all old Z-programs with is not an option. Only a handful that are API based. Updates to SAP tables are also blocked technically now (I tried - it did not work with ABAP native commands).

Interesting challenges for sure, but correct way to go IMO.

But back to the original topic: Did anyone ever try this remote menu synchronization and navigation via single or composite roles? Did it live longer than you?

Cheers,

Julius

[mvoros]

A nice thing about S/4HANA is that taking all old Z-programs with is not an option. Only a handful that are API based. Updates to SAP tables are also blocked technically now (I tried - it did not work with ABAP native commands).

That's interesting. I haven't been connected to S4/HANA system yet. Are you saying that the developers are blocked from accessing tables directly? That makes sense but I am wondering how it's done.

Cheers

[Former Member]

Actually it is in the ABAP application and nothing HANA specific. If you try to update some tables (eg. TADIR) from other packages (eg. Z-programs in $tmp) then it does not work anymore. Also on 7.40 systems if configured to do so.

I believe this is a an extension of the package check from a syntax warning to a runtime error. External package programs must go via APIs and not directly to foreign tables.

Boxing something directly into the DB or via SQLEXEC will probably be with us forever though.

Cheers,

Julius

[mvoros]

OK, so it sounds like ABAP kernel is restricting which programs can access which tables. Similarly what's is being done right now when you want to access trusted store. That sounds like a really nice feature and it can avoid some nasty bugs. On the other side everyone will be frustrated when API provided by SAP does not cover everything. Thanks for the info. Do you know which release of 7.4 supports this?

Cheers

[Former Member]

Hi Martin,

I had to research it myself. Seems like SAP had the whole thing planned ever since SAP Note # 7...  🙂

In 4.5x the field DEVCLASS was introduced to S_DEVELOP as the organizational unit for controlling development objects.

In 7.31 already the extended syntax check (SLIN) was equipped with warnings for package conformity.

It is now configurable since then to influence how strict the syntax checks and runtime checks are. There is a series of blogs on it by which includes the security advantages amongst others -> google for "site:sap.com package concept trapp"

Yes, I completely agree that a package can only be switched to runtime errors once it provides all required APIs or it's classes permit "friends".

Cheers,

Julius

[Former Member]

Hi Martin and others,

I experimented a bit further with this, albeit rather unsuccessfully from the view of useful results.

While the "target system" field is intended for navigation to the corresponding trusted RFC connection, it is also possible to turn the user menus off. So such a remote role is not going to go anywhere in navigation. If additionally the CUA is active and you create all the target system single roles in the CUA master system as well and assign them to the "target" they are intended for... then the single role menu is transferred to the child system which the role has as a target. But only the menu, and leaves the role in the target as status red. That also means it is only useful for component neutral roles.

Now comes the hack: If you create a composite role in the master system with local single roles as well but the single roles are assigned to "targets destinations", then when assigning the user to the composite role in the master system, then it also assigns the single roles in the target systems to the user as well as the local system (the master as a child of itself). So it is in fact a halfway business role in the IDM sense, with some naming convention strings attached.

You also dont see this in the code of SU01, as the USERCLONE Idoc processing seems to be the guilty one to also send aditional Idocs for these single roles with targets assigned to the roles and not the user.

There is only one major show-stopper in the design of the thing: You can only assign 1 target RFC connection to a single role in the central CUA master system but have to maintain the roles in the target logical system still. That means that roles must be maintained logical system specifically. That also means that you have to maintain the roles directly in production and have a completely different set for development and never transport any roles. They are as unique as their CUA master system "target destination" value and that is the logical system name as well.

That is a bit of a bummer because it means that you also cannot ever test anything...

Did anyone ever try to actually use this?

Cheers,

Julius