Add support for Github provider

[Chief-Rishab]

Summary We need to support access management of Github

Proposed solution

• [ ] Provider configuration for Github
• [ ] Github client
• [ ] Github resource & access management (TODO: figure out what resources that need to be granted & revoked)
• [ ] Documentation

[Chief-Rishab]

@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

[rahmatrhd]

for a case when the invitation is not accepted by the user, we might need another access status called canceled/ignored

[Chief-Rishab]

@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

[ravisuhag]

@Chief-Rishab we need to think of statuses of irrespective of github though.

[rahmatrhd]

@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

[Chief-Rishab]

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