cancel
Showing results for 
Search instead for 
Did you mean: 

SAP GUI Scripting Allowance

amyfeldman
Explorer

Hello,

We have recently licenses SAP Enable Now primarily for use on our ECC systems. We have been challenged by the security team about the need to turn on scripting. They feel that turning on scripting will destabilize system security. Has anyone else had to justify the need to turn on GUI Scripting?

warren_angerstein3
Active Participant

we are on premise, but have it enabled in Dev and QA, but not production for security reasons. This follows our Global Information Security policy.

Accepted Solutions (0)

Answers (2)

Answers (2)

Wallace
Active Participant

For us, at my company, I usually do not suggest recording in production, instead relying on QA.

Several reasons:

1. Additional system load. Yes, I know this is a small load and we are always (almost) sized for this not to be an issue.

2. Data - sometimes in QA we have the data less "real" - for example, we could have names that are not "real data". If we do, this can minimize the need for anonymizing data in the edit phase after the recording.

3. Old historical way of working: Sapgui scripting brings additional load, security questions, so the path of least resistance is usually QA.

Hope this helps, provides some additional items to consider. I like Kristina's answer above.

Wallace

amyfeldman
Explorer

Thank you, Wallace!

apetriuusi
Explorer
0 Kudos

Hi Wallace!

First off, thank you for your response. It is much appreciated.

I work with Amy, and wanted to take a minute to elaborate a bit of the situation.

As you rightly recommend, we are currently recording in non-production environments.

The issue we are dealing with is how to enable Desktop Assistant for end-users, which requires read-only scripting to identify context and serve up SEN content. This would need to be enabled in both production and non-production environments, as we want to be able to deliver the same on-demand learning to end-users, regardless of the environment they are in.

I hope this helps. If you have any further thoughts, we would love to hear them.

Stay well!

Wallace
Active Participant

Hi Andrew and Amy,

I want to see how Kristina responds to today's update.

Sorry I can't help more - we don't currently run Desktop Assistant. As we look at S4, I am pushing the Web Assistant capabilities - delivered from SAP and perhaps we build our own. We're on an S4 journey, but nothing yet live.

Wallace

KristinaKunad
Product and Topic Expert
Product and Topic Expert

Hello Amy,

other customers might be able to also share their experience around the scripting topic. From my experience it can be necessary to justify the use of scripting but in 90% of the cases the security team allows it because

1. there are valid reasons for it,

2. we only need to read out data via scripting (not write it),

3. and you can use SAP roles and authorizations to define who can use it.

Please find more information about scripting and security in the SAP Scripting Security Guide.

If this answers your question, please mark the question as answered.

Take care,

Kristina

amyfeldman
Explorer

This is a great help! Thank you, Kristina. We've created a lot of content and are frustrated that we may not be able to use Desktop Assistant to share it.

apetriuusi
Explorer
0 Kudos

Hello Kristina!

I would like to echo Amy's thanks for your response. I am on the technical team on the SAP Enable Now deployment Amy is asking about, and really appreciate your thoughts.

We did review the scripting guide, and have a decent understanding of the core scripting security approach.

The challenge we are running into here is that, in order to serve learning content to our end-users in the production environment, they must have read-only scripting access in that environment, which means we must essentially grant read-only access to everyone. This tracks with your second point in that we only require read-only scripting access, but this is just as much of a concern to our security/compliance team in that they are concerned with scripting causing a load issue if used incorrectly. We are also unable to leverage roles/authorizations OOB, due to the fact that anyone could be an end-user seeking learning content.

We are really trying to understand if other companies that have also deployed Desktop Assistant have also encountered these type of concerns, and how they addressed them. Is there another tool or security layer that might mitigate the risk of scripting abuse? Is there a way to dynamically provision access through roles/authorizations for users, either based on t-code usage and/or the presence of the Desktop Assistant (we explored this to some extent with a tool called Nextlabs, though this was not successful)? Or have other companies NOT enabled scripting in production and instead only allowed access to Desktop Assistant content in non-production environments?

Any insight you or others here can provide would be greatly appreciated. Either way, thank you again for your response and support.

Stay well!

KristinaKunad
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Andrew,

sorry for the late response - did not get an email about a new comment.

Let me answer your second question first - other companies in my experience do turn on the scripting in their productive environments. Since the access to the transactions is already being handled by the SAP roles, only specific users will access the transactions and thus the learning content through Desktop Assistant.

I am by no means an expert on security, but from what I have gathered from my discussions with customers is that there is a way to tie the scripting access (even read only) to specific roles. I think this would be the parameter mentioned here:

The problem can be solved by setting the rights to run SAP GUI Scripting per user. The new profile parameter sapgui/user_scripting_per_user allows the administrator then to enable SAP GUI Scripting support for specific users. Unless the administrator explicitly changes the value, this parameter is set to FALSE. If the profile parameter is set to TRUE the following happens: ● On the login screen SAP GUI Scripting is available for every user. ● After login, SAP GUI Scripting only remains available for those users that have the authorization for the Execute(16) action of the authorization object S_SCR in class BC_A.

From the way I read it you could put that authorization object into an SAP role and handle the scripting permission via that role.

Hope that helps!

Kristina