Eureka Frequently Asked Questions

If a customer developed scripts/tools which call into Folio, will they still work on Eureka?

It depends. Generally speaking they should as long as they’re not calling any of OKAPI’s internal APIs for managing the system (e.g. for creating/managing tenants, listing modules, enabling/disabling modules for tenants, etc.). Folio installations on Eureka will provide a Kong-prefixed backend hostname instead of an Okapi-prefixed backend hostname. Scripts should be pointed at this. For example, instead of https://okapi-foo.folio.ebsco.com you’d use http://kong-foo.folio.ebsco.com

How would migration of existing staff users work (transitioning current permission sets to roles)? Will this represent substantial downtime for the library or will this be accomplished prior to the DNS switch?

Migration APIs have been developed in mod-users-keycloak and mod-roles-keycloak. On the users side, the API will create records in Keycloak for all users assigned at least one permission (users that actually login and use Folio). Keycloak will typically not need to know about other users (patrons, etc.). On the roles side, the permissions assigned to those users will be inspected and roles will be created in keycloak, and assigned to users as needed. Once both of the migration APIs have been invoked, users should still have the same privileges as before, only now in the role-based access control model. The roles generated via this mechanism can then be tweaked/adjusted/combined/renamed/etc. as desired.
Staff users' (i.e. those who login to Folio) records will need to migrate to Keycloak from mod-users. However, passwords cannot be migrated, so users will need to (re)create passwords for themselves - which will be held by Keycloak going forward.

Are the time-based policies meant to imply when actions can be performed by a staff member or when a staff member’s capability will expire? Or is this a combination?

On the legacy platform, users either have the ability to call an API endpoint or they don’t. With the introduction of time-based policies, we have greater control. These policies allow us to control not only whether a user can call an API endpoint, but also when. For example, I’m assigned a role which allows me to perform check-out and check-in. With a time-based policy, I might only be able to perform check-out and check-in during normal business hours, Monday through Friday.

When looking at a capability, is the “Manage” action the equivalent of having all the other actions (view, edit, create, delete)?

That’s right.

Is a role assigned via the Settings app, the Users app, or both?

Short term, from settings only. Eventually roles/user assignments will be managed from both perspectives (looking at a particular role in settings, and looking at a particular user in the users app)

If a library is running mod-roles, would they be able to run mod-permissions concurrently or is the activation of mod-roles effectively deactivating mod-permissions? (Please correct any misnaming I’ve done here.)

Discussed around the 30 min mark in the WOLFcon recording, but I’m not fully clear on this.

There are a couple technical reasons why we still need mod-permissions running in parallel with mod-roles-keycloak, at least during migration/transition to the new platform. We expect to address this at some point, allowing us to remove mod-permissions from the picture.

Will things like session timeout duration and password reset policies be configurable by library or will hosting impose these things uniformly for all libraries?

At the moment (Dec 15, 2023) these types of things are configured directly in Keycloak. Access to Keycloak’s admin console will be tightly controlled, so at least initially this configuration will be performed by FSE / hosting provider. We’re planning to make many of these things configurable via Folio APIs in the future, but details are TBD.

Since this will be a phased rollout, how should we plan for this from a training standpoint? Should we have a Eureka training tenant and a “traditional” training tenant?

This deserves discussion between training, Eureka, and possibly FSE. That said, having parallel training environments sounds like a reasonable approach.

What are the plans for working with the Documentation Working Group to incorporate these changes to the product documentation?

There’s an technical writer working on consolidating existing developer-facing documentation for Eureka. This person and the developer documentation SIG have been put in touch with each other to see if there’s any overlap in efforts.

How will other open source FOLIO integrations that call OKAPI directly (like VuFind) be notified that they need to point to Kong?

See Question 1 above.

Any concerns regarding Eureka and FOLIO z39.50? Or Eureka and for example OCLC z39.50? 

No concerns or known issues between Eureka and Z39.50.

Also does Eureka help in anyway with improved logging actions/activity? 

Eureka’s sidecars produce structured transaction logs, something which OKAPI-based folio doesn’t provide OOTB.