Open Chief-Rishab opened 2 years ago
@ravisuhag @AkarshSatija @bsushmith @singhvikash11 @rahmatrhd
Problem
Github differs from the other providers we already have in guardian currently. According to the current flow in guardian, whenever the approver approves the appeal the user requesting for the resource is directly added to the authorised member's list. Unlike that, in Github the user receives an invite to join the repository/organisation, so once the appeal is updated to an active
state in guardian, the user is not yet added to the authorised member's list on the provider. This problem will remain in all other providers which have an invite based flow.
Proposed Solution:
In continuation with the yesterday's discussion to decouple the appeal and access, in this issue https://github.com/odpf/guardian/issues/246, @rahmatrhd and I think adding another state called pending
in status field might solve this problem.
type Access struct {
ID string
- Status string // active | revoked
+ Status string // pending | active | revoked | canceled/ignored
AccountID string
AccountType string
ResourceID string
Permissions []string
ExpirationDate *time.Time
AppealID string
RevokedBy string
RevokedAt *time.Time
RevokeReason string
CreatedAt time.Time
UpdatedAt time.Time
}
For all the provider which will have a direct access, this pending state will be skipped. For an invite based approval the pending state holds true. We will also have to make an API to see if the user have accepted the invite or not to proceed to the active state of access.
Access:
+ 1. pending
2. active
+2. canceled/ignored
3. revoked
for a case when the invitation is not accepted by the user, we might need another access status called canceled
/ignored
@rahmatrhd yes, was thinking to add that. Should we rename pending
to invite_sent
or invite_pending
to sound more precise? And if the invite isn't accepted, we might introduce another state called invite_expired
@Chief-Rishab we need to think of statuses of irrespective of github though.
@ravisuhag we're assuming the invitation-based membership might be common for other providers (need to validate further). That aside, IMO pending
and canceled/ignored
statuses still can be relevant to access
even though not every provider needs them
Github/Gitlab (and other public SAAS based platforms) do not expose the user email to public by default. Currently we were only using the user email to grant/revoke access to the resources in Guardian since all those private SaaS providers had option to work with user email.
The APIs in Github/Gitlab are using the userID/username
to grant/revoke membership and it is not always possible to retrieve them with the /GET user
APIs unless the user have made his email public.
To counter this problem, we propose to get the username/userID
in appeal
on Guardian itself.
For example if I want to be added as a contributor on a Github repository in ODPF
then, I will be required to pass my username(Chief-Rishab) in the Appeal
body (or in custom appeal questions on Datlantis). This will become a generic case for other providers later which do not expose the user emails to public. @rahmatrhd @ravisuhag @AkarshSatija
Summary We need to support access management of Github
Proposed solution