Configuring Users and Permissions

Users, their passwords, and Permissions can be edited within 1Integrate.

Both Users and Permissions are the same for WebLogic and WildFly installations of 1Integrate. It is only the method of assigning these to users that differs.

     Note: Access to the different sections of 1Integrate is controlled by a series of Permissions. Changing these permissions is achieved by altering the Roles in your chosen Application Server (WebLogic or WildFly)

     Warning: By default, 1Integrate is deployed with example users and passwords included. This enables a quick set-up process, but for security reasons it is HIGHLY RECOMMENDED that:

  • As a minimum, on installation, change all passwords from the default to unique values.

  • Change the user names to ones relevant to your organisation.

  • Do not store users and passwords in plain text

For stronger security and management, consider using other authentication mechanisms such as using your organisation's Lightweight Directory Access Protocol (LDAP) Service e.g. Microsoft Active Directory. This ensures that passwords and usernames are not stored in the application server but managed, as normal, by an IT department.

Permissions

Each user is assigned one or more Permission. These permissions determine a user's privileges and the areas of the functionality to which they have access.

When configuring Permissions in the application server they will be interchangeably known as "Roles", but the two terms are interchangeable.

Permission

Description

1int-datastores-read

Grants the ability to read Data Store objects and folders at the endpoint.

1int-datastores-write

Grants the ability to write Data Store objects and folders at the endpoint..

1int-rules-read

Grants the ability to read Rule objects and folders at the endpoint..

1int-rules-write

Grants the ability to write Data Rule objects and folders at the endpoint..

1int-actions-read

Grants the ability to read Action objects and folders at the endpoint.

1int-actions-write

Grants the ability to write Action objects and folders at the endpoint.

1int-actionmaps-read

Grants the ability to read Action Map object and folders at the endpoint.

1int-actionmaps-write

Grants the ability to write Action Map objects and folders at the endpoint.

1int-sessions-read

Grants the ability to read Session objects and folders at the endpoint.

1int-sessions-write

Grants the ability to write and edit the Session objects and edit folders.

1int-sessions-control

Grants the ability to control a session with the "Play", "Pause", "Rewind" and "Stop" functions.

1int-sessions-results

Grants the ability to access all Session results, including both Task and Session results i.e. Validation errors.

1int-grid-read

Grants the ability to view the engine grid.

1int-grid-write

Grants the ability to edit the engine grid.

1int-api-keys

Grants the ability to manage the API Key functionality in the Dashboard section.

1int-access-groups

Grants the ability to manage and configure Access Groups.

1int-repository

Grants the ability to access the Repository Administration functions and to see the Environment and System Properties.

Group Permissions

There are two sets of group permissions available that can be used to quickly assign a common set of permissions to a user.

Group Permission

Description

1int-user

The User is designed to be applied to standard users, this role includes:

  • 1int-datastores-read

  • 1int-datastores-write

  • 1int-rules-read

  • 1int-rules-write

  • 1int-actions-read

  • 1int-actions-write

  • 1int-actionmaps-read

  • 1int-actionmaps-write

  • 1int-sessions-read

  • 1int-sessions-write

  • 1int-sessions-control

  • 1int-sessions-results

  • 1int-grid-read

1int-admin

The Admin to includes all permissions and is designed for those that will be performing administrative functions.

Includes all the permissions of 1int-user with the addition of:

  • 1int-grid-write

  • 1int-api-keys

  • 1int-access-groups

  • 1int-repository

Default Users

The following users are created by default upon installation:

Username

Password

Assigned permissions

INTFull

integrate1

This default User has the 1int-admin Group Permission applied.

INTAdmin

integrate101

This default User has the 1int-admin Group Permission applied.

INTUser

integrate102

This default User has the 1int-user Group Permission applied.

     Note: You will need to restart 1Integrate for any changes to user and permissions to take effect.

WebLogic Users

1Integrate Users and the Permissions they are assigned should be configured using the WebLogic Server Administrator Console.

Unlike the default Users that are created, the Permission names (known as roles in WebLogic) set up by installer must not be altered.

     Note: The default setup assigns the default users to some of the default Permissions (known as roles in WebLogic), allowing you to log in and start using 1Integrate without having to change any of the security configuration. If you wish to customise the users, then WebLogic role assignment can be altered.

WildFly Users

To configure Users and Permissions, navigate to the \wildfly-[version]\SETTINGS folder. This folder contains the following files:

  • users.properties contains a list of usernames and passwords, in the form username=password.

     Note: All users listed in the previous table are included as default.

  • roles.properties contains a mapping from user names to 1Integrate permissions in the form username=permission1,permission2,permission3

LDAP

For stronger security and management, Consider using other authentication and authorisation mechanisms such as your organisation's Lightweight Directory Access Protocol (LDAP) Service e.g. Microsoft Active Directory. This ensures that passwords and usernames are not stored in the application server but managed, as normal, by an IT department.

Authenticate using LDAP (WebLogic)

For information on configuring WebLogic in this way, please refer to the Oracle documentation:

https://docs.oracle.com/en/middleware/standalone/weblogic-server/14.1.1.0/secmg/atn.html#GUID-46CB94C0-BF0A-4788-8E93-0D322DA67462

Authenticate using LDAP (WildFly)

The default WildFly configuration of storing passwords as plain text is not recommended for production use. To configure 1Integrate to use your organisation's LDAP service in WildFly, perform the following configuration:

ClosedConfigure an LDAP service

  1. Find the settings.properties file, to locate this go to: [1Integrate_Directory]\SETTINGS\.

  2. Uncomment the following and fill with your LDAP values:

  3. #ldap.authentication.enabled=true
    #ldap.host=
    #ldap.principal=
    #ldap.credential=
    #ldap.username.attribute=
    #ldap.user.base.dn=
    #ldap.group.attribute=
    #ldap.group.base.dn=

Parameter

Expected Value

ldap.host

The hostname for the LDAP server.

ldap.principal

The principal (username) used for authentication with the LDAP server.

ldap.credential

The credential (password) used for authentication with the LDAP server.

ldap.username.attribute

The LDAP attribute to be used for 1Integrate login names e.g. samAccountName

ldap.user.base.dn

The LDAP search root for users.

ldap.group.attribute

The group name attribute to be used from your LDAP server e.g. samAccountName

ldap.group.base.dn

The LDAP search root for groups.

Change default ldap settings

Depending on your particular LDAP implementation, you may need to change some of the default LDAP settings.

# Enable if you need to override any defaults
#ldap.protocol=ldap
#ldap.port=389
#ldap.referral.mode=IGNORE
#ldap.direct.verification=true
#ldap.recursive.search=true
#ldap.group.member.attribute=member
#ldap.authentication.level=simple

To do this:

  1. Find the settings.properties file, to locate this go to: [1Integrate_Directory]\SETTINGS\.

  2. Uncomment the sections that need changing for your active directory.

Parameter

Expected Value

ldap.protocol

The protocol the connection will use (ldap or ldaps).

ldap.port

The port number for your LDAP.

ldap.referral.mode

Set to FOLLOW if you have multiple LDAP servers that refer to eachother.

ldap.direct.verification

Set to FALSE if WildFly should query the users password out of the LDAP server for user credential verification.

     Note: For most installations direct verification will be sufficient.

ldap.recursive.search

Recursive search will search through nested groups. If this setting is unnecessary for your environment, setting to false may improve performance.

ldap.group.member.attribute

The attribute on the group object that contains the members of that group.

ldap.authentication.level

Set to none if you want to bind to the LDAP server anonymously.

     Note: For security we would recommend all connections are authenticated.

Mapping LDAP groups to 1Integrate roles

Once you have completed your LDAP configuration, any users assigned to LDAP groups named the same as 1Integrate Permissions (e.g.1int-repository) will be authenticated and authorised by your LDAP system.

Authorisation in Wildfly

It is possible to configure authentication so that usernames and passwords are managed by LDAP and the authorisation (permissions assigned to specific LDAP groups) is managed within the configuration files. This removes the need for the LDAP service to know anything about 1Integrate specific permissions.

     Note: In order to authorise in LDAP and authenticate in WildFly, the roles.properties file must be populated with the groups that match those from the LDAP directory with the associated permissions(s). e.g. LDAPGroup = 1int-repository.

     Note: You can only map LDAP Groups to roles if using this method.

Example of the roles.properties file which is mapping LDAP groups to the relevant roles:

ADMIN\ USERS=1int-admin
ENGINEERS=1int-user,1int-grid-write
WORKERS=1int-user