Done
Details
Assignee
Mikhail FokanovMikhail FokanovReporter
Craig McNallyCraig McNallyPriority
P2Story Points
0Sprint
NoneDevelopment Team
EurekaTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Mikhail Fokanov
Mikhail FokanovReporter
Craig McNally
Craig McNallyPriority
Story Points
0
Sprint
None
Development Team
Eureka
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created December 31, 2023 at 3:00 PM
Updated December 31, 2023 at 5:19 PM
Resolved December 31, 2023 at 5:19 PM
Currently configuring many of the parameters for a tenant must happen via direct interaction with Keycloak (either via the admin console or APIs). Given that we want to reduce who can access Keycloak, it's desirable to provide a way for system operators to configure these things via FOLIO APIs. We have the agility to associated arbitrary key/value pairs with tenants. The idea here is to add support for special attribute key prefixes (e.g. keycloak._________) which will inform the mgr-tenants to make corresponding calls to Keycloak. Example:If the attribute keycloak.access-token.ttl is specified with value 300, the tenant manager would pick this up and make the necessary calls to keycloak to set the tenants/realm's access token TTL to 300 seconds.Questions/considerations:How do we want to handle this in mgr-tenants?Do we want to support just certain attributes?What about other infrastructure, e.g. Kong. Can we also support prefix of kong.?Is there a way to make this more easily extensible w/o having to write code/change mgr-tenants whenever a new attribute is supported?Are there certain naming conventions which help here? e.g. keycloak.realm. or keycloak.client.diku-application.access-token.ttl