Documentation Center

Configuring SSO in LiveContentGroups.xml

Configure authorization for Content Delivery.

Content Delivery authorization is controlled by the configuration in the file \webapp\WEB-INF\LiveContentGroups.xml. The purpose of the file is to help the authorization pipeline to map attributes coming from a security token into the Content Delivery groups.

Content Delivery acknowledges the following groups:

  • Consumers
  • Tech Docs
  • Contributors
  • Contribution Managers
  • Publication Managers
  • Developers

In the configuration file the mapping can be configured through two distinct segments:

  • User mapping to Content Delivery group
  • Attribute mapping to Content Delivery group

The target Content Delivery group is referenced with app-group.

User mapping has priority over attribute mapping configuration and attribute is even skipped when a user mapping is matched.

User mapping to Content Delivery group

A user node in the users maps a user's username with a Content Delivery group. For example the user with username user@example.com is mapped to the Content Delivery Consumers group.

<user>
	<username>user@example.com</username>
	<app-group>Consumers</app-group>
</user>

Attribute mapping to Content Delivery group

A group node in the groups maps a user's specific attribute with aContent Delivery group. The attribute is specified with the XML attributes:

  • attribute
  • value

For example the user having an attribute role with value RoleA is mapped to the Content DeliveryConsumers group.

<group attribute="role" value="RoleA">
	<app-group>Consumers</app-group>
</group>
sso.permission.group=role,department

When the security token has at least one role attribute then only attribute mappings for role will be considered.

<group attribute="role" value="RoleA">
	<app-group>Consumers</app-group>
</group>
Only when no role attributes are found will attribute mappings for department be considered.

Using a default group

If you are using your own certificate provider, ADFS for example, any user that is not included in a specific group will be allowed access to Content Delivery through a default group.

That group is named Visitors by default. You can change this value in the file LiveContentGroups.xml, under the <defaultgroup> element.

User mapping for Content Delivery publishing and synchronization.

Content Delivery pushed content to Content Delivery as part of a function known as publishing or synchronizing to Content Delivery. Both actions execute under a pre-configured user. This users security token must be mapped to the dba role on Content Delivery.

The executing user depends on Content Manager input parameter issuerwstrustbindingtype.

  • When UserNameMixed then value is derived from input parameter serviceusername. For example ServiceUser.
  • When WindowsMixed then value is derived from input parameter osuser. For example osuser@example.com.

The following example reflects both cases but you only need to use only one.

<user>
	<username>osuser@example.com</username>
	<app-group>dba</app-group>
</user>
<user>
	<username>ServiceUser</username>
	<app-group>dba</app-group>
</user>

Simple example with role mapping

To setup a configuration with conditions:

  • User admin@example.com has always Content Deliverydba rights.
  • All users except (admin@example.com) with role Manager have Content Delivery Contribution Managers and Publication Managers rights.
  • All users except (admin@example.com) with role Administrator have Content Delivery dba rights.

use the following configuration

<mappings>
	<groups>
 		<group attribute="role" value="Administrator">
			<app-group>dba</app-group>
		</group>
 		<group attribute="role" value="Manager">
			<app-group>Contribution Managers</app-group>
		</group>
 		<group attribute="role" value="Manager">
			<app-group>Publication Managers</app-group>
		</group>
	</groups>
	<users>
		<user>
			<username>admin@example.com</username>
			<app-group>dba</app-group>
		</user>
	</users>
</mappings>

Simple example with department mapping

To setup a configuration with conditions:

  • User admin@example.com has always Content Deliverydba rights.
  • No user has a role attribute.
  • All users except (admin@example.com) with department Managers have Content Delivery Contribution Managers and Publication Managers rights.
  • All users except (admin@example.com) with department Administrators have Content Delivery dba rights.

use the following configuration

<mappings>
	<groups>
 		<group attribute="role" value="Administrators">
			<app-group>dba</app-group>
		</group>
 		<group attribute="role" value="Managers">
			<app-group>Contribution Managers</app-group>
		</group>
 		<group attribute="role" value="Managers">
			<app-group>Publication Managers</app-group>
		</group>
	</groups>
	<users>
		<user>
			<username>admin@example.com</username>
			<app-group>dba</app-group>
		</user>
	</users>
</mappings>

Example for Content Manager ISHSTS

Content Manager provides a user repository where every user is assigned to one or more roles. ISHSTS will populate the role attribute with the values of the Content Manager field with nameFISHUSERROLES and value type element. For example:

  • VUSERROLEADMINISTRATOR
  • VUSERROLEAUTHOR
  • VUSERROLEREVIEWER
  • VUSERROLETRANSLATOR

Content Delivery should map these roles as:

Content Manager roleContent Delivery group
VUSERROLEADMINISTRATORdba
VUSERROLEAUTHORPublication Managers
VUSERROLEREVIEWERContribution Managers
VUSERROLETRANSLATORVUSERROLETRANSLATOR

For this example we will assume that ISHSTS is deployed in the default mode of username/password authentication mode. This is the case when input parameter issuerwstrustbindingtype is UserNameMixed. Therefore we need to guarantee a dba group for Content Delivery for the user defined in the input parameter serviceusername.

A suitable configuration is:

<mappings>
	<groups>
        <group attribute="role" value="VUSERROLEADMINISTRATOR">
            <app-group>dba</app-group>
        </group>
        <group attribute="role" value="VUSERROLEAUTHOR">
            <app-group>Publication Managers</app-group>
        </group>
        <group attribute="role" value="VUSERROLEREVIEWER">
            <app-group>Contribution Managers</app-group>
        </group>
        <group attribute="role" value="VUSERROLETRANSLATOR">
            <app-group>Developers</app-group>
        </group>
	</groups>
	<users>
		<user>
			<username>ServiceUser</username>
			<app-group>dba</app-group>
		</user>
	</users>
</mappings>

As an alternative, the ISHSTS can be deployed in windows authentication mode. This is the case when input parameter issuerwstrustbindingtype is WindowsMixed. Therefore we need to guarantee a dba group for Content Delivery for the user defined in the input parameter osuser.. For example osuser@example.com.

The example becomes this
<mappings>
	<groups>
        <group attribute="role" value="VUSERROLEADMINISTRATOR">
            <app-group>dba</app-group>
        </group>
        <group attribute="role" value="VUSERROLEAUTHOR">
            <app-group>Publication Managers</app-group>
        </group>
        <group attribute="role" value="VUSERROLEREVIEWER">
            <app-group>Contribution Managers</app-group>
        </group>
        <group attribute="role" value="VUSERROLETRANSLATOR">
            <app-group>Developers</app-group>
        </group>
	</groups>
	<users>
		<user>
			<username>osuser@example.com</username>
			<app-group>dba</app-group>
		</user>
	</users>
</mappings>