Mandy, > Which entity types do not have the createdBy attribute - it looks like it is > a standard attribute of AtlasEntity You are right. All entities have a built-in attribute named 'createdBy'. This field is populated with the username of the logged-in user, when an entity is created in Atlas.
Ranger authorization allows granting permissions for resource-owners; to enable this, the component needs to provide the 'owner' name along with the authorization request. Ranger Atlas authorizer can supply the 'owner' name from 'createdBy' field. Perhaps we can support this in default authorizer implementation as well. @Nixon Rodrigues - can you please review the details? Thanks, Madhan On 2/16/18, 5:31 AM, "Mandy Chessell" <[email protected]> wrote: Hello Madhan, Which entity types do not have the createdBy attribute - it looks like it is a standard attribute of AtlasEntity? Is this not always set? I could see it being blank for a non-logged on user - but I would hope in a secure environment, they would need to be logged on to create metadata? I agree the user Id normalization should be pushed out - in fact not even part of Atlas - more an issue for the security service managing the signon. If a person has two accounts with different user Ids then they should get different access. It would be more flexible to allow a small group of people to edit each instance (entity/relationship). But it is a lot of work to set up. So I was suggesting a default policy of only allowing editing by the creator of the instance and then allow that individual to augment that access with other names. The reason this default policy works for so many governance use cases is that many of the non-asset metadata instances such as comments, likes, the stewardship actions, policies etc are limited to the creator - so that people are accountable for the metadata they create - and the metadata instance records their actions/decisions. Where metadata instances are created through automated processes, we do not want these instances to be editable by any userId other than the engine's userId because the edits could be over-written the next time the automated process runs. There are some metadata instances that are editable by a small team - such as glossary terms and categories - and these would be cases where the team sets up their access by effectively overriding the default policy. All the best Mandy ___________________________________________ Mandy Chessell CBE FREng CEng FBCS IBM Distinguished Engineer Master Inventor Member of the IBM Academy of Technology Visiting Professor, Department of Computer Science, University of Sheffield Email: [email protected] LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49 Assistant: Janet Brooks - [email protected] From: Madhan Neethiraj <[email protected]> To: "[email protected]" <[email protected]> Date: 16/02/2018 02:23 Subject: Re: Metadata security policies examples Mandy, > edit access is limited to the user identified in the createdBy property. It will be possible to support authorization as above. However, there are few issues to be aware of in such approach. For example: - 'createdBy' property may not be present in all entity-types - the username in 'createdBy' property might have to be normalized or mapped, to be able to compare with the username logged into Atlas. - for example [email protected] vs jscott I would recommend to handle such username normalization/mapping in a later phase. > where a classification can only be added to an entity by a user that has edit access to the entity. > where a classification can only be added to any entity by a user with create rights on the classification. Wouldn't it be more flexible to allow different set of users to edit and classify entities? Similar to the following scenario. > where edit access to an entity is required before a relationship can connect it to something else > and it would be good from a graph decoupling point of view if adding relationships could be done independently of the access rights to either entity. I agree on decoupling authorization to create relationship from access rights to the entities at both ends. Thanks, Madhan On 2/14/18, 10:06 AM, "Mandy Chessell" <[email protected]> wrote: Hello Madhan, I was thinking through our common use cases for metadata security. For most metadata entities and relationships, we would want to enforce that metadata is readable by logged on users but edit access is limited to the user identified in the createdBy property. Then we have special cases for entities such as connections and some governance actions. For example there may be a connection to an audit log and that can only be seen by members of the security team since having access to the connection means you can connect to the data store. Some governance actions may be updateable by anyone in the governance team - not just the creator. When it comes to classifications, we have 2 scenarios - where a classification can only be added to an entity by a user that has edit access to the entity. - where a classification can only be added to any entity by a user with create rights on the classification. I was trying to think through similar examples for relationships - for example, where edit access to an entity is required before a relationship can connect it to something else - but I can't think of one - and it would be good from a graph decoupling point of view if adding relationships could be done independently of the access rights to either entity. All the best Mandy ___________________________________________ Mandy Chessell CBE FREng CEng FBCS IBM Distinguished Engineer Master Inventor Member of the IBM Academy of Technology Visiting Professor, Department of Computer Science, University of Sheffield Email: [email protected] LinkedIn: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_pub_mandy-2Dchessell_22_897_a49&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=DEupm0k8-ppAmw6rImSmuE_tc4KzDG1cSUr7Fo_5T8Q&m=nvlE5hlOgcowVGw5D0cPIkp-b9aqUABRluGGJVremkA&s=7Z97U83-B6EaZITCvY1N52wH-IJE5ya1nKAAKhP_Ekc&e= Assistant: Janet Brooks - [email protected]
