Skip to Content

HANA Schema User and Role Security

Welcome again to my series of blogs on Users/ Roles / Security. In this blog, I am going to showcase how to create users and roles

(read only and read & write) and how to assign these roles to a user.

First we need to have a SCHEMA where we can assign these roles to certain users. The owner of the schema or someone with owner privileges of the schema should be able to accomplish this task.

I started by going to the documentation and ran the statement below a few times (this works but there is an easier and more manageable way to accomplish the task) please go to Secondly for a better way


Secondly, we will need to create the roles and assign   a) read access to the schema  and   b) read/write access to the schema.

This is the READ ONLY Role


This is the READ/WRITE Role


Thirdly, we need to create the users (if not existent) and assign such roles to their Granted Roles tab


Finally, we will test these scenarios for the READ ONLY User


and now the same tests with the Read/Write user (and role)



and verify that it works ( Rows affected: 1)

Thank you again for reading this blog. This is all for my user security blog.

Please share your experiences and/or questions.

You must be Logged on to comment or reply to a post.
  • Hi Sergio,

    what additional value adds this blog post to the community beside the available of course more detailed documentation, other blog posts here and the many available SAP HANA Academy videos regarding this topic?

    What I would expect are more detailed information on paint points you had during your projects. What are the pain points and what are the pitfalls?



    • Florian,

      this is a great point... before I answer your question, let me take a step back and mention that I am working on a demo which requires this type of security plus another types (next blog in my series) Regarding your question about pain points, I wanted to address my demo and capture screenshots for my scenarios as well as hoping to help others with similar issues. I am sure there is tons of materials on scn, youtube, openSAP, etc. however, I always depended on the db admins, or someone else with such privileges to get this accomplished. This blog is from my own experience and also showcasing the simplicity of the exercise. It will make more sense on my next blog what the complexity of the next security points are.

      Some of the pitfalls include the understanding of how schemas, roles and users and finding the documentation in the vast amount of official documentation. It may all be documented but depending on the topic, there may be a looooot out there as you probably agree with me on this one.

      I am hoping that others having similar issues could ask more questions such as yours.. and thanks for it. Please let me know if I need to clarify any other points. Have a great one.

      • aThat is the problem. That blog just describes a very little simple piece out of a big and important area. Why not giving the people the chance to find the right starting point. For example some people would ask which rights are necessary to create roles in the security area or more simple how they create the roles (either in HANA studio or in the web based tooling). I think we have a different understanding here. But as a colleague from the ABAP space would say: "It is worth 10 points" 😉 .

  • Hi Sergio and Florian

    Good discussion of this blog post and I think both of you have valid points.

    I agree with Florian that the depth and extent of how the topic had been addressed in the blog post is not advanced. Indeed it only scratches the surface and there are a lot more information on security mechanisms and best practices available.

    And for a good posting I'd wish that this material would have been considered. SCN does have a rather high standard when it comes to publishing information and knowing what's available is an important part of that.

    On the other hand this is not a piece of documentation and I see that there is a lot of potential to tell the story more from a personal experience point of view - just as you, Sergio, explained it in the comments.

    Personally I like to think of blogs as travel diaries and documents as maps.

    When you write a new map (explaining the technology, the techniques, ides, concepts, etc.) we want accurate, new information. Something that makes the new map better than the old maps or brings additional information in a way that makes it easy to understand. It should help the reader of the map to do the job and to get ahead in the journey. If it does that, it's a good map.

    From a travel diary however, I don't necessarily expect that. If it contains technical information, all good, but what I am really interested in is how the journey went. What surprises were found on the way and what mistakes had been made? If the travel diary/blog post makes me see a different point of view or makes me want to go on a journey myself, that's a good one then.

    And for that it's completely fine if the author doesn't see the end of the journey just yet.

    So, if this blog post would contain more of the personal experience (the journey) part, I believe this could make a really nice blog post instead of a really not great piece of documentation.

    Hopefully, this analogy makes sense and we get to read more from your journey as a SAP HANA developer Sergio!




    Just a caveat: it's easy and quite common to go and announce a whole series of blog posts. Truth is: that often doesn't happen. In the sense of Mr. Torvalds famous quote: Talk is cheap...

    • thanks Lars for your comments and I totally agree with your comments.. please see my next blog regarding the row level security sharing my experiences, learnings, and struggles