The edgeWeb component provides a single sign-on (SSO) capability through an extensible framework.
The flow for processing requests is as follows:

• When a client request arrives, a check is made to determine if the relevant AppSession is in the ESTABLISHED state
• • If it is (which it always will be, for example, if no authentication is being used), then edgeWeb proceeds to service the request.
  • If sign-on is already in progress (triggered by another request), then we simply park the request until sign-on completes.
  • If the AppSession is in the INACTIVE state, then it proceeds to sign-on.
  • If the AppSession is in the FAILED state, sign-on will be reattempted.  If this fails, then the client request fails with a status code of 401 (‘unauthorized’).  If there is a need to avoid frequent sign-on attempts, the config property edgeWeb.retrySignOnThreshold can be set to the time (in milliseconds) for which it is desired to wait before reattempting sign-on. Prior to edgeSuite 3.8.1 (and 3.6.3 / 3.7.3), we only proceeded to sign-on if a relevant configuration change has been detected (ie. credentials updated).
• Once sign-on completes, all parked requests, including the one that triggered the sign-on process, are resumed and processed as if they had just arrived. This occurs whether or not sign-on succeeded. This doesn’t represent an infinite loop, however, as the AppSession will now have changed state, to either ESTABLISHED or FAILED.

An AppSession represents the state required to maintain a session with an application server. This includes the authentication state, an HTTP cookie store, and an arbitrary variable store that can be used by SsoHandler implementations to store additional state pertaining to the AppSession. The AppSession also implements the behavior required to control signing on and off, and control the progress of other requests which depend on the state of the session.

By default, an AppSession is scoped to the logged-in EdgeCore user and the connection related to a request, so any feed coming off the connection will share the same AppSession.  If required, the scope can be narrowed to be specific to the feed to which the request relates by setting the SSO Scope property of the feed.

In terms of lifecycle, AppSessions are created when they are needed, and destroyed (after completing the sign-off process) when their owning EdgeCore user session expires or is terminated. The exception to this is AppSessions associated with server polling, which are only destroyed when the EdgeCore server is reinitialized.

Credentials

EdgeCore manages credentials in a general way for all connection types, and they can be specified in one of two ways:

• ‘statically’: associated with the connection so that the same credentials are used for any user viewing content associated with that connection;
• via a variable: as with other ‘secured variables’, credentials can be specified globally, per-domain, or even per-user;