Dev:Partner creation processes: Difference between revisions
Stefanseiler (talk | contribs) |
Stefanseiler (talk | contribs) |
||
| Line 29: | Line 29: | ||
=== How digital creation generally works === | === 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) === | === How login works in distributed environments (here: Kordeus.PAX) === | ||
Revision as of 14:32, 9 December 2025
Tehre is no portal which is used to create digitals. Instead it means pages of PAX-Portal and MOC-SARA, which have the power to create digitals on target realms with predefined configurations.
| 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 as well a user is created. In the SAR-Collaboration, this means, that these users are propagated to the known other portals, so these digitals can login at the desired portals as well.
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.