When a business application communicates with a service, you must decide whether you want to propagate the identity of the user that called the business application, or if a call from machine-to-machine is sufficient.
If the business application triggers an action of the service that should be auditable or requires that the identity of the user be known, use principal propagation. Principal propagation enables the identity of the user to be propagated from the business application to the service.
If the business application triggers an action of the service for which the identity of the user is unimportant, such as a regular clean-up task or the checking of a queue, then you can use technical communication. In technical communication, the service performs the action for the business application without knowing the identity of the user.
Cross-Application API Calls from an External System to Applications in the Cloud Foundry Environment
If applications from an external system must make API calls to applications running in the Cloud Foundry environment, administrators must make sure that these applications can communicate with the relevant applications in the external system. In this case, the bearer assertion flow or client credentials identify the external application at the UAA, which can then issue a JSON web token. The external application can use this JSON web token when it makes the API calls to applications in the Cloud Foundry environment.
No browser is involved here. Users are propagated in the following ways:
-
Using technical communication, for example, propagating scopes and authorities.
-
Using a bearer assertion or client credentials (JSON web tokens) to propagate named users.
Related Information
Principal Propagation with Tightly Coupled Developments