Optimized Federated Services
The federated services and claims-based authentication system received improvements to reduce network traffic.
General
- 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
- 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).
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.
- The identity model configuration states to use
SequencedSessionSecurityTokenCacheas follows.<system.identityModel> [...] <caches> <sessionSecurityTokenCache type="Trisoft.Utilities.IdentityModel.Cache.SequencedSessionSecurityTokenCache, [...]" /> </caches> </identityConfiguration> </system.identityModel> - Our cache implementation will use the current in-process memory cache for quick lookup as specified through
MruSessionSecurityTokenCache. If not found,IshSessionSecurityTokenRepositorwill 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> - Outdated sessions that were persisted in the database are regularly cleaned up as part of the
ISh_StandardInfoShareJob.