Dev:Partner creation processes

Distributed infrastructure

Example Realm Setup

Kordeus.PAX operates in a distributed data ecosystem, which means that different b-op digitals can reside wherever they want to reside and still the network functions as if they were working together as one system according to their trust-relations.

A typical setup for Kordeus.PAX ecosystem looks like this:

• Medical Operations Realm - This realm hosts the core digitals of the airlines and the operation center digitals. This realm runs the backend applications (SARA, Admin-Tools)
• Medial Cloud Realm(s) - These realms host their business partners, holding the data of them (PAX, Travel Partners, Delivery Partners)
• Portal Operation Realms - These realms are operating the portals and are focused on being publicly accessible. Typically they are one realm per portal to scale performance and keep these portals independent from each other.

Digital creation

There are multiple parties in the Kordeus.PAX ecosystem, which can create digitals for partners, to allow a distributed collaboration model.

Which digital type can create others?

Created digital type ➡️ ⬇️ Creating digital type	PAX	Travel Partner	Delivery Partner
MOC Digitals	➕ Create	➕ Create	➕ Create
PAX Portal Digitals	➕ Create & 🔑 Login	🔑 Login
Delivery Portal Digitals			🔑 Login

Creation of a new digital means that it is deployed with:

• at least one user
• trust relations are established with other players (e.g. other known PAX-Portal digitals, Operation center digitals or Travel partner digitals)
• applications deployed, which are required for operations

How digital creation generally works

The local digital

1. receives a digital creation api-key per target realm in which to create a local digital which allows
2. With this api-key and a json which holds the information of the digital to create (type, email, ... ) it invokes the endpoint and waits for a creation response.
3. The endpoint invoked is an app operating under the remote realm concierge digital, which
   • issues a RRE-Command to create the new digital from a digital creation template, which controls the creation process.
   • Builds trust relations with the intended digitals (other PAX portals, SARA)
   • returns synchronously the result of the operation (OK/NOK, creation info)

How login works in distributed environments (here: Kordeus.PAX)

After a remote digital is registered as known business participant with its user(s) and the remote authentication is enabled on the remote digital, the user can log-in using the portals for which this user is registered

1. Pre-Authentication process

The user navigates his browser to the portal startup page, which:

• first creates a session identification token (SIT) and then
• resolves the authentication ruleset for the client browsers invoking URL (see /DetermineAuthRuleSetFromClientURL)
• checks if a valid user identification token (UIT) is present. If so, the user is logged in and the portal's main application is launched

2. Login path selection process

If there are multiple login paths available in the applicable AuthRuleSet, the login-path selection page of the application is invoked.

This only applies to PAX-Portal, where there are three authentication paths:

• Passenger with TavelID (Miles-And-More account)
• Passenger with email
• Travel agent

The users selection determines the final AuthRuleset to use, with which the authentication process is triggered

3. Login process

The login process adheres to the standard process of user authentication agent (UAA): The may use local or a remote digital's authentication factor plugins to which the user's browser sessions is redirected. After each provided factor the SIT is elevated until the UIT is created and the portal's main application is launched.

See also

• Kordeus.PAX