Federated Services changes
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
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/wherebaseurlandinfoshareauthorwebappnameare 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/wherebaseurlandinfosharewswebappnameare 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 theservicecertificatethumbprintinput 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.0for 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
- 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.
| Choose your STS, then your Authentication Type | ISHSTS by UsernameAuth | ISHSTS by WinAuth | ADFSv3 by WinAuth |
|---|---|---|---|
issuerwstrustbindingtype | UsernameMixed | WindowsMixed | WindowsMixed |
issuerwstrustendpointurl | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mixed/username | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mixed/windows | ADFSURL/adfs/serices/trust/13/windowsmixed |
issuerwsfederationendpointurl | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wsfed | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wsfed | ADFSURL/adfs/ls/ |
issuerwstrustmexurl | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mex | BASEURL/INFOSHARESTSWEBAPPNAME/issue/wstrust/mex | ADFSURL/adfs/services/trust/mex |
serviceusername | ServiceUser | empty, the account of osuser will be used | empty, the account of osuser will be used |
servicepassword | ED47BA6B... | empty | empty |
issueractorusername | Value of serviceusername | Value of osuser | Value of osuser |
issueractorpassword | Value of servicepassword | empty | empty |
To be able to use this you need to add an Operating System feature/role for enabling Internet Information Services (IIS) 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.