Documentation Center

Configuring SSO in LiveContentGroups.xml

Configure authorization for Collaborative Review .

Collaborative Review 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 Collaborative Review groups.

Collaborative Review 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 Collaborative Review group
  • Attribute mapping to Collaborative Review group

The target Collaborative Review 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 Collaborative Review group

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

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

Attribute mapping to Collaborative Review group

A group node in the groups maps a user's specific attribute with a Collaborative Review 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 Collaborative Review Consumers 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 Collaborative Review 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 Collaborative Review publishing and synchronization.

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

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 Collaborative Review dba rights.
  • All users except (admin@example.com) with role Manager have Collaborative Review Contribution Managers and Publication Managers rights.
  • All users except (admin@example.com) with role Administrator have Collaborative Review 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 Collaborative Review dba rights.
  • No user has a role attribute.
  • All users except (admin@example.com) with department Managers have Collaborative Review Contribution Managers and Publication Managers rights.
  • All users except (admin@example.com) with department Administrators have Collaborative Review 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

Collaborative Review should map these roles as:

Content Manager roleCollaborative Review 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 Collaborative Review 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 Collaborative Review 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>