Hi Madhan, My thoughts on the 3 points are : 1) It would seem to me that we should have one way of identifying users at the metadata layer and any normalisation or mapping should be done prior to this so that users are uniquely identified in an organization in the policy / metadata layer.. 2) You say "Wouldn't it be more flexible to allow different set of users to edit and classify entities? Similar to the following scenario." I think it is not an 'or ' situation but an 'and'. I think it is beneficial to restrict based on a list of users as you suggest. It is also useful to be able to have some principles as Mandy suggests, so if you have certain access rights then you get other access rights by virtual of a policy. Having these principles expressed in policies means that the policies can be simpler and more naturally expressed. 3) Agreed.
all the best, David. 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=QhpUQPr5YlG95aAgCvZGStEXHg4hBbSYQ9JkRqR_svY&m=Qa-FKldwlfxLK0OygoMR9IopavMa6ccJ81Xtg4l11cs&s=20HZiMDEZtwudUrz9j12W32Kb8AklTGhbNDPAg5AN6s&e= Assistant: Janet Brooks - [email protected] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
