Skip to Content
author's profile photo Former Member
Former Member

Dynamic role assignment at login - Supporter concept

Dear experts,

our auditors had the idea that all system supporters (not the normal users) have only display authorization. In the case that the supporters need to modify data they have to state a reason and then the login with a special user (via RFC from their user) which is authorized to change data.

The problem from my point of view is now, that since this "special" user is permanently in use by the support users (we have around 60 supporters for different areas) it is very hard now to find who changed it in person (since this user is the same for all). We have the system audit log running for this user, but sometimes the log file is full and the data is lost who did what. Supporting RF transactions doesn't work as well since these transactions check for single logon (which is almost never the case due to parallel usage of this special user).

To cut a long story short, I don't believe in this concept. My "dream" would be the following: On the logon screen of the production system there are 2 radio buttons:

User:

Password:

(x) Display only login

( ) Supporter login - please state the reason for usage in the text box below:

<Text box>

Depending what has been chosen the supporter user should have either display or modify authorizations with his normal user name.

Do you think this is possible? If so, can you give me a hint?

Gunter

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

4 Answers

  • Posted on Dec 22, 2008 at 08:36 AM

    Since they need permission anyway you could give them display rights for their account and create a reference user with rights to modify data.

    Once they've requested access and it's okay-ed you connect the reference user and start monitoring their account. This way they'll do everything under their own name and they will always need a second pair of hands/eyes to get the extra rights. The only thing I do not know is if the addition/deletion of the reference user will show up in the users' change documents. If that's the case your auditors may even become happy.

    About modifying the logon screen, I've heard that's the biggest nono possible as any mistake can render your system unusable.......

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Dec 22, 2008 at 09:27 AM

    We have these kind of requirements some time wherein the users (customizers generally) require special access in production system. We have a specially designed role for this purpose. We assign this role for a temporary period via our customzied CUA tool, The role assignment has to be approved by the users manager and the role owner. Also, we mention in comments section the exact requirement.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Dec 22, 2008 at 06:22 PM

    >

    > Dear experts,

    >

    > our auditors had the idea that all system supporters (not the normal users) have only display authorization. In the case that the supporters need to modify data they have to state a reason and then the login with a special user (via RFC from their user) which is authorized to change data.

    > The problem from my point of view is now, that since this "special" user is permanently in use by the support users (we have around 60 supporters for different areas) it is very hard now to find who changed it in person (since this user is the same for all). We have the system audit log running for this user, but sometimes the log file is full and the data is lost who did what. Supporting RF transactions doesn't work as well since these transactions check for single logon (which is almost never the case due to parallel usage of this special user).

    >

    > To cut a long story short, I don't believe in this concept.

    Well, what you have described sounds very similiar to the "Firefighter" concept of GRC, indeed.

    > My "dream" would be the following: On the logon screen of the production system there are 2 radio buttons:

    >

    > User:

    > Password:

    >

    > (x) Display only login

    > ( ) Supporter login - please state the reason for usage in the text box below:

    >

    > <Text box>

    >

    > Depending what has been chosen the supporter user should have either display or modify authorizations with his normal user name.

    >

    > Do you think this is possible? If so, can you give me a hint?

    >

    > Gunter

    Sorry, but I dislike that idea. First of all: there are many logon screens - and you might not be able to modify them all (e.g. the SAPGUI logon screen). Second: that's mixing "authentication" with "authorization" - and in general it's not good to mix different concepts (just as a general "rule of thumb"). Actually, you could simply create two accounts (for each of those users) - one with the "display only" authorization and one with the "supporter" authorizations. I assume that the only reason for not doing so is the license measuring, right?

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Dec 22, 2008 at 09:29 PM

    We have a self-developed emergency user solution, however it would not completely meet your requirement 😔

    But here is a suggestion for yours:

    > Wolfgang wrote:

    >>Actually, you could simply create two accounts (for each of those users) - one with the "display only" authorization and one with the "supporter" authorizations.

    Legend :

    "display only" user ID = NORMAL

    "supporter" user ID = NORMALX

    What you could also do, is create a second ID (NORMALX) in a protected group for each of the folks (NORMAL), but only with the delta authorizations assigned to them (the add on support features, not the basic display authority etc to be able to enter the transactions).

    Then set the system up to trust itself for trusted RFC, and assign S_RFCACL allowing the "same user only" to be different, but only for their own "add on" support user (NORMALX). You need to be very restrictive here.

    Then disable the password of the NORMALX so that it cannot logon via the SAPGui logon screen.

    Then disable the Reference User type check in table PRGN_CUST temporarily and add NORMAL (who must have logged on already) as a reference user for authorization checks to NORMALX (the user ID with the add-on features). Not the other way around (!).

    Then, there is a user exit in the SAPGui logon program which you can use with your own coding to check to see whether the user NORMAL has a reference user with an 'X' attribute. If yes, then give them a popup to decide whether they want to proceed with a normal logon or an "emergency" support logon with additional access.

    This way, if they create a new session or logon via types other than the SAPGui logon... they should not be able to access the additional authorizations of NORMALX.

    But if they choose "Yes"....

     PERFORM user_switch USING it_uname... 

    Note that the security audit log has dynamic profiles as well. You could tweak it there as well, so that folks have to "sign off"... so that they don't click "Yes" every time to avoid being hassled about it 😉

    Please post your coding if you want to try it and have problems or doubts.

    Cheers,

    Julius

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.