You are viewing the documentation for Blueriq 14. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

When using external flow please make sure that the host and the target runtimes have the same major and minor versions.

Introduction

The external flow is a concept that allows embedding and starting a flow from a different project, without the use of Portal Messages. See Decoupling Pattern 8: External Flow Container for more information.

Definitions

Host RuntimeThe runtime which contains a project that has an AQ_ExternalFlow_ container implementation running.  
Target RuntimeThe runtime which contains a project with a flow that can be started by an AQ_ExternalFlow_ container implementation. 
Source ProfileThe domain model of the source. 
Target ProfileThe domain model of the target.
Interface ProfileThe domain model of the interface
Datastore                                           The location where the serialized profile is stored.

Requirements

In order to use this functionality you need to enable Blueriq External Flow Component.

Configuration

To configure the External Flow Container to work on the runtime you have to do the following:

  1. Enable external-flow profile in bootstrap.properties.
  2. When using mutliple runtimes enable the correct redis sessions
  3. When using a single runtime choose either to use redis or the in memory variant.

External flow functionality saves the profile in a Redis Datastore. Please consult Blueriq External Flow Component in order to see more details on how to configure the runtime to support the external flow.

Using other datastore implementation then Redis

Blueriq provides IExternalFlowStore interface which can be used to interact with a generic datastore. A default implementation is already provided in the Blueriq External Flow Component. If other datastore implementation is desired you can follow these instructions.

Modeling an External Flow

Decoupling Pattern 8: External Flow Container

Flow type: external

Container type: AQ_ExternalFlow

Module type: Contract module

External Flow Endpoints

See External Flow Endpoints.

External Sessions Lifecycle

External sessions are created when different runtimes start an external flow on the current runtime. The external sessions are closed when the http session has expired or it was idle. When the user logs out from the host project or the host session simply expired, the external session has no knowledge of that and will remain open even if not used.

To mitigate the problem an mechanism was introduced that uses the same redis connection (check configuration section) to store information about the host session, and the target runtime will check for all of its host sessions if any of them are closed or are still opened. Every time it finds one that was closed, then it will also close the external sessions that were created by that host session.

Use the same time-out for external sessions and host sessions in order to prevent unexpected 'Session Expired' problems.

Authentication & Authorisation 

When an external flow is executed on a different runtime than the one that the current project is open, there needs to be a way in order for the roles of the currently logged in user to be validated on the target runtime where the external flow resides to. In order to support this, the authentication details of the main project are saved in the External flow Data Store and when the external flow is executed, the authentication is retrieved on the runtime where the external flow resides on, and is set up as if the same user has logged in on that runtime.


When an external flow resides on a different Runtime, that Runtime gains access to the authorisation details of the user that is executing the external flow, and it may make requests to other systems with that user credentials (especially when using OpenID Connect).

When executing an external flow on a different runtime, it is mandatory for both runtimes (the current runtime and the one containing the external flow) to have the same authentication type.

Security

Content-Security-Policy (needed when hostname and/or port are different)

Set Content-Security-Policy on the source to allow access to the remote server:

# Content Security Policy
blueriq.security.click-jacking-protection.content-security-policy.default-src='self' http://target:port

Cross-Origin Resource Sharing (needed when using multiple domains)

When running an external flow from an AQ_ExternalFlow container, requests could be made between different domains. Therefore, for the external flows to work, you need to configure the Cross-Origin Resource Sharing mechanism. For more information, see Security: Cross-Origin Resource Sharing


  • No labels