First, if the user is new to your OSDU instance, they will need to be added to the AWS Cognito User Pool. This is a manual process that can be done by someone with appropriate permissions in the AWS account where the OSDU instance is deployed, or by 47Lining support staff.
https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users.html
Data and Service access privileges in OSDU are managed by the Entitlements Service. User permissions are added and deleted with the groups API endpoints. See https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/blob/release/0.7/docs/tutorial/Entitlements-Service.md for a complete description of how to use those endpoints.
Here is a list of all the entitlements groups set up during deployment of your OSDU instance, as of the v2021-05-24 release of the 47Lining Enterprise PaaS - Preview Deployment
: curl --request GET \
--url https://$DOMAIN/api/entitlements/v1/groups \
--header "authorization: $BEARER_TOKEN" \
--header 'content-type: application/json' \
--header 'data-partition-id: opendes' |
jq -r '.groupNames[]' |
sort
data.default.owners
data.default.viewers
service.delivery.admin
service.delivery.creator
service.delivery.editor
service.delivery.user
service.delivery.viewer
service.entitlements.admin
service.file.admin
service.file.creator
service.file.editors
service.file.user
service.file.viewers
service.indexer.admin
service.indexer.creator
service.indexer.editor
service.indexer.user
service.indexer.viewer
service.ingest.admin
service.ingest.creator
service.ingest.editor
service.ingest.user
service.ingest.viewer
service.legal.admin
service.legal.creator
service.legal.editor
service.legal.user
service.legal.viewer
service.policy.admin
service.policy.creator
service.policy.editor
service.policy.user
service.policy.viewer
service.schema-service.editors
service.schema-service.viewers
service.search.admin
service.search.creator
service.search.editor
service.search.user
service.search.viewer
service.storage.admin
service.storage.creator
service.storage.editor
service.storage.user
service.storage.viewer
service.unit.admin
service.unit.creator
service.unit.editor
service.unit.user
service.unit.viewer
service.workflow.admin
service.workflow.creator
service.workflow.editor
service.workflow.user
service.workflow.viewer
users.datalake.admins
users.datalake.editors
users.datalake.ops
users.datalake.viewers
To give a user "Admin" entitlements, an existing Admin would invoke a POST request like this for each of the groups shown above
: curl --request POST \
--url https://$DOMAIN/entitlements/v1/groups/$GROUP@$DOMAIN/members' \
--header 'authorization: $BEARER_TOKEN' \
--header 'content-type: application/json' \
--header 'data-partition-id: opendes' \
--data "{ \"email\": \"$USER_EMAIL\", \"role\": \"OWNER\" }"
To give a user "read-only" entitlements, an Admin would use the same members endpoints, but only for the list of groups that have "user" or "viewer" in their name, and "role":"MEMBER" in the --data argument.
: curl --request POST \
--url https://$DOMAIN/entitlements/v1/groups/$GROUP@$DOMAIN/members' \
--header 'authorization: $BEARER_TOKEN' \
--header 'content-type: application/json' \
--header 'data-partition-id: opendes' \
--data "{ \"email\": \"$USER_EMAIL\", \"role\": \"MEMBER\" }"
To find which entitlements a given user has, one would submit GET requests to all the members endpoints
: curl --request GET \
--url https://$DOMAIN/entitlements/v1/groups/$GROUP@$DOMAIN/members/$USER_EMAIL' \
--header 'authorization: $BEARER_TOKEN' \
--header 'content-type: application/json' \
--header 'data-partition-id: opendes'
Likewise, a user's entitlements can be removed with a sequence of DELETE requests to the members endpoints.
: curl --request DELETE \
--url https://$DOMAIN/entitlements/v1/groups/$GROUP@$DOMAIN/members/$USER_EMAIL' \
--header 'authorization: $BEARER_TOKEN' \
--header 'content-type: application/json' \
--header 'data-partition-id: opendes'
0 Comments