You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by Mandy Chessell <ma...@uk.ibm.com> on 2018/02/14 18:06:14 UTC
Metadata security policies examples
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_chessell@uk.ibm.com
LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49
Assistant: Janet Brooks - jsbrooks12@uk.ibm.com
Re: Metadata security policies examples
Posted by Graham Wallis <gr...@uk.ibm.com>.
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_wallis@uk.ibm.com
IBM Laboratories, Hursley Park, Hursley, Hampshire SO21 2JN
Tel: +44-1962-815356 Tie: 7-245356
From: Madhan Neethiraj <ma...@apache.org>
To: "dev@atlas.apache.org" <de...@atlas.apache.org>, Nixon Rodrigues
<nr...@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" <ma...@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_chessell@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 - jsbrooks12@uk.ibm.com
From: Madhan Neethiraj <ma...@apache.org>
To: "dev@atlas.apache.org" <de...@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.scott@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" <ma...@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_chessell@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 - jsbrooks12@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
Posted by Madhan Neethiraj <ma...@apache.org>.
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" <ma...@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_chessell@uk.ibm.com
LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49
Assistant: Janet Brooks - jsbrooks12@uk.ibm.com
From: Madhan Neethiraj <ma...@apache.org>
To: "dev@atlas.apache.org" <de...@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.scott@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" <ma...@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_chessell@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 - jsbrooks12@uk.ibm.com
Re: Metadata security policies examples
Posted by Mandy Chessell <ma...@uk.ibm.com>.
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_chessell@uk.ibm.com
LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49
Assistant: Janet Brooks - jsbrooks12@uk.ibm.com
From: Madhan Neethiraj <ma...@apache.org>
To: "dev@atlas.apache.org" <de...@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.scott@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" <ma...@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_chessell@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 - jsbrooks12@uk.ibm.com
Re: Metadata security policies examples
Posted by David Radley <da...@uk.ibm.com>.
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 <ma...@apache.org>
To: "dev@atlas.apache.org" <de...@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.scott@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" <ma...@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_chessell@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=QhpUQPr5YlG95aAgCvZGStEXHg4hBbSYQ9JkRqR_svY&m=Qa-FKldwlfxLK0OygoMR9IopavMa6ccJ81Xtg4l11cs&s=20HZiMDEZtwudUrz9j12W32Kb8AklTGhbNDPAg5AN6s&e=
Assistant: Janet Brooks - jsbrooks12@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
Posted by Madhan Neethiraj <ma...@apache.org>.
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.scott@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" <ma...@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_chessell@uk.ibm.com
LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49
Assistant: Janet Brooks - jsbrooks12@uk.ibm.com