Documentation Center

Federated Services changes

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 run the scripts after installation as they will have the correct parameters already set. The scripts are located:
  • For Microsoft ADFS, in \App\Setup\STS\ADFS\Scripts\.
  • For ISHSTS, in \App\Setup\STS\ISHSTS\Scripts\.

Out of the box for ISHSTS, our setup routines will add prefixes to the relying party configuration such as ISH, LC and BL. This prefix will be used in our basic claims set transformation (see \Web\InfoShareSTS\Configuration\infoShareSTS.config) so they are immediately ready to go.

Simplified STS configuration

For integrating Content Manager with a Security Token Service (STS), ISHCM and ISHWS require a set of identifiers to be configured within the target Security Token Service. We already had 1 relying party URL for Content Manager web client (ISHCM) and 1 for Content Delivery web client (CD). Previously we required 100+ entries for the Web Services relying party in a scaled setup. From now on we only need 1 relying party URL as well for the Content Manager web services (ISHWS).

Overview

The number of identifiers for ISHWS has been significantly reduced in order to reduce STS related configuration complexity. This improvement makes the STS independent of the Content Manager cluster composition. No action is required on the STS when adding or removing nodes from the cluster.

ISHCM identifiers

ISHCM requires one identifier to be configured on the STS and that is the baseurl/infoshareauthorwebappname/ where baseurl and infoshareauthorwebappname are the values from the input parameters. E.g. https://example.com/ISHCM/.

ISHWS identifiers

ISHWS requires a minimum of one identifier to be configured on the STS and that is the baseurl/infosharewswebappname/ where baseurl and infosharewswebappname are values taken from the input parameters. E.g. https://example.com/ISHWS/. The identifier must be configured with an encryption certificate using the public key of the Content Manager service certificate. This is referenced by the servicecertificatethumbprint input parameter.

The Content Manager has been adjusted to depend only on this identifier. Other integration against ISHWS might require an additional optional set of identifiers depending on their code. This optional set is made of one identifier for each ISHWS WCF endpoint based on this pattern: baseurl/infosharewswebappname/Wcf/API25/Application.svc.

ISHSTS configuration
ISHSTS will automatically seed its database with the required identifiers. For convenience it will also seed the optional set for each svc endpoint. To enforce the re-seeding of the database, this file's version was increased to Web\InfoShareSTS\App_Data\IdentityServerConfiguration-2.2.sdf. The previous version IdentityServerConfiguration-2.1.sdf is now obsolete and should be removed. The scripts folder was moved from \App\Setup\STS\InfoShareSTS\Scripts\ to \App\Setup\STS\ISHSTS\Scripts\. The script files within the folder are renamed to
  • SDL.ISH-ISHSTS-Configure for Windows Authentication.ps1
  • SDL.ISH-ISHSTS-RP-AddRelyingParty.ps1
  • SDL.ISH-ISHSTS-RP-UpdateCertificate.ps1

From within the folder \App\Setup\STS\ISHSTS\Scripts\, the files SDL.LiveContent.Architect-InfoShareSTS-RP-AddNode.ps1 and SDL.LiveContent.Architect-InfoShareSTS-RP-RemoveNode.ps1 are removed because the new configuration requirements are cluster composition independent.

Microsoft Active Directory Federated Services (ADFS) v3 Support

Existing ADFS relying parties must be deleted and then replaced by new ones to reflect the changes described here. All scripts in \App\Setup\ADFS\Scripts\ are renamed to match the current version of ADFS (ADFSv3.0 for this release). The script SDL.ISH-ADFSv3.0-RP-Install.ps1 script will create on ADFS the necessary relying parties. As with ISHSTS, the optional set for each svc endpoint is also added for convenience.

The files SDL.LiveContent.Architect-ADFSv2.0-RP-AddNode.ps1 and SDL.LiveContent.Architect-ADFSv2.0-RP-RemoveNode.ps1 are removed because the new configuration requirements is cluster composition independent.

Documentation

New content describes deployment guidelines and limitations of various setups. There is now, 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 ISHSTS.

Customers authenticating with on-premises Microsoft ADFS STS can use a SDL Knowledge Center installation deployed on SDL hosted servers outside their network. The services (web sites like ISHCM, ISHWS, Content Delivery, Quality Assistant, etc) can be configured to accept a token from ISHSTS additional to the originally configured ADFS 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 ADFS and SDL Knowledge Center products. The solution is based on using the internal ISHSTS as the STS for all back-end initiated activities. This configuration removes the dependency on the customer's ADFS. Out-of-the-box ISHSTS allows delegation with tokens that were issued only from itself. All back-end activated entities are redirected to use ISHSTS as their issuer instead of the customer's ADFS.

For Security Token Services other than ISHSTS and ADFS, such as PingIdentity, the Security Token Service Requirements chapter is added to explain what is necessary for the successful integration of Content Manager and the Security Token Service.

To help advance 3rd party integrations, a best practices topic has been added. When integrators utilize the suggested pattern then the optional set of identifiers is no longer required.

Light weight Windows Authentication on ISHSTS

Our backward compatible solution ISHSTS was created to allow customers relying on Content Manager user accounts (read Trisoft accounts) to continue to work but still have the benefits of a Secure Token Service (STS) and Single Sign On (SSO) across the Knowledge Center solution. From an STS perspective ISHSTS forced authentication by requesting a valid username/password combination which would be validated in the Content Manager repository.

A popular request was to re-introduce simple Windows Authentication without introducing Microsoft Active Directory Federated Services (ADFS) in the environment. We now offer indirect Windows Authentication on top of ISHSTS. This is a light weight solution that is provided for hidden authentication by your logged on Windows account. [TS-8818].
An overview of typical combinations that are confirmed by the field is provided below. For a more elaborate description of the inputparameters.xml parameters, refer to the installation documentation.
Choose your STS, then your Authentication TypeISHSTS by UsernameAuthISHSTS by WinAuthADFSv3 by WinAuth
issuerwstrustbindingtypeUsernameMixedWindowsMixedWindowsMixed
issuerwstrustendpointurlBASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mixed/usernameBASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mixed/windowsADFSURL/adfs/serices/trust/13/windowsmixed
issuerwsfederationendpointurlBASEURL/INFOSHARESTSWEBAPPNAME/issue/wsfedBASEURL/INFOSHARESTSWEBAPPNAME/issue/wsfedADFSURL/adfs/ls/
issuerwstrustmexurlBASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mexBASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mexADFSURL/adfs/services/trust/mex
serviceusernameServiceUserempty, the account of osuser will be usedempty, the account of osuser will be used
servicepasswordED47BA6B...emptyempty
issueractorusernameValue of serviceusernameValue of osuserValue of osuser
issueractorpasswordValue of servicepasswordemptyempty

To be able to use this you need to add an Operating System feature/role for enabling Internet Information Services (IIS) Windows Authentication (Internet Information Services > World Wide Web Services > Security > Windows Authentication) on ISHSTS after installation. [TS-8816]

Other changes

All future active profile requests will no longer force a token type from the client side. Do note that we still require an OASIS SAML 1.1 token as a result. In practice Trisoft.Utilities.ServiceReferences is used to pass <trust:RequestSecurityToken><trust:TokenType>urn:oasis:names:tc:SAML:1.0:assertion in its token request which confused some Secure Token Services (STS) like PingIdentity PingFederate. [TS-9049|TS-9034|SRQ-2523]

In previous versions of ISHSTS, the actor user for delegation purposes - like server-side connection of web client code to web services code - was never verified as an existing account. From now on a valid account has to be specified at installation time through inputparameters.xml parameters issueractorusername and issueractorpassword. The actor must exist in the Content Manager repository as an Internal user. We recommended to use the same as the ServiceUser, see inputparameters.xml parameters serviceusername and servicepassword.