This project provides a solution to dynamically generate and view a report of all Auth0 applications in your tenant, and their associated Actions. This solution also utilises Role-Based Access Control (RBAC) to control which portions of the report can be viewed based on permissions - in particular, for users with the 'Manager' role assigned through RBAC, this report also includes the type of trigger each Action is bound to.
-
report-view
: This is a React application that communicates with the backend servers and Auth0 Login Providers to enable authentication and display the report. It runs onlocalhost:5001
. -
api-gateway
: Running onlocalhost:3000
, it serves as the proxy and entry point for backend services. -
report-generation-service
: A backend service running onlocalhost:3001
that fetches data from Auth0's Management API and prepares the report. -
Behind the scenes on the Auth0 Dashboard, there are two Auth0 applications integrated with the frontend and backend respectively:
report-view-spa
andreport-generation-service
. -
On the Auth0 dashboard, we have also defined two APIs -
Report Generation Service API
which acts as theaudience
for the frontend login providers and is responsible for verifying authentication token before interacting with theManagement API
, and theManagement API
which allows for interaction with Auth0 admin data (like client apps and actions) -
The Auth0 application
report-generation-service
uses both theReport Generation Service API
and theManagement API
-
Auth0 account and tenant configured
-
On
Auth0 Dashboard > Applications
, configure aRegular Web Application
for thereport-generation-service
. It is not necessary to set any Callback URLs or Allowed Web Origins -
On
Auth0 Dashboard > Applications
, configure aSingle Page Application
for thereport-view-spa
. SetAllowed Web Origins
andAllowed Callback URLs
tolocalhost:5001
or any port number you choose -
On
Auth0 Dashboard > APIs
, configure aCustom API
for theReport Generation Service API
, setting your own unique URL identifier and the Signing Algorithm toRS256
. Also verify that theAuth0 Management API
is present on the APIs page. -
On
Auth0 Dashboard > User Management > Roles
, configure aManager
role -
Have Docker installed
- Clone the repository to your local machine.
git clone https://github.com/nicholas-gcc/auth0-app-action-map.git
- Create a
.env
file following the format specified in the/report-view/.env.example
,/report-generation-service/.env.example
and/api-gateway/.env.example
directories - From the root directory, deploy and run the Docker container using:
docker-compose up --build
You can now access the system at localhost:5001
. You can click the Login
button and log in with your Auth0 credentials associated with the desired tenant to generate the report.
- Clone the repository to your local machine.
git clone https://github.com/nicholas-gcc/auth0-app-action-map.git
- Create a
.env
file following the format specified in the/report-view/.env.example
,/report-generation-service/.env.example
and/api-gateway/.env.example
directories - Install the required npm packages for the frontend and backend and run each service.
cd report-view
npm install
npm start
cd api-gateway
npm install
npm start
cd report-generation-service
npm install
npm start
You can now access the system at localhost:5001
. You can click the Login
button and log in with your Auth0 credentials associated with the desired tenant to generate the report.
- The React frontend integrates with an Auth0 provider, enabling users to log in with Auth0's predefined login boxes (shown below)
-
Upon successful login, Auth0 generates a bearer token for the session which is then sent to the
api-gateway
and thereport-generation-service
. Both of these services have authentication middlewares with the intended audience being theReport Generation Service API
, but you may choose to define different authentication logic at theapi-gateway
(e.g. Coarse Permissions) and thereport-generation-service
levels (e.g. Fine-Grained Permissions) separately according to your business rules and logic -
After successful authentication, the
report-generation-service
uses theManagement API
to generate a Management API token. This token is used to retrieve information about client applications, actions, and flows. In particular, this application uses theManagement API
's/api/v2/clients
and/api/v2/actions/actions
endpoints to generate the action-client mappings, and the/api/v2/users/{userId}/roles
to verify the permissions assigned to the user. -
It also checks if the user is assigned a
Manager
role. If so, the report will display all information, including triggers. Below is an example of a user with theManager
role.
- Otherwise if the logged in user does not have the
Manager
role, the triggers will not be displayed as shown below:
This application is structured with potential extension of microservice APIs in mind, regardless of tech stack. Adding new services and integrations can be made possible by defining a new API separate from the report_generation_service
, proxying these new services through the api-gateway
, configuring a Dockerfile
and modifying docker-compose.yml
to cater for different service infrastructure. This enables the extension of the application while also maintaining Separation of Concerns.
-
Action Usage Statistics: This would provide a statistical breakdown of how often each Action is executed. It could be helpful for management to optimize resources by identifying underutilized Actions. You can possibly do this by accessing logs through the Management API using the
/api/v2/logs
endpoint and defining a separate API service for this. -
Integration with Other Services: Depending on the specific needs of your company or your customers, you could add features to integrate Auth0 with other services. For instance, you could connect it with Slack or email to send notifications about critical events or updates, such as new mappings between Actions and client applications, utilising webhooks between this app and the service you are looking to integrate
-
Advanced Search: Improve the search functionality in the application. Allow users to search for Actions based on different criteria, such as trigger type, name, date created, and more. This could greatly simplify the process of finding the right Actions. This can be achieved by provisioning a database or in-memory data structures, populating them with your tenant data and retrieving relevant results based on user inputs and use built-in search/query methods on the programming language of your choice
-
Rate Limiting: In the
api-gateway
, you can introduce rate limiting to prevent abuse and to protect your backend services. Rate limiting can be IP-based, or user-based if the user is authenticated at the API gateway. -
Conditional Access Policies: In the
report_generation_service
, you can implement conditional access policies that take into account the user's location, device, IP address, etc. For example, requests from unfamiliar locations or devices might trigger additional security measures.
While Docker provides a flexible and robust solution for deploying the auth0-app-action-map
project, it may be worth considering AWS Lambda as a potential alternative, depending on your specific use case:
-
Scalability: If the
auth0-app-action-map
is expected to be used infrequently or irregularly (such as an administrative tool used for periodic audits or reports), AWS Lambda's pay-per-use model could provide cost benefits. You would only be billed for the actual compute time consumed by each function invocation, instead of paying for server uptime on Docker -
Ease of Management: AWS Lambda abstracts away infrastructure management, allowing you to focus solely on code. This might simplify operations if your team doesn't have extensive DevOps expertise or if you prefer to minimize operational overhead.
-
Integration with AWS Ecosystem: If your infrastructure is heavily AWS-based, AWS Lambda integrates seamlessly with other AWS services for a smooth, end-to-end development and deployment experience.