Jans Config-Api - Enable Config Api to be able to configure two different OPs

[pujavs]

Requirement:

Jans Config Api to be able to configure multiple OPs

Jans Config Api Current Flow:

1. jans-config-api is tightly linked to underlying jans-auth-server.
2. On installation, oauth scopes and internal client is created.
3. On start-up the jans-config-api load the underlying server’s config, persistenceEntryManagerInstance, verifies scopes etc and creates a cache of the scope.
4. Client can invoke an endpoint with bearer token reference (with or without the issuer in the header) or jwt token
5. If the token is jwt then validates it against its issuer else if reference token its introspected it with the passed approver or underlying jans-auth-server

Enhancement:

1. jans-config-api should be capable to configure multiple Jans Auth Server
   Example:
2. OP#1 will be the Internet facing OP…The one that does the actual open banking transactions.
3. OP#2 is only used to hold the admin accounts, and the admin client entities.

Pseudo Flow:

1. OP to be predefined. Say op_server=server1, server2, server3
2. Config details of the OP config folder to be pre-defined as required on start-up. -Dserver1.jans.base=/etc/jans.
3. Jans Config-api on start-up will create a config using point#1 and JanssenProject/jans-config-api#2 and create a server-config mapping
4. Client to invoke jans-config-api endpoint with appropriate server context
   example
   https://config-api.gluu.org/server1/jans-config-api/api/v1/jans-auth-server/config?..
   https://config-api.gluu.org/server2/jans-config-api/api/v1/config/database/ldap...
5. Jans Config-api filter will intercept the request and validate the token
6. Jans-Config-api will invoke the auth server configuration

Assumption:

1. Jans-Config-api will allow configuration of underlying Jans auth server of same version

Open Issues:

1. Need clarity on Point#2 -> Config details of the OP config folder to be pre-defined as required on start-up. -Dserver1.jans.base=/etc/jans.
2. jans-config-api checks if the token is jwt then validates it against the issuer insider token else if reference token then introspects it with the passed approver or underlying server. This will require each auth server to have the config_api client and scopes for validations. Is this approach fine?

[yurem]

According to your description jans-config-api should have access to each OP DB directly. In Jans Auth we have similar code which can create list of Persistence Entry Managers for authentication. In you case you can @Produces can produce Map<String, PersistenceEntryManager> which you can inject in your code:

	@Inject
	@Named(ApplicationFactory.PERSISTENCE_AUTH_ENTRY_MANAGER_NAME)
	private Map<String, PersistenceEntryManager> persistenceEntryManagers;

Also in AppInitializer there is code to do check for configuration files update using timer, recreate PersistenceEntryManagers on conf update, destory on shutdown, etc..

[pujavs]

This feature is been put on hold as there are security concerns. To summarize;

1. In order to configure multiple auth-servers, config-api will need persistence and encryption details of all these auth-servers, raising security concerns.
2. However inside a K8s cluster, config api cannot access another K8s cluster unless the background network is setup to do that
3. Allowing access from outside to the K8s cluster causing security risks and anti CN pattern.