Documentation Center

Optimized Federated Services

The federated services and claims-based authentication system received improvements to reduce network traffic.

General

Several scripts are added to simplify your maintenance across server nodes. We advise you to take the scripts after installation as they will have the correct parameters already set, these can be found in:
  • For Microsoft ADFS, in \App\Setup\STS\ADFS\Scripts.
  • For InfoShareSTS, in \App\Setup\STS\InfoShareSTS\Scripts.

Out of the box for InfoShareSTS, our setup routines will add prefixes to the relying party configuration like Architect, Reach and Enrich. This prefix will be used in our basic claims set transformation, see \Websites\InfoShareSTS\Configuration\infoShareSTS.config so they are immediately ready to go.

Documentation

New topics that describe deployment guidelines and limitations of various setups. For example:
  • An explanation on front-end certificate usage (in for example Network Load Balancing scenarios) and back-end (batch) certificate usage.
  • Security flows and scaling limitations of InfoShareSTS.

Customers authenticating with on-premises Microsoft ADFSv2 STS can use a LiveContent installation deployed on SDL hosted servers outside their network. The services (web sites like InfoShareAuthor, InfoShareWS, Reach, Erich, etc) can be configured to accept a token from InfoShareSTS additional to the originally configured ADFSv2 one. This configuration removes the dependancy of delegated services or even background tasks to connect to your on-premises STS installation which is usually not accessible because of your company's firewall.

All clients (browsers and client tools) running from the customers network have access to both ADFSv2 and LiveContent products. The solution is based on using the internal InfoShareSTS as the STS for all back-end initiated activities. This configuration removes the dependancy on the customer's ADFSv2. Out-of-the-box InfoShareSTS (IdentityServerV2) allows delegation with tokens that were issued only from itself. All back-end activated entities are redirected to use InfoShareSTS as their issuer instead of the customer's ADFSv2.

‘How to’ information can be found in the Information Portal documentation.

Reducing network traffic

Every HTTP request to our services (web client and web services) always put a big state description on the wire in the previous release (10.0.x). The state description was required to make any server act as a big calculator, or in essence making the whole system stateless. To avoid the state description's pay load to be communicated over-and-over again, we introduce a caching mechanism. In practice, also browsers and proxy servers could cause the application to fail with HTTP 400 - Bad Request, typically caused by an overload of cookies (typically aggregating to 16KB in size, a well known limit).

It is actually your Secure Token Service (STS) - for example Microsoft ADFS or our backward compatible solution InfoShareSTS- that drives the size of the claim set, hence the FedAuth cookie by parameters like:
  • Token signing certificate strength and details (e.g. CN).
  • The number of claims packaged.
  • If delegation is setup, extra bootstrap information is added.

The Relying Party (RP) - for example InfoShareAuthor or InfoShareWS - will now take responsibility to store the bigger part of the claims set. When using a single-server setup you could choose to store it in memory which offers better performance, but if the hosting process dies (e.g. ApplicationPool) you have to redo the handshake. A persistence mechanism was added and allows to support multi server setups.

Our RP's web.config are out of the box configured for a combination of a memory-cache and upon cache-miss a lookup in our database.
  1. The identity model configuration states to use SequencedSessionSecurityTokenCache as follows.
    <system.identityModel>
        [...] 
        <caches>
          <sessionSecurityTokenCache type="Trisoft.Utilities.IdentityModel.Cache.SequencedSessionSecurityTokenCache, [...]" />
        </caches>
      </identityConfiguration>
    </system.identityModel>
    
  2. Our cache implementation will use the current in-process memory cache for quick lookup as specified through MruSessionSecurityTokenCache. If not found, IshSessionSecurityTokenRepositor will look up the session in our database (table ISH_SESSIONSECURITYTOKEN).
    <trisoft.utilities.identityModel>
        <sequencedSessionSecurityTokenCacheProviders>
          <provider cacheType="Trisoft.Utilities.IdentityModel.Cache.MruSessionSecurityTokenCache, [...]" />
          <provider repositorType="Trisoft.InfoShare.Core.IdentityModel.IshSessionSecurityTokenRepositor, [...]" />
        </sequencedSessionSecurityTokenCacheProviders>
        <isReferenceModeSettings enableWeb="true" enableWcf="false" />
      </trisoft.utilities.identityModel>
  3. Outdated sessions that were persisted in the database are regularly cleaned up as part of the ISh_StandardInfoShareJob.