https://github.com/curityio/dynamic-authenticator-demo
Resources needed to run a demo of the dynamic authenticator
https://github.com/curityio/dynamic-authenticator-demo
authentication federation oauth2 openid-connect saml use-case
Last synced: 8 months ago
JSON representation
Resources needed to run a demo of the dynamic authenticator
- Host: GitHub
- URL: https://github.com/curityio/dynamic-authenticator-demo
- Owner: curityio
- License: apache-2.0
- Created: 2022-08-03T11:30:17.000Z (almost 4 years ago)
- Default Branch: master
- Last Pushed: 2024-11-05T14:14:22.000Z (over 1 year ago)
- Last Synced: 2025-01-30T13:31:44.274Z (over 1 year ago)
- Topics: authentication, federation, oauth2, openid-connect, saml, use-case
- Language: Shell
- Homepage: https://curity.io/resources/learn/dynamic-authenticator/
- Size: 253 KB
- Stars: 0
- Watchers: 5
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Dynamic Authenticator Demo
This repository contains resources needed to demonstrate the usage of a Dynamic Authenticator in the Curity Identity Server.
The resources created with scripts from this repo are:
- Two separate instances of the Curity Identity Server that serve as two external OIDC Providers.
- Two separate instances of the Curity Identity Server that serve as two external SAML Providers.
- A node API that serves configuration required by the Dynamic Authenticator.
- An instance of the Curity Identity Server with two types of Dynamic Authenticators configured.
Note, that the OIDC and SAML providers are just added for demonstration purpose and to make this example self-contained. Don't bother the extra instances of the Curity Identity Server and related data stores. In a proper environment, those providers are external and maintained by a third party. To simulate a real-world scenario, the providers in this example are assigned different domains. See [The Created Resources](#the-created-resources) for the details.
## Prerequisites
The following tools are used by the script from this repo, and you will need them to run the demo:
- Docker Desktop
- openssl
- curl
Make sure that you have those installed and available in path before running the scripts.
You will also need a license for the Curity Identity Server. If you don't have one you can get a trial license from the
[Curity Developer portal](https://developer.curity.io/free-trial/).
## Starting the Demo
Follow these steps in order to run the demo:
- Copy the JSON license file to `/idsvr`.
- Add the following domains to `/etc/hosts`:
```
127.0.0.1 login.example.com provider1.example.com provider2.example.com provider3.example.com provider4.example.com
```
- Run the `./deploy.sh` script. It will create the required certificates and containers.
## Log in Using the Dynamic Authenticator
You can log in to the main instance of the Curity Identity Server, by starting an OAuth flow for the client `dynamic-authenticator-demo`.
The dynamic authenticator needs a way of determining which configuration to use for the authentication. Therefore, it first collects a username, then calls the configuration API with the domain typed into the username field.
Enter the following URL in your browser to start an authentication:
```
https://login.example.com:8443/oauth/v2/oauth-authorize?client_id=dynamic-authenticator-demo&response_type=code&scope=openid&redirect_uri=http://localhost
```
In the username prompt, type `user1@provider1` or `user2@provider2` for federating to an OIDC provider,
`user3@provider3` or `user4@provider4` for federating to a SAML IdP.
You may now log in at the external provider. Use one of the following credentials to log in at the different providers:
| Provider | Username | Password |
|-----------|----------|-------------|
| provider1 | `user1` | `Password1` |
| provider2 | `user2` | `Password1` |
| provider3 | `user3` | `Password1` |
| provider4 | `user4` | `Password1` |
After logging in with a provider you will see a Debug Attribute Action screen, where you can study the attributes collected from the respective provider.
Note that even though `userX@providerX` was first used as the subject, the final subject is the one obtained from the provider.
| Dynamic Authenticator using OIDC | Dynamic Authenticator using SAML |
| --- | --- |
|  |  |
### Customizing the Look and Feel
The [Look And Feel](https://curity.io/resources/learn/customize-look-and-feel-simple) editor provides a way of changing the theme of the login forms without the need of editing CSS files and templates. You can use it to quickly change the login screen look.
## The Created Resources
The demo creates the following resources. Some useful endpoints are provided for convenience.
### Provider 1
A Curity Identity Server instance that serves as an external OIDC Provider.
Endpoints:
- OIDC metadata: https://provider1.example.com:8444/oauth/v2/oauth-anonymous/.well-known/openid-configuration
- admin UI: https://provider1.example.com:6750/admin
### Provider 2
A Curity Identity Server instance that serves as an external OIDC Provider.
Endpoints:
- OIDC metadata: https://provider2.example.com:8445/oauth/v2/oauth-anonymous/.well-known/openid-configuration
- admin UI: https://provider2.example.com:6751/admin
### Provider 3
A Curity Identity Server instance that serves as an external SAML IdP.
Endpoints:
- SAML IdP URL: https://provider3.example.com:8446/authn/authentication
- admin UI: https://provider3.example.com:6752/admin
### Provider 4
A Curity Identity Server instance that serves as an external SAML IdP.
Endpoints:
- SAML IdP URL: https://provider4.example.com:8446/authn/authentication
- admin UI: https://provider4.example.com:6753/admin
### Main instance
A Curity Identity Server instance that uses the dynamic authenticator.
Endpoints:
- OIDC metadata: https://login.example.com:8443/oauth/v2/oauth-anonymous/.well-known/openid-configuration
- admin UI: https://login.example.com:6749/admin
### The Configuration API
A node Express API that serves the configuration required by the dynamic authenticator.
Endpoints:
- http://localhost:8080/api/configuration?fid=(provider1|provider2|provider3|provider4)
## Updating the Resources
When you update the default configuration files or the API code you will have to redeploy the containers. Running `./deploy.sh` again
will restart all containers, and the Curity Identity Server instances will have the configurations and data reset.
If you change the API code, run the script with the `--rebuild-api` option. This will refresh the API code in the container.
If you need the certificates to be renewed, run the script with the `--regenerate-certs` option.
## Teardown
Once you're done with the demo, run the `./teardown.sh` script. This will free all the resources used in this demo.
## Further Reading
Have a look at this [tutorial](https://curity.io/resources/learn/dynamic-authenticator) that describes the Dynamic Authenticator in details.
If you want more information about the Curity Identity Server, Identity and Access Management, OAuth or OpenID Connect,
then have a look at the [resources](https://curity.io/resources/) section of the [Curity](https://curity.io) website.
If you have any questions or comments don't hesitate to open an issue in this repository or contact us.