Hi Madhan, With regard to the OMRS connectors, I have been generally using the userId parameter to the OMRS connector API, to set the createdBy field (of the OMRS and/or Atlas typedef or instance) prior to calling Atlas to add that object to the repository. Is this OK or should I instead be letting Atlas set the createdBy field, e.g. by using the supplied userId to establish a request context (in Atlas) as indicated by the additional lines marked with ***** below:
public EntityDetail addEntity(String userId, ... ) { ... RequestContextV1 requestContext = RequestContextV1.get(); // ***** requestContext.setUser(userId, null); // ***** ... AtlasEntity atlasEntity = new AtlasEntity(); ... // initialization of atlasEntity not shown entityStore.createOrUpdate(new AtlasEntityStream(atlasEntity), false); ... Thanks and best regards, Graham Graham Wallis IBM Analytics Emerging Technology Center Internet: graham_wal...@uk.ibm.com IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN Tel: +44-1962-815356 Tie: 7-245356 From: Madhan Neethiraj <mad...@apache.org> To: "dev@atlas.apache.org" <dev@atlas.apache.org>, Nixon Rodrigues <nrodrig...@hortonworks.com> Date: 12/03/2018 08:05 Subject: Re: Metadata security policies examples 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" <mandy_chess...@uk.ibm.com> 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: mandy_chess...@uk.ibm.com 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=Li6zJa6pLsu8dGS1GSW1j00glumVmLp0H5HVkn5QyAA&m=sWs19f60bqWtQh7czm06n-iaSjFGJu37aV9vOXbufzM&s=1eYXJ4LahASqlzk8JOuYMLI0XC73em62AvZOwmUAScU&e= Assistant: Janet Brooks - jsbrook...@uk.ibm.com From: Madhan Neethiraj <mad...@apache.org> To: "dev@atlas.apache.org" <dev@atlas.apache.org> 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 john.sc...@example.com 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" <mandy_chess...@uk.ibm.com> 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: mandy_chess...@uk.ibm.com 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 - jsbrook...@uk.ibm.com 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