eGov Greek Client Consent

The purpose of this document is to describe the technical solution to the eGov Greek Client Consent integration with Ebury services, for which the PRD with requirements have been defined by Product.

We will cover different approaches and alternatives to cover the set of business requirements, documenting key aspects which may approve or discard those approaches as doable.

Problem Description

We can summarize all the requirements of this project in the following key points:

  • Creation of a portal. Which will perform as a landing page for clients when we provide them with unique links we generate to access.
  • Integration with the eGov system. Clients will be redirected to eGov to authenticate and review their personal information.
  • Client data retrieval into Ebury systems. On approval from eGov application, data will be displayed in Ebury portal, and only after the client customer approves, it will be sent to our Ebury systems.
  • Retrieved data reviewed by Onboarding Analysts. After clients give their consent, data will be stored in our systems and made accessible for Onboarding Analysts during the Onboarding or Periodic Review processes.

There are 2 possible flows which would meet with the above requirements:

Ebury Portal Authentication provider and eGov SSO

eGov Greek Client Consent - Salesforce Authentication Flow

This flow follows the next steps:

  1. KyC Analyst sends emails with links to all the related parties under a Greek Client (In the Onboarding or Periodic Review flows).
  2. The client contact opens the link to be directed to the Ebury Portal.
  3. The contact authenticates to the Ebury Portal.
  4. The contact is then redirected to the eGov Portal.
  5. The contact authenticates to the eGov Portal.
  6. The contact is then shown its personal information in eGov, and prompted to consent the data transfer.
  7. The contact is redirected to the Ebury Portal, if consent was provided, then data is displayed in the Ebury Portal.
  8. The contact is prompted again to consent for the data transfer with Ebury.
  9. If data transfer is consented, then data is stored in Ebury systems, and KyC Analyst is notified.
  10. Finally, KyC Analyst updates the transferred data into the FenX system.

eGov Greek Client Consent - Unique Link Flow

  1. KyC Analyst sends emails with unique links to all the related parties under a Greek Client (In the Onboarding or Periodic Review flows).
  2. The client contact opens the link to be directed to the Ebury Portal.
  3. The contact clicks a button to be redirected to the eGov Portal.
  4. The contact authenticates to the eGov Portal.
  5. The contact is then shown its personal information in eGov, and prompted to consent the data transfer.
  6. The contact is redirected to the Ebury Portal, if consent was provided, then data is displayed in the Ebury Portal.
  7. The contact is prompted again to consent for the data transfer with Ebury.
  8. If data transfer is consented, then data is stored in Ebury systems, and KyC Analyst is notified.
  9. Finally, KyC Analyst updates the transferred data into the FenX system.

Background

For regulatory and efficiency reasons we need to change the Greek onboarding process using the government’s e-Gov portal which is a KYC registry. There are 2 reasons this must be completed:

  • Regulatory: The need for clients to use the regulatory portal (called e-Gov) standard that must be completed before the end of the year.
  • Efficiency: Additionally, this will mean we can use the consent and documents that are part of e-Gov rather than requesting multiple forms of documentation + consent for clients.

Solution

Salesforce Experience Cloud (Unauthenticated)

Salesforce Experience Cloud can host a public (unauthenticated) page that can handle the logic around the process.

Building a flow to generate unique, one-time use links that the customers will be able to use to initiate the process, accessing Ebury Portal.

From the Ebury Portal, clients will be able to be redirected to eGov, to authenticate to the government portal, and upon granting consent to share their data, they will be able to see it in Ebury Portal.

Everything will be managed trough OAuth 2.0 authentication flow, in which we will receive a token from eGov to be able to query for the client data.

In this case, no additional licenses are required, compared to one of the alternatives also using Salesforce Experience Cloud with authentication.

This will be a custom mechanism that we will need to develop from our side, in this case the unique links will contain a UUID in the URL, which will be unique for that specific request, and we will use that UUID to validate that the request is expected before proceeding to the Ebury portal. We will also make the link to be only available to be used for 30 minutes, after the user already accessed the page.

These are the key aspects to consider in this customization:

  1. UUIDs will be generated in our back-end, and they will be of 40 characters length.
  2. The link will be sent to the client, so when the client accesses the portal the UUID will be validated in our back-end, in order to grant access to the portal.

The client will be redirected to the eGov page, after accessing the Ebury Portal, but on accessing the external eGov page, then the UUID will be lost from the URL, we need to store it in the web browser, using cookies, because after giving consent from eGov, the client will be redirected back to Ebury Portal, and needs to have the UUID to access it again.

So the UUID would be validated once again, before the user could proceed and see the data in the Ebury Portal.

Notifications

Back-office will need to get notified once a client has granted consent for us to treat their data, so they can proceed and review the data and perform the necessary updates in Salesforce and/or FenX.

We still have pending from Product team to define how users would expect to receive those notifications. But surely they may be generated from Salesforce as Chatters or Emails. WIP

Alternatives

A set of alternatives were considered for this project:

Appian

Appian is a tool which allows creating portals and exposing them through the internet. It also supports OAuth 2.0: Authorization Code Grant, so it meets our requirements.

This option was discarded because it would require 1 license per OAuth call, and we had other alternatives for this project.

Custom Web Forms

BPA team was working on the Periodic Review forms, generating already magic links for users and implementing Firebase for IAM.

In the flow the user receives a link, with their email pre-populated and upon clicking the login button, a cookie is stored in their browser, later we send them a link to confirm their email, which will validate that same cookie.

This option has been discarded, because the Periodic Review design is an exception granted due to extreme time pressure and does not fit within the published Technology Strategy.

Salesforce Experience Cloud (Authenticated Portal)

Salesforce Experience Cloud portal is an option for authenticated flow. We can add a custom Authentication Provider with Open ID Connect for the SSO authentication and allow users to login to the portal.

This would need to be confirmed, as while Open ID Connect is built on top of OAuth2, while the e-Gov system may support it, it's not certain as it's not referenced in their documentation, so its more of an assumption that it may be possible.

If it's not, then a separate set of credentials would be needed for the portal, and handling the OAuth authorization inside the customer component referenced below. We would need access to e-Gov dev/test system to be able to confirm that. From there, using a custom component, we should be able to pick up the authentication token and initiate a request to the e-Gov platform for the customer data (within the context of the Authentication Token that is received as part of the authentication flow.

This option was discarded from Product side, as we would need some Customer Community licenses, that are outlined here as pricing (should be in USD).

Salesforce Site (Unauthenticated)

Salesforce Sites are a simplified version of the unauthenticated Salesforce Experience Cloud option, having a very similar security model.

There are some limitations to Sites though, as they would require us to use Visualforce pages (which are an old and not so much updated Salesforce framework), though we would embed to it the same web software as in the Experience Cloud solution.

In this case, no additional licenses are required.

This option was discarded, as Experience Cloud is a more powerful platform and allows more complex customizations than Salesforce Sites.

Caveats

No caveats discovered so far.

Operation

No operations aside of the software development lifecycle.

Security Impact

As this development includes the development of a portal which will be publicly exposed, there are some security concerns.

Having a public portal could lead to suffering Denial of Service attacks or potential vulnerability exploits in order to perform data leaks.

As described in the multiple possible solutions there are some mechanisms that could be added to add extra layers of security:

  1. Authenticated portal. This is a standard solution provided by Salesforce, which would add extra layer for possible data leaks, as anybody who cannot authenticate will not have access to the portal.
  2. Unique links generation. This would be a customization from our side, which would add extra layer for possible data leaks, as anybody who does not have a link will not have access to the portal.

Even so, independently of those mechanisms, Salesforce includes a feature to deactivate Sites and Experience Clouds that we could use, in case we identify a vulnerability or DDOS attack happening, so Ebury has the mechanism of stopping the attacks and having time to fix the issues without further impact.

Performance Impact

There is no big impact in performance, as from Salesforce side we will only be providing an interface for clients to access. Even if data would be inserted into the database in an asynchronous way, it would not be such a big volume to affect any other business flows.

Developer Impact

We have not identified any big pain points so far in the analysis of this project.

Data Contracts

Though data will be transferred via a new provider, we would not expect the nature of the data to vary from what we are already processing. Neither we are getting any new types of data.

So it should not impact any flows or data reportings.

Deployment

Apart from that, the deployments will follow the regular CI/CD processes already defined for Salesforce developments in the Salesforce CAB.

The only exception will be Portal configurations performed in the Salesforce Experience Cloud, which may not be part of the manageable Metadata, so we will not be able to deploy them.

Dependencies

We are currently working on a POC built on Experience Cloud, so far we only have some blockers regarding access to eGov for testing and lack of details in their documentations of the responses we would expect from their endpoints, all of that we are currently trying to clarify with Product team.

Also, as this is a Public Portal which will be accessed by client customers of Ebury, it would be wise to involve the Product Design team, in order to provide the best User Experience possible, we have raised this topic to Product team, to see if they can allocate resources to work in this project.

References