Group Management

Cinchy Groups

Cinchy Groups are containers that contain Users and other Groups within them as members, and used to provision access controls throughout the platform. Cinchy Groups enable centralized administration for access controls.

Groups are defined in the "Groups" table within the Cinchy domain. By default this table can only be managed by members of the Cinchy Administrators group. Each group has the following attributes:

• Name - Group name, this must be unique across all groups within the system

• Users - Users which are members of the group

• User Groups - Groups which are members of the group

• Owners - Users which are able to administer the membership of this group. By default Owners are also members of the group (i.e. they do not need to also be added into Users).

• Owner Groups - Groups whose members are able to administer the membership of this group. By default, members of Owner Groups are also members of the group (i.e. they do not need to also be added into Users or User Groups).

• Group Type - Either "Cinchy Group" or "AD Group". If this is a "Cinchy Group", this means that membership is maintained directly in Cinchy. If this is an "AD Group", then a sync process will be leveraged to maintain the membership and overwrite the Users.

How to define a new AD Group

1. Create a new record within the Groups Table with the same name as the AD Group (use the cn attribute).

2. Set the Group Type = "AD Group".

How to convert an existing group to sync with AD

1. Update the Name attribute of the existing group record to match the AD Group (use the cn attribute).

2. Set the Group Type to "AD Group".

Group Membership Sync

AD Groups defined in Cinchy have their members sync'ed from AD through a batch process that leverages the Cinchy Command-line-interface (CLI).

Execution Flow

The sync operation performs the following high-level steps:

1. Fetches all Cinchy registered AD Groups using a Saved Query.

2. Retrieves the usernames of all members for each AD Group. The default attribute for username that is retrieved is "userPrincipalName", but configurable as part of the sync process.

3. For each AD Group, loads the users that are both a member in AD and exist in the Cinchy Users table (matched on the Username) into the "Users" attribute of the Cinchy Groups table.

Dependencies

1. Cinchy CLI Model must be installed in your instance of Cinchy, steps are mentioned here

2. An instance of the Cinchy CLI must be available to execute the sync

3. A task scheduler is required to perform the sync on a regular basis (e.g. Autosys)

Configuration Steps

Create a Saved Query to retrieve AD Groups from Cinchy

Create a new query within Cinchy with the below CQL to fetch all AD Groups from the Groups table. The domain & name assigned to the query will be referenced in the subsequent step.

SELECT [Name]
FROM [Cinchy].[Cinchy].[Groups]
WHERE [Group Type] = 'AD Group' 
AND [Deleted] IS NULL

Create the Sync Config

Copy the below XML into a text editor of your choice and update the attributes listed in the table below the XML to align to your environment specific settings. Once complete, create an entry with the config in your Data Sync Configurations table (part of the Cinchy CLI model).

<?xml version="1.0" encoding="utf-16" ?>
<BatchDataSyncConfig name="AD_GROUP_SYNC" version="1.0.0" xmlns="http://www.cinchy.co">
  <Parameters />
  <LDAPDataSource objectCategory="group" ldapserver="LDAP:\\activedirectoryserver.domain.com" username="encryptedUsername" password="encryptedPassword" >
    <Schema>
      <Column name="cn" ordinal="1" dataType="Text" maxLength="5000" isMandatory="false" validateData="false" trimWhitespace="true" description=""/>
      <Column name="member.userPrincipalName" ordinal="2" dataType="Text" maxLength="200" isMandatory="false" validateData="false" trimWhitespace="true" description=""/>
    </Schema>
    <Filter>
      lookup('Domain Name','Query Name')
    </Filter>
  </LDAPDataSource>
  <CinchyTableTarget model="" domain="Cinchy" table="Groups" suppressDuplicateErrors="false">
    <ColumnMappings>
      <ColumnMapping sourceColumn="cn" targetColumn="name" />
      <ColumnMapping sourceColumn="member.userPrincipalName" targetColumn="Users" linkColumn="Username" />
    </ColumnMappings>
    <SyncKey>
      <SyncKeyColumnReference name="name" />
    </SyncKey>
	<ChangedRecordBehaviour type="UPDATE" />
    <DroppedRecordBehaviour type="IGNORE" />
  </CinchyTableTarget>
</BatchDataSyncConfig>

Sync Execution & Scheduling

The below CLI command (see here for additional information on the syncdata command) should be used to execute the sync. Update the command parameters (described in the table below) with your environment specific settings. Execution of this command can be scheduled at your desired frequency using your scheduler of choice.

dotnet Cinchy.CLI.dll syncdata -s cinchyAppServer -u username -p "encryptedPassword" -m "Model" -f "AD_GROUP_SYNC" -d "TempDirectory" 

References

• Cinchy CLI Reference

• Syncdata Command

Overview

Cinchy supports integration with any Identity Provider that issues SAML tokens (e.g. Active Directory Federation Services) for authenticating users. It follows an SP Initiated SSO pattern where the SP will Redirect to the IdP and the IdP must submit the SAML Response via an HTTP Post to the SP Assertion Consumer Service. Below is a diagram outlining the flow when a non-authenticated user attempt to access a Cinchy resource.

Configure SAML Authentication

Cinchy must be registered with the Identity Provider. As part of that process you'll supply the Assertion Consumer Service URL, choose a client identifier for the Cinchy application, and generate a metadata XML file.

The Assertion Consumer Service URL for Cinchy is the base URL for the CinchySSO application followed by "/{AcsURLModule}/Acs" e.g. https://myCinchyServer/CinchySSO/identity/AuthServices/Acs. {AcsURLModule} value needs to be defined in appsettings.json file

To enable SAML authentication within Cinchy, follow the below steps:

1. You can find the necessary metadata XML from the applicable identity provider you're using the login against. Place the metadata file in the deployment directory of the CinchySSO web application.

2. Update the value of the below app settings in the CinchySSO appsettings.json file.

• SAMLClientEntityId - The client identifier chosen when registering with the Identity Provider

• SAMLIDPEntityId - The entityID from the Identity Provider metadata XML

• SAMLMetadataXmlPath - The full path to the metadata XML file

• AcsURLModule - This parameter is needs to be configured as per your SAML ACS URL.

  • Example ACS URL: "https:///CinchySSO/identity/AuthServices/Acs"

  • Example parameter value: "/identity/AuthServices"

3. The following parameters pertain to signed SAML IdP requests. Within the IDPSSODescriptor tag of the metadata is the below WantAuthnRequestSigned attribute:

If the value for this attribute is set to "true" then your Identity Provider is expecting the request to be "Signed". In this case, please enter the following parameters:

• SAMLSignCertificatePath - This parameter needs to be the path for the PFX file of the certificate. This must match the same certificate in your identity provider.

• SAMLSignCertificatePassword - This parameter is the password for the above mentioned PFX file. You may choose to encrypt it or not.

• SAMLSignCertificateMinAlgorithm - This parameter is optional and only needed for PFX files that are generated at different algorithm levels.

  • The possible options for this parameter are:

    • SHA1

    • SHA256

    • SHA384

    • SHA512

    • http://www.w3.org/2000/09/xmldsig#rsa-sha1

    • http://www.w3.org/2000/09/xmldsig#rsa-sha256

    • http://www.w3.org/2000/09/xmldsig#rsa-sha384

    • http://www.w3.org/2000/09/xmldsig#rsa-sha512

4. If the Identity Provider is configured for the request to be encrypted please provide a PFX file, with a non-empty password, for the below attributes:

• SAMLEncryptedCertificatePath - This parameter needs to be the path for the PFX file of the certificate. This must match the same certificate in your identity provider.

• SAMLEncryptedCertificatePassword - This parameter is the password for the above mentioned PFX file.

Once SSO is enabled, the next time a user arrives at the Cinchy login screen they will see an additional button "Single Sign-On". Before a user is able to login through the SSO flow, the user must be set up in Cinchy with the appropriate authentication configuration. See the User Management section below for instructions on how to perform this setup.

User Management

Users in Cinchy are maintained within the Users table in the Cinchy domain. Each user in the system is configured with 1 of 3 Authentication Methods:

• Cinchy User Account - These are users that are created and managed directly in the Cinchy application. They log into Cinchy by entering their username and password on the login screen.

• Non Interactive - These accounts are intended for application use.

• Single Sign-On - These users authenticate through the SSO Identity Provider (configured using the steps above). They log into Cinchy by clicking the "Login with Single Sign-On" link on the login screen.

How to define a new SSO User

Create a new record within the Users table with the Authentication Method set to "Single Sign-On".

How to convert an existing user to SSO User

Change the Authentication Method of the existing user to "Single Sign-On".

Logging in with SSO

Once a user is configured for SSO, they can then click the "Login with Single Sign-On" link on the login page and that will then take them through the Identity Provider's authentication flow and bring them into Cinchy.

Automatic User Creation

Once SSO has been enabled on your instance of Cinchy, by default, any user that does not exist in the Cinchy Users table will not be able to login regardless if they are authenticated by the Identity Provider.

Enabling Automatic User Creation means that upon login, if the Identity Provider authorizes the user, an entry for this user will automatically be created in the Cinchy Users table if one does not already exist. This means that any SSO authenticated user is guaranteed to be able to access the platform.

See below for details on how to enable Automatic User Creation.

Pre-requisites

The Identity Provider configuration must include the following claims in addition to the base configuration in the SAML token response:

• First Name

• Last Name

• Email

In order to enable automatic group assignment for newly created users (applicable if you plan on using AD Groups), then also include an attribute that captures the groups that this user is a member of (e.g. memberOf field in AD)

Config setup

Enabling automatic user creation requires the following changes to the appsettings.json file in the CinchySSO web application.

• Add "ExternalClaimName" attribute values under "ExternalIdentityClaimSection" in appsettings.json file. Do not add the value for "MemberOf" if you don't want to enable automatic group assignment .

• The ExternalClaimName value must be updated to create a mapping between the attribute name in the SAML response and the required field. (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname is the name in the SAML response for the FirstName field)

If you are syncing someone with a lot of ADFS groups, the server may reject the request for the header being too large. If you are able to login as a user with a few groups in ADFS but run into an error with users with a lot of ADFS groups (regardless of if those ADFS groups are in Cinchy), you will need to make 2 changes.

Server Max Request Header Size

CinchySSO App Settings

In your CinchySSO app settings, you will also need to increase the max size of the request header.

ADFS Configuration

On your ADFS Server, Open AD FS Management.

Righ-click on Relying Party Trusts and select Add Relying Party Trust. This will launch the Add Relying Party Trust Wizard.

ADFS Wizard

Welcome

Select Claims aware. Click Start.

Select Data Source

Choose Enter data about the relying party manually. Click Next.

Specify Display Name

Enter a Display Name of your choice.

Configure Certificate

Do not choose any certificates.

Configure URL

Select Enable support for the SAML 2.0 SSO Web SSO protocol.

Enter your login URL in the following format:

Configure Identifiers, Choose Access Control Policy, Ready to Add Trust, Finish

Choose an Identifier and click Next until you are complete.

Claim Issuance Policy

1. Right-click on the Relying Party Trust you just created (look for the Display Name) and click Edit Claim Issuance Policy.

2. Click on the Add Rule... and choose Claim Rule as Send LDAP Attributes as Claims.

3. Add Claim rule name, choose Active Directory under Attribute store and map LDAP attribute to outgoing claim types:

4. Click Finish.

5. Click on Edit Rule...

6. Click on View Rule Language and copy out the Claim URLs for the claims defined. This information will be needed in a later step to configure your Cinchy appsettings.json. This will look something like this:

7. Click Ok to save the rule.

8. Right-click on your Relying Party Trust again and click Properties.

9. Go to the Advanced tab and set the secure hash algorithm to SHA-256

Cinchy Configuration

1. Open https://<your.AD.server>/FederationMetadata/2007-06/FederationMetadata.xml in a browser and save the XML file in the cinchysso folder.

2. Open IIS Manager and create an HTTPS binding on the Cinchy site (if necessary).

3. Go to sso site and bind HTTPS with it. Make sure to use the same port as the login URL above if specified.

Cinchy appsettings.json

AppSettings Section

External Identity Claim Section

You will need the Rule Language URLs you copied out from the ADFS Configuration above. Using the same example as above, we would get the following (replace with your own URLs).

Web.config

Add the 3 following lines to your web.config within the appSettings section: