From d0503a606f35b2efdf625ebcd18f0f7abd0db591 Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Wed, 11 Sep 2024 04:37:36 +0000 Subject: [PATCH] [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --- authN-authZ/auth-istio/README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/authN-authZ/auth-istio/README.md b/authN-authZ/auth-istio/README.md index 81412bde1..aa93fc1f8 100644 --- a/authN-authZ/auth-istio/README.md +++ b/authN-authZ/auth-istio/README.md @@ -3,6 +3,7 @@ In enterprise settings not only do we want to identify who is using a service but also what they are entitled to use. This is where authentication and authorization comes in. In contrast, API tokens provide full access by virtue of possession as long as they are valid/not expired. With that aside, we first provide the solution on AuthN and AuthZ in OPEA using Istio and JWT tokens. Another option is to leverage the oauth2-proxy with various OIDC providers for authentication and authorization. Using oauth2-proxy with Istio ensures secure, scalable access control, centralizes user management, and provides seamless single sign-on capabilities, improving overall security and user experience in complex microservices environments. Currently we provide three kinds of setups for authentication and authorization. Note: Please complete the steps in the [prerequisite](#prerequisite) before proceeding with these tasks. : + - [via fake JWT token with curl](#perform-authentication-and-authorization-via-fake-jwt-tokens) - [via JWT token generated by OIDC providers with curl](#perform-authentication-and-authorization-via-jwt-tokens-generated-by-oidc-provider) - [via oauth2-proxy and OIDC providers with UI](#perform-authentication-and-authorization-via-oauth2-proxy-and-oidc-provider-and-ui) @@ -235,7 +236,7 @@ The user management is done via Keycloak and the configuration steps look like t ![create realm](./docs/create_realm.png) -2. Create a new client called `chatqna` and set `Client authentication` to 'On'. Set the value of `$URL` with "/\* " (e.g. "http://chatqna-ui.com:${INGRESS_PORT}/\*") in the `Valid redirect URIs` part. Note that `INGRESS_PORT` and `INGRESS_HOST` shall be exported following the guide [here](https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports). Under the Credentials tab you will now be able to locate ``, which will be used in the oauth2-proxy configs. +2. Create a new client called `chatqna` and set `Client authentication` to 'On'. Set the value of `$URL` with "/\* " (e.g. "http://chatqna-ui.com:${INGRESS_PORT}/\*") in the `Valid redirect URIs` part. Note that `INGRESS_PORT` and `INGRESS_HOST` shall be exported following the guide [here](https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports). Under the Credentials tab you will now be able to locate ``, which will be used in the oauth2-proxy configs. ![create client 1](./docs/create_client_1.png) @@ -296,6 +297,7 @@ kubectl apply -f $(pwd)/$DEPLOY_METHOD/chatQnA_ui_gateway.yaml ``` With helm chart based deployment, the UI already deployed as part of the pipeline. So expose endpoints like this: + ```bash kubectl apply -f $(pwd)/$DEPLOY_METHOD/chatQnA_router_gateway_oauth.yaml ``` @@ -324,6 +326,7 @@ Add both host names for ChatQnA UI and backend service into /etc/hosts sudo sed -i '1i\127.0.0.1 chatqna-service.com' /etc/hosts sudo sed -i '1i\127.0.0.1 chatqna-ui.com' /etc/hosts ``` + Open browser with address `"chatqna-ui.com:${INGRESS_PORT}"` if using GMC based deployment. Otherwise, open the browser with address `"chatqna-service.com:${INGRESS_PORT}"`. Login with user `bob` and its credentials shall return a 403 error. Login with user `mary` and its credentials shall able to access the ChatQnA service.