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
GRANT [DELETE|UPDATE|INSERT] ON SCHEMA MYSCHEMA TO SOMEUSER WITH GRANT OPTION;
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.
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?
Regards,
Florian
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" 😉 .
I think I will address some of those points on the next blog 🙂 and yes it is worth it 10 points, totally agree
Just to clarify: That with the points was ironic. Don't like point cheating.
so everything that SAP has documented should be considered the same? again, I think most of the main question you have will be answered on the next blog which is my paint point
but I need some background in order for the next one..
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!
Cheers,
Lars
p.s.
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
as mentioned yesterday, here is the next blog of the series