From 2762a95da5751fba6c72b1098dc1a35e51314464 Mon Sep 17 00:00:00 2001 From: "David J. Allen" Date: Thu, 18 Apr 2024 12:55:16 -0600 Subject: [PATCH] Update README.md about internal IDP --- README.md | 60 ++++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 48 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index bcabb1b..1ca42c7 100644 --- a/README.md +++ b/README.md @@ -28,12 +28,39 @@ These commands will create a default config, then start the login process. Maybe - [Gitlab](https://about.gitlab.com/) - [Forgejo](https://forgejo.org/) (fork of Gitea) +The tool is now able to run an internal example identity provider using the `serve` subcommand. + +```bash +./opaal serve --config config.yaml +``` + +This will start a server that allows you to login with `opaal` itself. Currently, it is only has one example user to use for log in. The username and password combination is `ochami:ochami`. It uses the same config file as before with additional parameters set in the config file: + +```yaml +server: + ... + issuer: + host: "127.0.0.1" + port: 3332 + +authentication: + clients: + - id: "ochami" + secret: "ochami" + name: "ochami" + issuer: "http://127.0.0.1:3332" + redirect-uris: + - "http://127.0.0.1:3333/oidc/callback" +``` + +See the [Configuration](#configuration) section for the entire config file. + ### Authorization Code Flow `opaal` has the ability to completely execute the authorization code and return an access token from an authorization server using social sign-in. The process works as follows: 1. Click the authorization link or navigate to the hosted endpoint in your browser (127.0.0.1:3333 by default) - - Alternatively, you can use a link produced + - Alternatively, you can use a link produced 2. Login using identity provider credentials 3. Authorize application registered with IdP 4. IdP redirects to specified redirect URI @@ -41,27 +68,29 @@ These commands will create a default config, then start the login process. Maybe - ...verifying the authenticity of the ID token from identity provider with its JWKS - ...adds itself as a trusted issuer to the authorization server with it's own JWK - ...creates a new signed JWT to send to the authorization server with the `urn:ietf:params:oauth:grant-type:jwt-bearer` grant type - - ... returns an access token that can be used by services protected by the authorization server + - ... returns an access token that can be used by services protected by the authorization server *After receiving the ID token, the rest of the flow requires the appropriate URLs to be set to continue. ### Client Credentials Flow -`opaal` also has - ## Configuration Here is an example configuration file: ```yaml -version: "0.0.1" +version: "0.3.2" server: host: "127.0.0.1" port: 3333 callback: "/oidc/callback" + issuer: + host: "127.0.0.1" + port: 3332 providers: + opaal: "https://127.0.0.1:3332" forgejo: "http://127.0.0.1:3000" authentication: @@ -83,7 +112,17 @@ authentication: client-credentials: authorization: - urls: + token: + forwarding: false + refresh: false + duration: 16h + scope: + - smd.read + key-path: ./keys + endpoints: + issuer: http://127.0.0.1:4444 + config: http://127.0.0.1:4444/.well-known/openid-configuration + jwks: http://127.0.0.1:4444/.well-known/jwks.json #identities: http://127.0.0.1:4434/admin/identities trusted-issuers: http://127.0.0.1:4445/admin/trust/grants/jwt-bearer/issuers login: http://127.0.0.1:4433/self-service/login/api @@ -91,17 +130,14 @@ authorization: authorize: http://127.0.0.1:4444/oauth2/auth register: http://127.0.0.1:4444/oauth2/register token: http://127.0.0.1:4444/oauth2/token - clients: - - id: bss - secret: IAMBSS options: - decode-id-token: true - decode-access-token: true run-once: true open-browser: false - forward: false + flow: authorization_code + cache-only: false + verbose: true ``` ## Troubleshooting