You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Intro

TDS has multiple ways of users authentication, authorisation and provisioning. Possibilities depend combination on customer requirements and TDS capabilities.

Types of supported environments

From network point of view

  • public cloud
    • common TDS
    • dedicated TDS
  • private cloud
    • dedicated TDS

From AD/ADFS authentication integration point of view

  • AD/ADFS disabled
    • everyone has TDS account and is authenticated only using TDS ldap credentials
  • AD/ADFS enabled
    • everyone has TDS account and can be authenticated using TDS ldap credentials
    • everyone has TDS account and can be authenticated using company AD/ADFS credentials

From users origin point of view

Two users categories are distinguished:

  • AD users - users with AD account (usually employees, but very often also subcontractors)
    • can use AD or/and ADFS if enabled
    • can use TDS ldap credentials
  • non AD users - users without AD account (usually subcontractors)
    • cannot use AD nor ADFS
    • must use TDS ldap credentials

From users origin combination point of view

When both AD users and non AD users are present in TDS, we are talking about hybrid environment:

  • standard TDS
    • either AD/ADFS is enabled AND all users are AD users
    • or AD/ADFS is disabled (TDS does not care whether users have or do not have AD accounts as there is no integration)
  • hybrid TDS
    • AD/ADFS is enabled AND some non AD users are present

Provisioning capabilities

General provisioning capabilities

  • invitations
    • colleagues or leaders can send invitations to people not present in platform, invited users must validate their email address, then they can enter their credentials or their credentials are read from AD if present
  • sign-up
    • users can create accounts by themselves - first they must validate their email address, then they can enter their credentials or their credentials are read from AD if present
    • recommended for
      • for platform with AD users only without any externals (currently or in future)
      • for platform without AD connection
    • it is NOT recommended
      • in hybrid environments when AD users and NON AD users should be working in platform as users without AD account can create usernames as they wish and that can lead to conflict with current or potential future AD users leading to security issue
  • CSV import
    • currently requests must be raised via standard support channels as this functionality is available for TDS support ONLY (we are working on possibility to provide this to customer area admins and owners)
    • recommended for
      • hybrid environments when AD users and NON AD users should be working in platform - it gives customer key users (customer area admins/owners) full control over users that are joining platform

Provisioning capabilities flow diagrams

Invitations and sign-up flow

TODO

CSV import flow

TODO

Provisioning capabilities suitable for various types of environments

  • public cloud
    • common TDS - all provisioning options are available - invitations + signup + CSV import. This is thanks to the fact that there is no ADFS nor AD integration. That means freedom in usernames, thus no security related limitations are present (to avoid usernames collision and similar)

      • (tick) invitations
      • (tick) sign-up
      • (tick) CSV import
    • dedicated TDS
      • ADFS disabled - all provisioning options are available - invitations + signup + CSV import. This is thanks to the fact that there is no ADFS nor AD integration. That means freedom in usernames, thus no security related limitations are present (to avoid usernames collision and similar)
        • (tick) invitations
        • (tick) sign-up
        • (tick) CSV import
      • ADFS enabled - only CSV import is available due to security related limitations to avoid usernames collision and similar. It does not matter whether users have or do not have AD account, in public cloud we would not be able to control users that are invited or signed-up, thus we would not be able to prevent security issues caused by potential users accounts collisions
        • (error) invitations
        • (error) sign-up
        • (tick) CSV import
  • private cloud
    • dedicated TDS
      • both AD + ADFS disabled - all provisioning options are available - invitations + signup + CSV import. This is thanks to the fact that there is no ADFS nor AD integration. That means freedom in usernames, thus no security related limitations are present (to avoid usernames collision and similar)
        • (tick) invitations
        • (tick) sign-up
        • (tick) CSV import
      • AD enabled (ADFS does not matter) AND only AD users are present - all provisioning options are available - invitations + signup + CSV import. This is thanks to the fact that there is AD integration which TDS invitations or signup functionality uses to read username+email+FirstName+LastName (NOT password!)
        • (tick) invitations
        • (tick) sign-up
        • (tick) CSV import
      • AD enabled (ADFS does not matter) AND some non AD users are present - only CSV import is available due to security related limitations to avoid usernames collision and similar
        • (error) invitations
        • (error) sign-up
        • (tick) CSV import

Authentication capabilities

  • public cloud
    • common TDS
      • (tick) TDS
      • (error) ADFS
      • (error) AD
    • dedicated TDS
      • (tick) TDS
      • (tick) ADFS
      • (error) AD
  • private cloud
    • dedicated TDS
      • (tick) TDS
      • (tick) ADFS
      • (tick) AD

Authorisation capabilities

These depend on agreed service delivery mode and on capability of application to provide non system administrator permissions.

  • TDS integrated services
  • TDS standalone services (only Bitbucket, Confluence or Jira)
    • TDS provides infrastructure
    • TDS maintains application
    • No TDS integration in application
    • Customer key users maintain application (when non system administrator permissions are available)
    • TDS provides assistance with integrations to AD/ADFS or other platforms, so for example AD groups and users sync is possible as there is no interference with TDS
  • No labels