You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 10, 2023. It is now read-only.
Github organisations are supported for deploying applications, and any user who is a public member of an organisations that's in the customers file can see the organisation's dashboard and the organisation's functions in their dashboard.
However, The user that's a member of the organisation needs to also be in the customers list to be able to authenticate through the Github OAuth integration.
For example. I create an org called MyOrg, add myself to the organisation in Github and set my visibility to public.I add MyOrg to my customer's file.
I would be able to install the github app for the organisation, set repositories to be built and deployed.
I would not be able to login to OFC to see the dashboard with information about those functions. I would need to separately add my own Github username to the customers file to be able to authenticate.As soon as I am in the customer's file I get access to the Organisation's dashboard and organisation functions listed on my dashboard.
The use case is:
I have an OFC installation for my company, I manage access to github repositories through a Github Organisation. I would also (currently) need to keep the Customers file up to date with Githu usernames of the people in my company.
If people left, their github username doesn't disappear as it's a personal profile. Unless I take extra actions to change the customers file for any/all clusters I have setup the user still has access to the OFC installation and can add repositories to build and deploy into those clusters.
Additionally, this would allow organisations to limit the repositories that can be added to the cluster. At the moment, any user that has a line in the customer file can create new deployments into the cluster. Users in an organisation could have limited permissions where they are not able to create repositories, or add integrations. This proposal would allow an operator to limit the code that could be run on the cluster.
Expected Behaviour
An Organisation added to the customers file will allow public members of that organisation to authenticate with the cluster through the OAuth application (Github)
Current Behaviour
A user needs to also individually be in the Customers file as the organisations they belong to.
Possible Solution
We are able to get a list of organisations a user is a public member of, we already get this information and include it as a claim on their JWT.
We could also check in this field to see if any of the user's organisations are in the customer's file.
Context
Managing users in Github is already part of the onboarding/offboarding for a user, additionally remembering that any usernames in the OFC Customers file can authenticate and setup deployments into the cluster is additional burden for an operator.
The text was updated successfully, but these errors were encountered:
alexellis
changed the title
[Feature request] Support Github Orgs as Customers in edge-auth
[Feature request] Support GitHub organizations as Customers in edge-auth
Mar 4, 2020
Then you have more control and can control it from github. If you also check if level you have in the team then you can perhaps give read access to some of the members and deploy to other in that team.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Github organisations are supported for deploying applications, and any user who is a public member of an organisations that's in the customers file can see the organisation's dashboard and the organisation's functions in their dashboard.
However, The user that's a member of the organisation needs to also be in the customers list to be able to authenticate through the Github OAuth integration.
For example. I create an org called MyOrg, add myself to the organisation in Github and set my visibility to public.I add
MyOrg
to my customer's file.I would be able to install the github app for the organisation, set repositories to be built and deployed.
I would not be able to login to OFC to see the dashboard with information about those functions. I would need to separately add my own Github username to the customers file to be able to authenticate.As soon as I am in the customer's file I get access to the Organisation's dashboard and organisation functions listed on my dashboard.
The use case is:
I have an OFC installation for my company, I manage access to github repositories through a Github Organisation. I would also (currently) need to keep the
Customers
file up to date with Githu usernames of the people in my company.If people left, their github username doesn't disappear as it's a personal profile. Unless I take extra actions to change the customers file for any/all clusters I have setup the user still has access to the OFC installation and can add repositories to build and deploy into those clusters.
Additionally, this would allow organisations to limit the repositories that can be added to the cluster. At the moment, any user that has a line in the customer file can create new deployments into the cluster. Users in an organisation could have limited permissions where they are not able to create repositories, or add integrations. This proposal would allow an operator to limit the code that could be run on the cluster.
Expected Behaviour
An Organisation added to the customers file will allow public members of that organisation to authenticate with the cluster through the OAuth application (Github)
Current Behaviour
A user needs to also individually be in the Customers file as the organisations they belong to.
Possible Solution
We are able to get a list of organisations a user is a public member of, we already get this information and include it as a claim on their JWT.
We could also check in this field to see if any of the user's organisations are in the customer's file.
Context
Managing users in Github is already part of the onboarding/offboarding for a user, additionally remembering that any usernames in the OFC Customers file can authenticate and setup deployments into the cluster is additional burden for an operator.
The text was updated successfully, but these errors were encountered: