Skip to main content

FPX 101

About FPX​

What is FPX and what business value does it offer to the customer, their partners and end-users?
The IDENTOS FPX platform provides clients with a single, unified solution that allows them to offer their end-users the highest level of autonomy when it comes to sharing their personal data such as medical or financial records with external parties. As a next-generation User-managed Access platform, it provides a host of useful features such as digital authentication, authorization, easy integration to disparate data resources, and an intuitive web/mobile UI that gives end-users complete control over who can access their records and where that data will be sourced from.


What are the core components of the FPX Ecosystem?
The FPX Ecosystem is built on 3 core components that work together to provide a unified access management platform:

  • The FPX Authorization Server (AS) - The primary component of the FPX ecosystem. The Authorization Server receives and manages all requests coming in from clients. The client must receive authorization from the AS before it can make a request to an appropriate Resource Server (or possibly a Resource Server Adapter) for data. Successful authorization is the result of the request meeting a certain set of pre-defined/pre-configured parameters/policies set at the Authorization Server as well as user consent. Depending on the type of request, the Authorization Server routes it to a Wallet for user consent and then, once approved, provides the client with an access token. The client then uses this access token to make a direct API call to the Resource Server to access the specific requested resource.
  • The Wallet - The Wallet empowers users with the ability to manage credentials and control permissions and policies at the Authorization Server. It helps maintain user privacy within the network and allows for consented transactions. The Wallet offers a web or phone-based UI that is user-friendly and highly intuitive. The UIs can be customized and white-labeled as needed.
  • Resource Server / Resource Server Adapter (RSA)- A server that hosts resources on a resource owner's behalf and is capable of accepting and responding to requests for protected resources. The Resource Server Adapter is a separate feature offered by IDENTOS to easily integrate with Resource Servers that are hosted by third parties and rely on commonly used connectivity protocols.

Refer to Understanding the FPX Landscape and FPX Components for more details.


Explain the high-level data flow within FPX?
FPX allows integrated clients to initiate a request for user information. This request is routed internally by the FPX Authorization Server to the owner of the data requested. The data or ‘resource' owner then reviews the request within the web or phone UI (FPX Wallet and Navigator) and can accept or decline the request. If accepted, the user can also select where the information will be sourced from, provided multiple resource pools (Resource Servers) are configured for a particular resource type (e.g. Immunization records). Once the user consent is received, FPX provides the requesting client with an access token which is then used to make a direct API call to the Resource Server for the specific resource. FPX DOES NOT hold, store or transmit any user information for privacy reasons.

Refer to FPX Overview for more information.


What are the concepts or prerequisites that a prospective FPX client or adopter should be familiar with?
To fully understand the benefits offered by FPX and to simplify the deployment and configuration process, knowledge of the following industry standards/platforms is recommended:

In addition to this, people working on the deployment will need to be fluent with Kubernetes (containers) and MySQL.


How is user privacy maintained during the interactions between the various components of the ecosystem?
The primary purpose and functioning of FPX relate to working with consent rather than user data. FPX does not act as an intermediary or broker of user information between parties (Client and Resource Server in this case). Instead, it acts as a mechanism for services to request data from users, and to connect them directly with the source of that data. This connection is user-initiated and can be terminated by the user at any time. This operational model ensures that user privacy is maintained at all times and that IDENTOS does not withhold any information from the transaction between the Client and the Resource Server.


Does FPX conform to GDPR standards and requirements?
The GDPR principles that are most relevant to the Identity, Access, and Consent Management include 'Consent', the 'Right to be Forgotten', and 'Data Privacy'. FPX ensures that the client is able to offer discrete and 'easy to read' notices and captured user consent which formulates the core of the GDPR consent-related requirements. In addition, users can have their 'right to be forgotten' respected if the client chooses to offer the option to opt-out of the service. Privacy is a core part of the FPX services wherein the authorization services are used in conjunction with the privacy agent (FPX Wallet) ensuring that user activity isn't traceable or monitored.



FPX System Requirements​

What are the typical hardware/software investments that a prospective adopter of FPX would need to make?
FPX is designed to be deployed using Containers – A working Kubernetes cluster is the primary requisite for a successful FPX deployment. The exact sizing of this cluster can vary depending on the specific deployment needs, but the minimum should include a single node with 1 vCPU and 1GB of RAM of available resources to dedicate to the FPX components.

MySQL is recommended as the database of choice for a typical FPX deployment. If the required configuration dictates that MySQL needs to be deployed as well, an additional 0.5 vCPU and 0.5GB of RAM should be allocated.

FPX has been built to be cloud-agnostic. It can work on any Public Cloud hosted solution such as Azure, AWS, or GCP or can also work fine within the confines of an on-prem deployment. However, IDENTOS recommends the use of a public cloud solution for easier scalability and minimum downtime.
Refer to System Requirements for Authorization Server, Wallet, and Resource Server Adapter.


What are the commonly supported/used databases for an FPX deployment?
IDENTOS recommends the use of a MySQL v5.7 database for most deployments.


What are the various Desktop Operating Systems supported by FPX?
The following OS platforms are currently supported:

  • Microsoft Windows 10+
  • macOS Mojave (10.14.6+)

What are the various internet browsers that are supported by FPX along with their versions?
FPX supports the following browsers along with their N -1 version:

  • Google Chrome (95.0.4638.54)
  • Safari (15.0 - build 16612.1.29.41.4)
  • Microsoft Edge (95.0.1020.30)
  • Firefox 93.0Microsoft Internet Explorer is no longer supported.

Is FPX compatible with mobile devices?
Yes, FPX is fully compatible with mobile devices and supports the following OS versions:

  • iOS devices support OS 12+
  • Android devices support OS 9+ The mobile native FPX Wallet application is not currently optimized for use on tablets.

Is FPX compatible with Windows Active Directory accounts, authentication, and permissions?
Yes. The FPX Identity Access and Consent platform is compatible with Windows Active Directory through an LDAP or OIDC integration.

Refer to the LDAP and OIDC RSA chapters for more details.



FPX Components​

Can components within the FPX ecosystem operate independently from one another
No, the FPX components within the ecosystem rely on each other for various functions and hence cannot work in isolation. The entire premise of the FPX authorization platform is to share data to client services with the consent of that resource owner/data subject. While the Authorization Server facilitates this request processing, it cannot do so without a Client who makes the request, the Wallet where the user approves the request, and a Resource Server from where the client will access the resource/data.


Is the RSA (Resource Server Adapter) a required component? What benefits do the RSAs provided by IDENTOS bring to the table?
A Resource Server Adapter (RS Adapter) performs some of the duties on behalf of an application(s) wishing to act as a Resource Server (RS) in an FPX network. Existing applications may wish to isolate FPX integration efforts to a separate application/service. An RSA is applicable to third-party applications closed to modification, applications that use protocols or custom flows not supported out of the box by FPX, or data/identity stores that do not support some aspects required of a resource server, such as authentication or policy-based access management. For example, onboarding any of the following into an FPX network directly would present challenges:

  • Google API Services
  • An open-source healthcare system with custom authentication that cannot be modified without losing government accreditation
  • An Active Directory that wishes to be available to share user info

In these cases, an RS Adapter can serve as a façade to the RS, performing some or all of its duties in the FPX environment. The duties required of an RS by the FPX network are outlined within RSA Overview. When an RS on its own cannot fulfill its duties to the FPX network and the RSA is deployed to fulfill those very duties, collectively they represent a single Resource Server within an FPX network. It is therefore also correct to use the term "Resource Server" to refer to the joint entity of the application plus its adapter(s).


How do end-users interact with the FPX ecosystem?
The user will interact with a client service to initiate the request for resources, and the use of those resources to receive the service. FPX offers two interaction points for the end-users - The Wallet Web UI and the FPX Navigator phone application for Android and iOS. However, to progress through an entire FPX consent flow, the end-users will also interact with at least one Identity Provider interface and may further interact with a Resource Server(s) to take control of their resources at the particular Resource Server. The FPX interfaces offer end-users (resource owners) an intuitive, user-friendly interface to their Wallet from which they can manage their profiles and approach/reject resource access requests.

note

FPX platform-provided UX is an optional feature. The Wallet capabilities can be integrated by the operator into an existing user interface.


What are the various authentication and connectivity methods/protocols supported currently by the Resource Server Adapter? Are additional connectivity protocols being worked upon?
LDAP and OIDC are the two main protocols that are supported by the FPX Resource Server Adapter when connecting to a Resource Server. The Resource Server Adapter can be customized by IDENTOS to meet the requirements of other protocols as needed. The Adapters serve as an interlink between the FPX components and the externally hosted Resource Servers. The protocol-specific adapters help simplify the integration efforts for the clients, in many cases altogether eliminating the need to write any sort of custom code to talk to the FPX components. In addition to the LDAP and OIDC adapters, IDENTOS is also developing additional adapters for protocols such as FHIR and SMART on FHIR.
For more details, refer to Configuring a Resource Server Adapter.


What does the Navigator do? Is it a mandatory requirement for leveraging the FPX platform?
The FPX Navigator is a highly configurable iOS and Android application that an organization may leverage as part of its digital front-door strategy. A branded Navigator app enables the end-users to discover information and services offered by the organization. An organization may choose to turn on a branded Navigator app experience for their end-users, however, this is not a mandatory requirement for leveraging the FPX platform.



FPX Deployments, Backups, Upgrades (Applicable for Client Managed Solutions only)​

How long does a typical deployment and configuration of FPX take?
If the client has a fully functional Kubernetes cluster running along with the other prerequisites of a MySQL database, a typical deployment and configuration of FPX can take anywhere between 1-3 business days.


In the event of service termination, how would the exit strategy work in relation to data repatriation?
All clients that are onboarded to the FPX platform will use a SQL-compatible database management system. Should a program exit be required, these database contents can be exported in an encrypted format and used for later analytics/migrations into external systems as required. From an Identity, Access, and Consent Management perspective, no actual user data is stored by IDENTOS. The FPX platform only serves as a platform that enables users to manage consent to their data whenever requested by a client. Since no user data is stored, there is no separate process required to repatriate any data upon exit from the service. Users can simply revoke all permissions in their account and then log out.


Does IDENTOS have a disaster recovery/business continuity plan in place to support client operations in the event of any unforeseen events?
IDENTOS recommends a multi-region, public cloud-based deployment of FPX to ensure high availability and to provide native failover capabilities. For example, if the solution is deployed within Canada East on the Microsoft Azure platform, a database replica will be deployed to Canada Central as a standby location. In the event that a DR scenario should arise, a new copy of the entire infrastructure will be deployed into Canada Central using infrastructure as Code (IaC) and be connected to the standby database replica.


How does IDENTOS manage version updates and patching?
All updates and changes that are released are first applied to the client’s staging/UAT environment before being deployed to production.Security patches and minor version updates are provided on a regular basis (eg: bi-monthly cadence) and major updates or upgrades are rolled out on a bi-annual basis. Release notes are provided prior to any change and the impact on client operations, if any, is explicitly called out.