Analysis AuthorizationsBW and BOBJBW Security

Analysis Authorizations

Analysis Authorizations are used to secure individual InfoObjects during execution of queries. If we get a requirement of the form – “user should be only able to see for sales for the US companies but not for the European ones”, Analysis Authorizations are the way forward. In this post we will try to take a closer look at how these authorizations work and how to maintain them.

SAP provides the transaction RSECADMIN for working on different aspects of analysis authorizations. The different tabs of the transaction allow authorization maintenance, user assignment, transport and tracing potential errors. Analysis Authorizations are also be directly maintained through the transaction RSECAUTH. In addition to the tcodes, A person needs access to the authorization object S_RSEC to work with analysis authorizations.

RSECADMIN - Authorizations
RSECADMIN - Authorizations

The figures below shows an analysis authorization to secure 0COSTCENTER

Analysis Authorizations 1
Analysis Authorizations 1

Individual values can be maintained for 0COSTCENTER as shown below

Analysis Authorizations 2
Analysis Authorizations 2

In addition to EQ (Equals) which is used to give access to actual values as shown below, we might also use CP (Character Pattern) for wildcards or BT (Between) for ranges. Also, instead of values, individual hierarchy authorizations or user exit variables might also used for InfoObjects. In addition to actual values or hierarchies, two special characters are often used in authorizations. These are

  • Colon (:) – Colon is used to authorize access to aggregate data. For example, a person with : for 0COSTCENTER would be able to see aggregate data for all cost centers (cost center in the free characteristics section of the query) but would get an authorization error when trying to drill down on 0COSTCENTER. Colon (:) authorization is also needed for all authorization relevant characteristics which are not used in a query.
  • Hash (#) – While loading data into cubes, there might be some fields for which no values are maintained in the data source. Hash is used to authorize these undefined values as otherwise a full acces (*) would be needed for them.

If we look at the first screenshot showing the definition of the analysis authorization, we find that in addition to 0COSTCENTER, the analysis authorization uses three other characteristics. These are

  • 0TCAACTVT (Activity in Analysis Authorizations) – Default value 03(display) is sufficient for reporting. However, 02 (change) is needed for using planning functionality of BI as planning essentially allows updation of data into InfoProviders.
  • 0TCAIPROV (Authorizations for InfoProvider) – We maintain the InfoProviders for which the authorization is meant to give access. Default is *
  • 0TCAVALID (Validity of an Authorization) – Default value is * but can be used to restrict analysis authorization by validity dates.

It is imperative that all three of the above InfoObjects are part of at least one of the analysis authorizations assigned to a user but its good practice to add them to each authorization that you create.

Once created, there are two ways of assigning analysis authorizations to users.

  • Direct Assignment – Direct assignment of analysis authorizations to users is possible by following the path RSECADMIN >> User >> Assignment which calls transaction RSU01 transaction.
  • RSECADMIN - User Actions
    RSECADMIN - User Actions
  • Assignment through roles – SAP provides the authorization object S_RS_AUTH with the single field BIAUTH. Individual analysis authorization values can be maintained for this field and added to the users’ roles.

55 thoughts on “Analysis Authorizations

  • This is very helpful information.

    I want to know how we handle a scenario in which a user needs to be given access to display one field in the query but another field is not included in the output.
    Will using : (colun) solve the issue.

    Thanks,
    Phani

    Reply
    • Hi Phani,

      Whether colon (:) i.e. authorization for aggregates, will work is determined by the design of your query and whether any restriction for the field is being used . I can think of a few cases below

      – Field not included in query – : authorization will work
      – Field include in query but part of the free characteristics. – : authorization will work
      – Field included in rows of the query. No restriction – : will not work. You need * to give access
      – Field included in rows of the query and the field is restricted to particular value. – : will not work. Both * and actual restricted values can be used to give access.

      Hope this helps!

      Regards,
      Aninda

      Hope this helps!

      Reply
  • Hi Aninda

    We have over 65 infoobjects which are marked as Authorization relevant. So whenever we create authorization in analysis authorization, we need individually select * for all the objects which we want complete access. Normally all we need is to control is access 2 couple of infoobjects, but land up in declaring * for remaining large amount of infoobjects. It is very time consuming. One way is to do a housekeeping of autho relevant check of all the infoobjects which need not be part of security.
    Is there any method to consider only infoobjects of interest ?

    Reply
    • Hi Paddy,

      I can think of two options to reduce maintenance.

      Firstly, if you are not securing any of the 65 characteristics, you can revisit the decision of whether you really need them to be authorization relevant. If they don’t need to be auth relevant, switching off the auth relevant flag in RSD1 will save entering them in analysis authorizations.

      Secondly, you can create a single authorization with all these 65 characteristics which do not need to be secured. Maintain all of them with * access and use this authorization for all users (maybe through a common role?). Now you need to only create authorizations for the infoobjects which you really want to secure.

      Hope this helps!

      Regards,
      Aninda

      Reply
  • Hi,

    we are trying to restrict the user with Cost center and we have add EQ xxxx. and also maintained antorher row with EQ Colon(:). now when we assgined this cost center to the user he is still able to access the other cost centers. do you want us to remove the Colon(:) and then try or any other way to restrict the cost center.

    Note we have also maintained the Hierarchy stucture.

    Thanks
    Sudhakar M.

    Reply
    • Authorization values are intrinsically related the query design and the input values while running the query. A colon (:) for cost center would allow you to run an unrestricted query on cost center as long as cost center is not part of the rows sections in the query design. So first check the query design and then the requirements.

      Reply
  • Thank you for the detailed post. IT was very helpful. We have a requirement, where we have to give a particular user access to a cost center (1000 &2000)and also want to give access to aggregate value ( cost centers 1000-9000). When defining analysis authorizations I gave EQ 1000, EQ 2000 and in another line EQ “:”.

    The users can view the amounts for 1000 and 2000 cost centers and for totals can only see (1000+2000) but not the aggregate $ amount that a user would see with full access.

    Is this even possible with “:” authorization?

    Thank you much in advance

    Bindu

    Reply
    • Hi Bindu,

      Adding colon (:) for cost center should allow you to see the aggregate (totals) value for cost center. However you mentioned that this is not working for you. This might be due to how the queries are constructed. Are you running the queries with costcenter restricted to 1000 + 2000? If its restricted, obviously the totals will also be for these two values. However, also note that in case, cost center is present in rows section in the query, you would actually need the characteristic to be restricted to the two values. Otherwise you will get an authorization error.

      as long as cost-center is in free characteristics, costcenter is not restricted, you should be able to display totals with : value.

      Reply
  • Hi Aninda,
    Thank you for the reply. The query itself is not restricting to those particular cost centers. With the analysis authorization object that I created, I can restrict what the user can drill down to w.r.t cost center. Our requiremet is that the user should see costcenter they are authorized to + the aggregate value. However, I am able to give them the cost center they can access; but for the aggregate totals they just see the total for the cost centers they are provided authorizations for.

    For example
    Costcenter Analysis Authorization-1
    EQ 1000
    EQ 2000
    EQ:

    The user can only see data for 1000, 2000 and for totals the total of 1000+2000. For total we are expecting that with the colon authorization, user should see 1000-9000 cost centers which does not seem to work. Is there anything our developer has to do to modify the query (w.r.t variable type used) as we are clueless what needs to be done to make this work.

    Thanks in advance
    Bindu

    Reply
    • Hi Bindu,

      The behaviour you are reporting is typical of the case, when you do restrict a characteristic at the query level. Can you please confirm that you are not using an authorization variable to restrict cost center at the query definition? if you are using an authorization variable, the query will only pull in data for 1000+2000 during execution.

      Regards,
      Aninda

      Reply
  • Thank you Aninda for the reply. Yes, the query does use an authorization variable for cost center. If we want the aggregate to show up in totals (for : authorization to work) what type of variable should be used?

    Thank you
    Bindu

    Reply
    • An authorization variable will just pull in actual values, not colon (:). As a result, you can not at the same time restrict a characteristic to values and expect it to return data for all cost center values.

      I can think of 2 options now. Create a new version of the query where cost center is not restricted by the authorization variable. Make sure that cost center is in the free characteristics. This query will not allow you to drill down on cost center.

      A second option will be to change the first query, so that it prompts you for the cost center during instead of just running with the authorized values. When you want to drill down you can restrict to actual values. To see totals, you run it unrestricted. I believe, you can set up authorization variables so that it suggests the possible authorized values instead of running for all.

      Reply
  • Vinuthan

    Hi Aninda,

    Can you please briefly explain about BI Security upgrade. I need to use migration tool(RESC_MIGRATION). Can you please provide more proactive approach for this BI Security upgrade.

    Reply
    • Aninda

      Hi Vinuthan,

      I have been involved in a few BW upgrades but nowhere was the migration tool used. I would accept that the tool can get you 80% of the way to a successful migration but the remaining 20% would still need to manually adjusted. If you decide to go for the tool, make sure you thouroughly go through the SAP documentation around it and the if any manual changes would be needed for you.

      Regards,
      Aninda

      Reply
  • jothi

    Hi,
    Thankyou for the helpful post.

    Can we use colon authorization and structural authorization at the same time. In our HR system we follow the structural auhtorization on 0orgunit. And for a particular requirement, i had to create colon on 0orgunit.

    My question is will the colon authorization overwrite the structural authorization in this case?

    Thanks,

    Jothi

    Reply
    • Aninda

      Hi Jothi,

      Structural authorizations are implemented in BI through a customer-exit variable. So the behaviour will be governed to a large extent by the code that’s put in the customer exit. I would suggest you take the help of an ABAP developer to check the code maintained for the exit and see if you can incorporate the colon (:) authorization at that point.

      Regards,
      Aninda

      Reply
  • Hi Aninda,

    We create 3 custom authorizations objects like ZBASIS, ZPRIVATE, ZFINAN from object 0EMPLOYEE.
    ZBASIS contains attributes from 0EMPLOYEE that everyone can see.
    ZPRIVATE contains sensitive data from 0EMPLOYEE that some of the user can see.
    ZFINAN contains sensitive data from 0EMPLOYEE that some of the user can see.
    We put all the Z* objects in free char. When we select one of the object in free char we got the authorization message that we need the value “*”. I expect to see “:”.
    Do you know the reason?

    Reply
  • Basically when we try to drag something from the free chars, the auth check is done with a * auth and since we have restricted the user with “:”, * does not go with it so it throws an auth error. Also the three Z* objects are authorization relevant.

    Reply
  • Hi Aninda,

    I have 3 custom Z* objects derived from 0EMPLOYEE.

    ZBASIS ,everyone have access.
    ZPRIV ,only certain ppl haves access to sensitive data.
    ZFIN, only certain ppl have access to sensitive data.

    I only turned on the “Auth. Relevant” flag for the three objects not for the attributes.
    I put the 3 objects in free characteristics(no variable created)

    When i drag the three objects from the free characteristics to the report. I got the error message “Not enough authorization”. I miss the authorization value “*” for ZFIN and ZPRIV.

    The user 1 may only see basis data got :

    ZBASIS -> “*”
    ZFIN -> “:”
    ZPRIV -> “:”

    The user 2 may only see basis en FIN data got :

    ZBASIS -> “*”
    ZFIN -> “*”
    ZPRIV -> “:”

    etc.

    Regards,

    WMLI

    Reply
    • Hi Wmli,

      The error messages that you have reported already give the correct answer. However I will re-iterate some of the points

      An unrestricted authorization relevant characteristic in the free characteristics of a query would require colon (:) value for it in an analysis authorization.

      When you are dragging a free characteristic to the rows area just colon will not be sufficient as you are drilling down on the characteristic . Colon is only meant to authorize access to aggregates not detailed values.

      In such a case, in addition to the colon you would need to restrict the characteristic to actual values through authorization variables or use (*) for the characteristic.

      Hope this works for you!

      Regards,
      Aninda

      Reply
  • Sorry for the double postings

    Reply
  • RSECADMIN does not exits in SAP 640

    I need to search role for the report provided by the user.

    Please help

    Baliram

    Reply
    • Are you using Analysis Authorizations or Reporting Auth Objects? Reporting Objects as used by the earlier security model in BW has its own tcodes.

      Reply
  • Lyubomir

    Your posts are great, really helpful, however I`ve searched all over the net and I was not able to find an answer to my problem.
    I`ve to create more than 500 Analysis Authorization (unfortunately this is the only option that we have in our company), is there a way, to create all the authorizations at one time. Some mass creation or something similar? I know that I can update the massively, but the options there are very limited.
    Probably a LSMW or could be created, but is there some standard sap functionality?

    Best Regards,
    Lyubomir

    Reply
    • Aninda

      Hi Lyubomir,

      To my best knowledge there is no standard tcode or such to mass create analysis authorizations in BW. If you can record a LSMW or SECATT script to do the job, I suggest going forward with that. I have used the same technique when I had to create or update analysis auths en mass.

      However, SAP provides a FM, RSEC_INSERT_FLAT_AUTH which can create analysis auths programmatically. You can ask a ABAP developer to write a wrapper program around this to read data from a file and execute this FM with the data.

      Thanks,
      Aninda

      Reply
  • Lyubomir

    Good day Aninda,

    Thank you very much for you answer, we will record a LSMW and we will use it for mass creation.

    Best Regards and thank you once again.
    Lyubo

    Reply
  • Dae Jin

    Hi Aninda,

    I have a requirement to restrict specific cost center from detail view but the keyfigure total should contain the value. It would look like this:

    Cost center Amount
    75000 $996,853
    75010 $354,005
    75020 *
    75030 *
    75040 $6,569,900
    75050 $1,567,113
    Overal Result $10,171,981

    You can back into the value of the 2 restricted cost centers to be $684,110 but it doesn’t show the individual value.

    I’ve tried many different configurations but because the security fails on 75020 and 75030 no values are returned just the failed auth message. Is there anyway around this and is the above doable within the bw security paradigm?

    I appreciate any input on this.

    Thank you,

    Dae Jin

    Reply
    • H Dae Jin,

      What you are trying to do can’t be done with standard SAP BW security. To show the cost centers in the detail view, you would have make sure that these values are authorized for the cost center characteristic. On top of this if you have access to the Amount key figure, it will show data for all the authorized characteristics. They choice you will have to make is to whether you want to give access to the two cost center values or not.

      Thanks,
      Aninda

      Reply
  • Hi Aninda,

    Thank you very much for nice explanation and forum.
    I have one query.I am new to BW security.I created role with S_RS_COMP and S_RS_COMP1 and added one report to the role.i have not assigned any analysis authorization in this role or directly to the user.Now when i am executing the query in the system it showing you have not authorized to Info provide Ztest1 with display access.Now my query is how can i get the analysis authorization which is having the Info provide in table level.Please can you provide some BW security table names.
    Thanks for your help. Regards,Surya

    Reply
    • RSECVAL table gives you the analysis authorizations already created with the values maintained in them.

      Reply
  • Siddharth K

    Hello Aninda,

    Thank you for all your posts.

    I am new to the BI 7.0 Analysis Authorization concept and your posts have helped me understand it better.

    My question is what is the /nsu53 equivalent transaction in BI 7.0 if we need to know which Anaylsis Authorisation (object/field) is missing in the user roles.

    Thanks once again.

    Regards,
    Siddharth

    Reply
  • chandra

    Hi Aninda

    For one user, I have a situation where we need to

    case 1:
    give access lets say 1,2,3,4 personnel areas for one Infoprovider 1 for query 1

    case2:
    and 1,2,3 personnel areas for infoprovider2 for query2 for the same user.

    I am thinking this can be solved by creating two analysis authorizations and assigning it to the same user in S_RS_COMP and then add query1,2 in S_RS_COMP1 in same role. I cant test it as sufficient data is not available in Dev.

    Can you please let me know if the solution is ok or if there is any alternate route.

    Thanks,
    Chandra

    Reply
    • Aninda

      Two analysis authorizations would be needed as you mention. However analysis auths are maintained in S_RS_AUTH. The query authorization would need to be added to both S_RS_COMP and S_RS_COMP1.

      Reply
  • Preethi

    Hi Aninda,

    We have a BI 7.3 security upgrade coming up and currently we are on BI 7.0, however using the reporting authorization concept.

    Now that we have to move to the new analysis approach, I have few steps to begin with , but again few queries on certain steps as this would be the first time I would be working on BI security. Please help me understand what needs to be done here.

    Step 1: Activate the authorization mode to “Current procedure with Analysis authorization” in the SPRO”… My query here is this has to be done before upgrade or afterwards

    Step 2: I hope we need to perform the SU25 upgrade here( not sure, please clarify)

    Step 3: Building Analysis authorization: Do we have to activate the 3 special characteristics i.e. 0TCAVALID, 0INFOPROV … ?? or is it by default auth relevant

    Step4: Because we have all the reporting Roles in place and working fine, we are thinking of redesigning the data for the queries of these Roles to the new concept.. Is this fine to go with??

    Step 5: While redesigning these Roles , we need to check for the infoproviders that provide data for the queries in these Roles and restrict the data accordingly in the Analysis authorizations… Now in our case when I analysed one Role which was providing some finance related reporting I got quite a few infoobjects that were auth relevant, but I am unable to find out how the data access was provided to these in the existing process as they do not have any custom objects which provides data.

    What would be the right approach to deal with this?? Do I need to consult the BI development TEam or is there any way where I can find out from the system as to how the user is trying to access data especially some org field related ones.

    Step 6: Restrict access based on either value or hierarchy authorizations. Is this again the BI development Team who would be suggesting us??

    Step 7: Add these analysis authorizations in the Role and provide access to the user, test it and move it to further environments.

    Please help me in understanding these.

    Regards,
    Preethi

    Reply
    • Aninda

      Hi Preethi,

      Thanks for the extra long question. However I am very doubtful about how much help I can provide you here. An upgrade from reporting to analysis auths is a big event and can prove challenging for seasoned security consultants. My first suggestion is to get some real help from folks around you. Next look at SAP documentation about the steps involved in an upgrade. This is far too important a subject to base your actions on my website.

      I will still try to answer a few of the questions

      Step 1: Activate the authorization mode to “Current procedure with Analysis authorization” in the SPRO” – Can be done after Basis upgrade has been completed.

      Step 2: I hope we need to perform the SU25 upgrade here( not sure, please clarify) – SU25 is a big subject in itself. Its probably not going to make a huge difference with reporting but ideally SU25 should be performed after each upgrade of the system.

      Step 3: 0TCAVALID, 0INFOPROV – check these in RSD1 after the upgrade. I believe you will have to set them to auth relevant

      Step 4: Ideally the upgrade should be transparent to the end users. So queries should remain the same and the roles need to be updated with new authorizations. However if you to re-write some queries as part of the upgrade, thats fine too.

      Step 5: You need to get some help in how to analyze BW security. This site can provide a start but some of it just comes out of experience. SAP has a good training program for BW security – BW 365. Try if you can go for it.

      Step 6: Restrict access based on either value or hierarchy authorizations – How does security work currently? Both were supported as part of the reporting authorization.

      Step 7: Once the authorizations are built, added to roles, tested you would need to move both the roles and the analysis auths to production.

      I will end by re-iterating that if this is indeed your first BW project, get help from someone who has actual experience with an upgrade.

      Thanks,
      Aninda

      Reply
  • Preethi

    Hi Aninda,

    Thanks a lot for your patience and prompt reply.. Sure we would look for someone who has actual work experience and start it 🙂

    Regards,
    Preethi

    Reply
  • Hi Aninda,

    where are you ?

    Reply
    • I am fine Ramesh. How are you?

      Reply
  • Hello, i’m new in SAP BW and i’m in migration process to the new authorization concept.

    Here is what happening:

    I have a role with all access to a company (*) of a provider X.
    I have another role with restricted access to a company (ex: COMPANY1, COMPANY2 and COMPANY3) of a provider Y.

    When i attribute those 2 roles to a user and access a query of the provider Y, i can see all the companies when it was supposed to only see the 1, 2 and 3.

    What am i doing wrong?

    Thank you in advance.
    João Gonçalves

    Reply
    • Aninda

      What does the authorization trace in RSECADMIN say? There might be a third authorization which is resulting in the extra access. The trace will tell you what all is happening behind the scenes.

      Reply
  • hi Aninda,

    How to set authorization relevant flag for 0TCAACTVT,0TCAVALID, 0INFOPROV in RSD1 .In my system i found it in uneditable mode.

    Reply
    • Aninda

      Do you have security for changing these settings? Since these are InfoObjects, this is better done by a BI developer rather than a security person.

      Reply
  • Hello ,

    Thanks for details .Well explained.

    Can anyone please tell me how we can maintain the Authorization Values in Production ?
    As the values in PROD system are quiet different from the volumes and data in DEV . i have requirement to restrict on Hierarchy and i might need to change it in the Authorization values from time to time and can be done only in Production as i dont have the same Hierarchy in DEV.

    Can anyone please help on how i can maintain the Auth values in Production system directly ?

    Regards
    Ram

    Reply
    • Aninda

      If you are using hierarchies, you need to ensure that the hierarchies are maintained the same throughout the landscape or at least the top level nodes are present. Once these nodes are present you should modify your analysis auths in dev and transport to prod. Directly maintaining this in production is a very bad idea.

      Reply
  • I have two questions.

    – Is there a difference between assigning multiple info objects to the same analysis authorization object, versus, assigning each to it’s own analysis authorization object (other than the obvious need to add one vs multiple objects to S_RS_AUTH)?

    – Once an analysis authorization is generated, it will no longer let me modify it. Is there a way to get around this?

    Reply
    • Aninda

      Ans 1 – No difference in the two approaches except in the design philosophy.
      Ans 2 – Maybe you have create access for S_RSEC and S_DEVELOP but not change

      Reply
  • Hi Aninda
    what are the authorizations required for end user to execute analysis authorization,if it is assign to directly to user via rsecdamin

    Reply
  • Hi Aninda,
    I need your help in understanding the below issue.. If two AA’s provides access to one infoprovider say XXX which is used in query say YYY.. So when executing a report or a query the two AA’s maintained with XXX info provider must be checked right.. Here comes a question..
    AA 1 has sales credit restricted with some values and : whereas AA2 has * in sales credit.. So whether * access will be replaced by restricted actual values present in another AA??
    FYI—sales credit is maintained as free characteristic and drill down is done what will happen and what is the appropriate solution.

    Awaiting for your reply!!

    Reply
    • The combining/merging of two or more analysis authorizations follows a complicated logic. There is a SAP note which talks at length about the merging of analysis authorizations. Ideally, * should override : and give full access to the characteristic. However, you have to think of not just sales credit but also any other authorization relevant characteristics that are present in the infoprovider and how all these authorization relevant characteristics have been maintained in the analysis authorizations which will determine what data is accessible in the reports.

      Reply
  • Hi Aninda,

    I have a scenario where I need to compare and verify if the version in PRD and dev is the same version..

    How can we do this verification.

    Regards
    Chandra

    Reply
    • I am referring to comparison of versions of analysis authorizations between PRD and dev

      Reply
      • You can check the timestamps of the analysis authorizations between production and development. The other option would be to compare the entries for the analysis authorizations in RSECVAL table. I believe this table stores the actual entries made in the analysis authorization.

        Reply
  • Tanya

    Hi,

    I have a scenario where I want to restrict my AA at vendor Code, we have a characteristic 0Vendor where I have provided my specific vendor code values like EQ A63930
    EQ B09970 EQ B64800 However when I am trying to run the query I am getting data only for vendor code A63930 and not for other two vendors…can you please suggest did I need to change anything?

    Reply
    • The first thing to check would to be see if there is any data for the other vendors. Secondly even if the other vendor have data, it is likely that there are other vendor attributes which are authorization relevant (e.g. 0COMPANY_CODE) which is not authorized.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *