Skip to content

jhipster/jhipster-registry

JHipster Registry

Build Status Docker Status Docker Pulls

This is the JHipster registry service, based on Spring Cloud Netflix, Eureka and Spring Cloud Config.

Full documentation is available on the JHipster documentation for microservices.

Deploy to Heroku

Click this button to deploy your instance of the registry:

Deploy to Heroku

There are a few limitations when deploying to Heroku.

  • The registry will only work with native configuration (and not Git config).
  • The registry service cannot be scaled up to multiple dynos to provide redundancy. You must deploy multiple applications (i.e. click the button more than once). This is because Eureka requires distinct URLs to synchronize in-memory state between instances.

Running locally

To run the cloned repository;

  • For development run ./mvnw -Pdev,webapp to just start in development or run ./mvnw and run npm install && npm start for hot reload of client side code.
  • For production profile run ./mvnw -Pprod

HashiCorp Vault Integration

Development Mode

JHipster Registry default integration uses a vault server with an in-memory backend. The data shall not be persist and shall require you to configure secrets after every restart. The in-memory configuration provides an easy way to test out the integration and later switch to the recommended server mode.

  • Start vault server docker container:
docker-compose -f src/main/docker/vault.yml up -d
  • The default configured root token is jhipster-registry. We shall use the default secrets engine backend mounted on the secrets path. Configure secrets using either of ui, cli or http.
  • Create a new secret sub-path jhipster-registry/dev and add the following secret in JSON format. Here jhipster-registry refers to the application name and dev refers to the development profile. Do follow the same convention to configure secrets of other applications.
{
  "spring.security.user.password": "admin123!"
}
  • Start JHipster Registry server in development mode using the following command (skipping execution of test cases):
./mvnw -DskipTests
  • After successful start, open http://localhost:8761/ in a browser. You shall require entering a new password as provided in the above vault configuration.

Server Mode

JHipster Registry also provides configuration to use the native file system as the persistent backend.

  • Uncomment the following configurations in vault.yml. You can refer config.hcl to view provided vault server configurations:
command: server
volumes:
  - ./vault-config/config:/vault/config
  - ./vault-config/logs:/vault/logs
  - ./vault-config/data:/vault/file
  • Start vault server docker container:
docker-compose -f src/main/docker/vault.yml up -d
  • Open vault server ui to initialize master key shares. In this guide, we shall enter 1 as the number of key shares and 1 as the key threshold value. Do refer to vault documentation for recommended configuration. Note down the initial root token and the key and keep it at a safe place. You shall require the key to unseal the vault server after a restart.
  • Enable secret engine backend kv and use secret as the mount path.
  • Create a new secret sub-path jhipster-registry/dev and add the following secrets in JSON format. Here jhipster-registry refers to the application name and dev refers to the development profile. Do follow the same convention to configure secrets of other applications.
{
  "spring.security.user.password": "admin123!"
}
  • In this guide, we shall use the token authentication mechanism to retrieve secrets from the vault server. Update bootstrap.yml to specify root token in place of default dev token.
vault:
  authentication: token
  token: jhipster-registry # In server mode, provide a token having read access on secrets
  • Start JHipster Registry server in development mode using the following command (skipping execution of test cases):
./mvnw -DskipTests
  • After successful start, you shall require entering a new password as provided in vault.

OAuth 2.0 and OpenID Connect

OAuth is a stateful security mechanism, like HTTP Session. Spring Security provides excellent OAuth 2.0 and OIDC support, and this is leveraged by JHipster. If you’re not sure what OAuth and OpenID Connect (OIDC) are, please see What the Heck is OAuth?

Please note that JSON Web Token (JWT) is the default option when using the JHipster Registry. It has to be started with oauth2 spring profile to enable the OAuth authentication.

In order to run your JHipster Registry with OAuth 2.0 and OpenID Connect:

  • For development run SPRING_PROFILES_ACTIVE=dev,oauth2,native ./mvnw
  • For production you can use environment variables. For example:
export SPRING_PROFILES_ACTIVE=prod,oauth2,api-docs

Keycloak

Keycloak is the default OpenID Connect server configured with JHipster.

If you want to use Keycloak, you can follow the documentation for Keycloak

Okta

If you'd like to use Okta instead of Keycloak, you can follow the documentation for Okta

Auth0

If you'd like to use Auth0 instead of Keycloak, you can follow the documentation for Auth0

*NOTE: Using the JHipster Registry, add URLs for port 8761 too ("Allowed Callback URLs" and "Allowed Logout URLs")