Re: Metadata security policies examples

[Madhan Neethiraj]

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: http://www.linkedin.com/pub/mandy-chessell/22/897/a49

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

Re: Metadata security policies examples

[Mandy Chessell]

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: http://www.linkedin.com/pub/mandy-chessell/22/897/a49

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

Re: Metadata security policies examples

[David Radley]

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 <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=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=QhpUQPr5YlG95aAgCvZGStEXHg4hBbSYQ9JkRqR_svY=Qa-FKldwlfxLK0OygoMR9IopavMa6ccJ81Xtg4l11cs=20HZiMDEZtwudUrz9j12W32Kb8AklTGhbNDPAg5AN6s=

 
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

Re: Metadata security policies examples

[Madhan Neethiraj]

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"  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: http://www.linkedin.com/pub/mandy-chessell/22/897/a49

Assistant: Janet Brooks - jsbrook...@uk.ibm.com

Metadata security policies examples

[Mandy Chessell]

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: http://www.linkedin.com/pub/mandy-chessell/22/897/a49

Assistant: Janet Brooks - jsbrook...@uk.ibm.com