Dev:Partner creation processes

From Kordeus Wiki
Revision as of 12:31, 10 December 2025 by Stefanseiler (talk | contribs)
Jump to navigation Jump to search

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.
    • 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-Login process

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

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