Setting up the Design Environment

With Financial Services Workbench 2.0, the Solution Designer gives the flexibility to connect to one or many Git providers. Using these Git providers, one has the possibility to decide with every solution, where the modeled data and the implemented code should be stored. The permissions that are defined at the Git provider will be automatically applied to the Solution Designer and therefore full control over the available capabilities for the users is guaranteed.

About Git Providers

Admin users can manage the available Git providers in the Admin Settings area. Before creating a solution, the Git provider has to be defined there. Each Git provider is identified by a unique alias.

The supported Git provider types are:

GitLab (self managed)
Bitbucket Server
GitHub (Enterprise)

Use Git Providers

To use a Git provider, every user has to define an access token for the Git. All supported Git providers provide the possibility to create these personalized access tokens. Each user can only specify one token per provider. This token will be from then on used for every interaction with the remote Git and also to restrict the capabilities of the user to the permissions that are set in the remote Git repository.

Use Multiple Git providers

If solutions should be stored at different places, an admin user can define multiple Git endpoints. While creating a solution, the creator could define, where the solution should be stored. Also, a specific group could be specified while creation. These groups are usually used to restrict permissions on certain solutions for dedicated users.

Manage Git Providers

In order to create and manage Git providers you must have admin privileges. To access the Admin Settings page use the Settings capability on the top right of the page. There you will get an overview of the already existing Git providers and their master data.

Create Git provider

To create a new Git provider use the Create capability.

The master data of a Git provider consists of:


Property	Description
Alias	Used to specify a Git provider under the given alias name. This field is mandatory.
Type	This is the Git provider platform. There are three options: GitHub Enterprise, GitLab and Bitbucket Server. This field is mandatory.
Base URL	The URL to the Git provider. This value must be unique. This field is mandatory.
Label	This is a short description of the Git provider. This field is optional.

Delete Git provider

To delete a Git provider use the header or inline Delete capability. After confirming the action, the Git provider and all tokens related to it will be permanently deleted.

Attention: You are not allowed to delete a Git provider if there are still solutions in the Solution Designer associated to the specific provider.

Necessary Git Token Permissions

The available capabilities in the Solution Designer depend on the permissions that are assigned to the user in the remote Git.

Grant general permissions for users on repositories

Repository or group administrators on the remote Git are responsible to grant access permissions on the repositories for the actual users.

GitLab

To create new solutions: at least developer permissions on the group must be granted.
To edit the solution content: at least developer permission (on the group or the repository) must be granted.
To view the solution: at least guest or reporter permission (on the group or the repository) must be granted.
To delete a solution: at least owner permission on the group must be granted.
Attention: The above described permissions are valid for a GitLab EE default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

Bitbucket Server

To create new solutions: administrator permission on project must be granted.
To edit the solution content: at least write permission (on the project or the repository) must be granted.
To view the solution: at least read permission (on the project or the repository) must be granted.
To delete a solution: administrator permission on project or repository must be granted.
Attention: The above described permissions are valid for a Bitbucket default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

GitHub Enterprise

To create new solutions: The authenticated user must be at least a member of the GitHub organization.
To edit the solution content: at least write permission in the GitHub organization must be granted.
To view the solution: at least read permission in the GitHub organization must be granted.
To delete a solution: admin access on the organization must be granted.

Attention: The above described permissions are valid for a GitHub Enterprise default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

Define specific permissions on tokens while generation

Usually, one could explicitly define the basic permissions for the token while creating the token in the remote Git provider.

Minimum permissions that need to be granted for the token:

GitLab

Select scope `api`
Select scope `read_repository`
Select scope `write_repository` (for GitLab version 11.11 or higher)

Bitbucket Server

Select permission “Read” for basic read access
Select permission “Write” to allow create, delete and edit capabilities, as well as committing to the repository
Select permission “Administrator” to allow create, import and delete solutions

GitHub Enterprise

Select permission "public_repo" to access public repositories.
Select permission "write_org" to read and write organization and team membership, read and write organization projects.
Select permission “repo_status” to access commit status in a repository.
Select "delete_repo" to be able to delete organization repositories.
Select "admin_org" to get full access of organization and teams, read and write organization projects.

Manage Git Tokens

To access the User Settings use the Settings capability on the top right of the page and navigate to the User Settings page.

Create a Git token

Each user can have only one token for each Git provider for which he has rights. To create a new token use the header capability Create in the Git tokens tab on the User Settings page.

A Git token is defined using the following master data:


Property	Description
Token name	Name of the token. It is unique for each user. This field is mandatory.
Git provider	It is a list of all the Git providers to which the current user has rights. The Git providers are represented with their assigned alias that was provided by the admin user. This field is mandatory.
Git access token	This is the actual Git token. This field is mandatory.
Git username	This is the user name as defined in the Git provider. This field is mandatory.

Note: By using the default Verify and Create the provided Git username and Git access token will be validated before the creation. In case of incorrect data you will get an error notification. If you want to use that data anyway please choose the Create button.

Verify a Git token

To verify a Git token use the inline or header Verify capability. You will get either a "Success" or an "Error" notification displayed.

Delete a Git token

To delete a Git token use the inline or header Delete capability. After you confirm the action the Git token will be permanently deleted.

Update a Git token

In order to update a Git token use the inline or header Edit capability. This action only allows a change of the access token itself. If your username has changed delete the previous Git token and create a new Git token for the same Git Provider. After saving the changes, all Pipeline configurations using your personal credentials will also be updated.