Appeal request on behalf of other user.

[singhvikash11]

Summary As a user, they want to raise an appeal for another user in Guardian. This could help the manager/supervisor to raise all access-request for a user and sometimes this access request is for integration account to other systems like metabase, tableau etc.

Proposed solution Allow the appeal-request flow to get another user's email as input. Will trigger the approval flow for giving another user and send appeal notification to both users(in case it's a non-human account).

[singhvikash11]

@rahmatrhd @ravisuhag currently guardian doesn't allow the creation of appeal for another user and this is checked here.

IMO, this should be part of policy where an org can define they should/shouldn't create an appeal on behalf of another user. The sample policy will look like this:

id: allow_create_appeal_for_other_user steps:

name: create_appeal_for_other_user_check description: appeal will be rejected if its creating for other individual strategy: auto approve_if: $appeal.account_type == "user" && $appeal.created_by == $appeal.account_id

Guardian will check whether it's creating an appeal for another individual based on created_by == account_id and handle the notification for both users.

cc @bsushmith @utsav-agarwal

@rahmatrhd @ravisuhag wdyt?

[ravisuhag]

@singhvikash11 Can you document how it will change the contract of appeal? Are you proposing that create_appeal_for_other_user_check this step will only be needed when admins want to disable the appeal creation on behalf of other users?

[singhvikash11]

@ravisuhag yes, As an admin they should be able to add this check as part of the approval flow instead of its default check-in guardian appeal service.

id: sample_policy
steps:
  name: bigquery_resource_check
    description: appeal will be rejected if its for other than bigquery
    strategy: auto
    approve_if: $appeal.resource.provider_type == "bigquery"

  name: create_appeal_for_other_user_check
    description: description: appeal will be rejected if its creating for other individual
    strategy: auto
    approve_if: $appeal.account_type == "user" && $appeal.created_by == $appeal.account_id

  name: manager_approval
    description: approval from manager
    strategy: manual
    approvers:
       $appeal.creator.manager_email 

[rahmatrhd]

Instead, we can just have an enable/disable flag in the policy to allow users to create an appeal for another user to make it more straightforward.

Also other things to note:

1. user details in creator field right now is based on the created_by field. Need to make it based on account_id if the appeal is created by a different user
2. notifications target

[ravisuhag]

@rahmatrhd Will this config be a root level config at the policy? Can you give an example of how the policy would look like this with the flag?

@singhvikash11 Can you update the issue with details of changes that would be needed to tackle the points mentioned by @rahmatrhd

[rahmatrhd]

  id: my-policy
  version: 1
  steps: []
+ appeal:
+   allow_cross_individual_user: true

we can think of a better name

[singhvikash11]

@rahmatrhd IMO, user details in the creator field should be based on the created_by field. Creator owns the lifecycle of this appeal. We only need to notify another user about the appeal creation, appeal approval, or appeal revoke.

@ravisuhag In this case, the changes are only on the notification side. The notification module needs to check whether an appeal is for another individual and if yes then It'll send an additional notification to that individual account id(email field).

[ravisuhag]

Yes, Creator i think should always be the person who created appeal and created_by id should be of appeal creator. We can think of a different of capturing on whose behalf the appeal is being raised.

[singhvikash11]

@rahmatrhd @ravisuhag This one is finalized then, we can start the dev on this. The approach is:

• Create a config in policy to enable/disable cross-user appeal creation.
• If the cross-user appeal is enabled and the creator and appeal's account_id are different then Guardian will allow creation of appeal just like service account.
• In case of cross-user appeal, Guardian will send an additional notification to appeal's account_id.
• These other individuals should be able to see these requests and be able to renew the appeals.

[rahmatrhd]

1. should the account_id user be allowed to cancel the appeal as well?
2. need to extend duplicate appeal logic as well. example: if user A created an appeal for user B, and then user B also created a new appeal to the same resource himself, user B should receive a duplicate error
3. the policy documentation also needs to be made clear that $appeal.creator might not always be the person who accesses the resource

[ravisuhag]

Update: Creator will own the entire appeal lifecycle and appeal will not show in account_id's appeals.

Later Guardian will provide a context of resources which user have access to provide information to user who is getting access. This will also provide history of past access and revocation to the user on a given resource.