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
Configuration of Auth0 applications, social integrations, and actions to support the EMPC labs Platform Starter Kits command line tool (`pskctl`).
13
+
Configuration of Auth0 applications, social integrations, and actions to support the EMPC labs Platform Starter Kits engineering platform user experience.
14
+
15
+
PSK Platform access is based around team membership. If you are part of a team that has been authorized to use the platform, then you will have permission to interact with all of that particular teams resources on the platform.
16
+
17
+
The intended integration pattern is that all the SaaS developer tools are integrated into the organization's SSO provider. Generally, corporations have Okta (of which Auth0 is now a part) or another IDP (Azure AD) and this is used to create an authentication workflow with the tool. As the authorization experience is intended to be around team membership and we also want customers of the platform to be able to self-manage those teams, we will use GitHub as the oauth2 integration point for the platform. It is relatively straightforward to configure such an experience within GitHub itself (and most organization have) as far creating and managing teams in an authorized manner.
18
+
19
+
A User (customer, developer) has access to the platform by virtue of being added to a GitHub Team that has been onboarded.
20
+
21
+
The Auth0 tenant application created by this pipeline is used in two ways:
22
+
- An the 0auth2/oidc integration with each of the kubernetes cluster to enable bounded access to team resources on the cluster, and
23
+
- to authN/Z calls to the custom platfom product APIs (typically using the platform cli `pskctl`).
14
24
15
25
The oauth0/oidc flow required by the pskctl tool is available in the free tier of Auth0. Complete these [bootstrap](doc/bootstrap.md) steps as part of signing up for Auth0 and preparing for the pipeline managed Auth0 configuration.
16
26
17
27
With a management api token now available, this pipeline will perform the following tasks:
18
28
19
-
* Create an application client to be used by the pskctl tool.
29
+
* Create an application client to be used by the pskctl tool.
20
30
21
31
* Create a custom action that will run after a successful github social-authentication. The action fetches the Users teams for the integrated (above) github organization.
22
32
@@ -28,45 +38,16 @@ The above results in the creation of an oauth2/oidc device-auth-flow endpoint th
28
38
29
39
This endpoint implements the oauth2/oidc device-auth-flow. Using the pskctl cli, when you perform a `login` command, you will be provided a link. From your browser, proceed to the link and enter the provided device code. You must then authenticate to Github. This is performed via Githubs oauth service and no credential information is made available to Auth0.
30
40
31
-
In addition to this social-login connection, upon a successful github login, the auth0 application client will fetch the list of github teams the user is a member of the github organization. This list is included as a claim within the resulting id token.
41
+
In addition to this social-login connection, upon a successful github login, the auth0 application client will fetch the list of organization github teams in which the user is a member. This list is included as a claim within the resulting id token.
32
42
43
+
The Auth0 tenant application is also integrated with the kubernetes clusters of the PSK engineering platform. The pskctl cli can also generate kubeconfig files that enable users to authenticate to the EKS cluster with permissions based on role bindings tied to the github team claims.
33
44
34
45
### development
35
46
36
47
The above github oauth app and auth0 management api tokens must be available in th environment for the python scripts to work. See op.*.env
37
48
38
-
39
-
40
-
41
-
49
+
These setting are all configurable in the request-body/TENANT.json file.
42
50
- token expires after 1hr (3600)
43
51
- can be refreshed (refresh token provided)
44
52
- absolute lifetime for refresh for token in active use is 7 days (604800)
45
53
- an idle token cannot be refreshed after 2days (172800)
46
-
47
-
48
-
49
-
50
-
51
-
52
-
53
-
After completing the bootstrap steps, the github social connection in place and the Management API client endpoint available, now this repo pipeline can manage the Applications and Rules that define the functionality of our oidc endpoint.
54
-
55
-
The pipeline has three essential steps:
56
-
57
-
1. Fetch a management api token to use for creating and updating Auth0 configuration
58
-
2. Deploy the dev or prod tenant dpsctl application definitions
59
-
3. Deploy all rules used by the dpsctl application login process
60
-
61
-
Since Auth0 is not used to perform any authentication functions, the rules are the steps to take in constructing a jwt to return from a successful authentication.
62
-
63
-
In this case that means, if the user is a member of the github org where the github oauth-app is defined (in this case ThoughtWorks-DPS) then they will be able to successfully authenticate, after which:
64
-
65
-
* with the users own github access token, fetch all org teams of which the user is a member
66
-
* insert those teams as a list into the returned idToken
0 commit comments