Dev:Partner creation processes: Difference between revisions
Stefanseiler (talk | contribs) m Stefanseiler moved page SARA.PartnerCreationPortal to Dev:Partner creation processes without leaving a redirect |
Stefanseiler (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
== 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? ====== | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
!Created digital type ➡️ | !Created digital type ➡️ | ||
| Line 26: | Line 29: | ||
|🔑 Login | |🔑 Login | ||
|} | |} | ||
Creation of a new digital means that | 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 === | === How digital creation generally works === | ||
Revision as of 12:31, 10 December 2025
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
- receives a digital creation api-key per target realm in which to create a local digital which allows
- 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.
- 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:
- 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.