topic Communication vs. System User Types in Application Development and Automation Discussions

Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 20:11:48 GMT

All:

I was researching something else when I came across an article or note (forgot already) but what I do remember is that SAP was moving more towards System ids and not using Communication Ids. Furthermore Communication ids could be changed over to System ids with no impact (to account behavior).

My searches have come up short and now seeking out to see if any one read this or has insights into this.

- Matt

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 20:44:04 GMT

What were your search terms?

There are several discussions about this on SDN and the better ones reference SAP Note 622464.

There are also many other SAP notes which describe symptoms of this user type problem in applications (Workflow, STMS, IS-* ... all the usual suspects

Cheers,

Julius

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 20:55:47 GMT

Julius,

These are definately helpful. As for the part around moving away from "Communcation" user types and only use "System", any thoughts?

I know eRecruit needs to use Communication users.

- Matt

Edited by: Matt Urban on Jun 21, 2011 1:57 PM

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 21:28:22 GMT


I know eRecruit needs to use Communication users.

There is a use-case for this when the end-user should be named as the communication partner but should not be SAPGui capable.

Communication users are personalized backend users for real humans in this case, who can also change their own passwords via non-SAP protocols.

In those cases you typically use real SSO anyway and delete the password, so can also use SYSTEM users for them if there are no licensing implications and they do not / should not be able to start external http debugging calls to the backend...

I am not aware of any defendable use-case for COMMUNICATION type users anymore, but suspect that you want HR applicants to have their own accounts in the backend and they are still using their own named IDs and passwords of the backend sytem. Okay... maybe there is a use case still.

When making the change, you need to consider:

SYSTEM type users cannot change their own passwords.

SYSTEM type users do not need to change their own passwords based on password rules.

SYSTEM type users cannot issue SAP login tickets, but can accept them if issued by the calling system (external portal?).

In all three cases, you have a higher level of security against DoS attacks and client / server side "identity hoppers" (proprietary terminology of Julius Bussche...:-) by using SYSTEM type users.

As of release 7.30 you can also assign security policies directly to the users which will give them a different password policy to follow than the RZ11 login parameters (until they pass the interview... and become employees, etc).

I am not familiar with eRecruit. Does the implemention guide recommend COMMUNICATION type users explicitly?

Cheers,

Julius

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 21:39:38 GMT

 
In all three cases, you have a higher level of security against DoS attacks and client / server side "identity hoppers" (proprietary terminology of Julius Bussche...:-) by using SYSTEM type users.

Interesting statement. Could you explain or provide documentation into how-so? Its my understanding that both System and Communication user types can be leveraged for external RFC connections and system-to-system communications and would be suspect to DoS & "identity hopping" (C) Julius Bussche.

I have marked this thread as answered but your statement has sparked an intriguing path I would like to travel down.

- Matt

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 21:59:39 GMT

If you can interactivately change the password (as is the case with COMMUNICATION type users), then you can:

a) Break the existing interface(s) as their previously correct passwords fail.

b) Logon with the new password from your own client application where you have more access.

c) Logon to systems which issue SSO2 logon tickets and then find interfaces which make subsequent calls to other systems.

For me these are 3 very good reasons to avoid COMMUNICATION type user ID's, particularly if they have saved logon data in connection configurations (SM59, etc).

Cheers,

Julius

Re: Communication vs. System User Types

Former Member — Tue, 21 Jun 2011 22:00:57 GMT

Thanks great points.

Re: Communication vs. System User Types

Former Member — Fri, 03 Oct 2014 10:47:51 GMT

When I read your answers I feel like I hardly know anything in SAP security.

Re: Communication vs. System User Types

Former Member — Fri, 03 Oct 2014 11:18:38 GMT

Well... you used the search (winner) and now you know this (another winner), so you will be fine.. 🙂