Trust Platform Desk

Desk docs   API docs
Clients     more...

Create a client for each company in the tenanted installation.

Each client will have one or more Projects (a PDS, IdP, Hub, Attribute Provider, Authentication, Blockchain and/or Verifier) with the individual settings for that project.

                 
Projects     more...

Create a project for each type of web application (PDS, IdP, Hub, Attribute Provider, Authentication, Blockchain or Verifier).

For example, if you want a SAML idP create a project of type IdP.

(You may have multiple projects of the same type, each with their own settings.)

A note on UI

Some projects may host a separate UI and simply call API functions.

(e.g. a mobile app.)

However, it may be more appropriate to utilise API UI endpoints for certain applications, e.g. for login and registration to a SAML IdP project.

In this case you will need to modify (or create from scratch) suitable web pages which must then be located in the /user/{projectid}/web and webres folders for your installation.

For a list of API web endpoints and their functionality, please see the API documentation

                      

Project settings

  • Additional attributes

    Sources for attribute enrichment

  • Assets

  • Blockchain settings

    Do not edit or remove "subscription".

  • Database settings

    Do not change the projectid fields.
    Node names are case sensitive.
    Type must be unique.

  • Email settings

  • Email templates

        

  • External authorisation

    Authorisation settings for external services

    (Use this for the redirect or callback URL for OAuth 2 authorisation)

  • External services

  • General settings

    Optional: Absolute path to web resource folder for locally hosted project. Must be https.

      

    Determines the behaviour and security requirements of some API calls

    Not available for web apps

    Require anti-CSRF cookie for sign-in APIs. Uses Origin and Referrer headers otherwise

    Authentication methods that involve a callback will only be permitted for these URLs. Separate multiple URLs by a comma.

      

    Determines how JWT are signed

    First factor hmac keys
    When you generate a new key it will be added to the existing key list.
    The most recent key will be used when users change their passwords or next sign in

  • Geo decoder settings

        

  • Authentication

    Social providers 

    (Allow login with 3rd party social providers e.g. Google)

    more...

    For an IdP or PDS project this allows a user to login through 3rd party social provider. Add an entry for each provider you want the user to use.

    At each social provider's site, you will need to set up a project and obtain a client ID and secret, which are entered below.

    You will also need to supply a callback URL where the social provider will return the OAuth token to. Use the value displayed below.

    Common provider social provider developer portals:

    Google

    LinkedIn

    Paypal

    Amazon. Once logged in select app console

    Microsoft

    (Use this for the redirect URL when you setup your social provider app)

                     

    Must be checked to enable this provider.

    If a user successfully authenticates with this provider (but doesn't have a Project account) an attempt will be made to create an account, transparently to the user. (If an account cannot be created then the user will see a login fail, as usual.)

    SAML  more...

    For an IdP or PDS project this allows a user to login through 3rd party SAML IdP. Add an entry for each IdP you want the user to use.

    For a HUB project, you must add an entry for every IdP that is on the hub.

    Much of the following settings can be obtained from the IdP's metadata or on request from the IdP.

    Note

    Using a third-party IdP requires a two-way exchange of metadata:

    The Project needs to know about the IdP (endpoints, signing certificate, attributes, attribute format, etc; these are set below.)

    The IdP needs to know about the Project (endpoints, signing certificate, expected attributes, etc. Most of these are described in the Project SAML metadata.)

                     

    Project entity id, used as the Issuer field for SAML aurthentication requests.

    Must be checked to enable this IdP.

    If a user successfully authenticates with this IdP (but doesn't have a Project account) an attempt will be made to create an account, transparently to the user. (If an account cannot be created then the user will see a login fail, as usual.)
    None of the above applies to a hub project.

    The Issuer of the SAML response. Obtain this from the IdP.

    The URL of the IdP POST binding SSO endpoint. Obtain from the IdP

    The URL of the IdP Redirect binding SSO endpoint.

    The URL of the IdP POST binding SLO endpoint. Obtain from the IdP

    The IdP's signing certificate. Obtain from the IdP. (PEM format, starting with '-----BEGIN CERTIFICATE-----' and ending with '-----END CERTIFICATE-----')

    Attribute mapping (Map Trust Platform attributes to IdP attributes)

    This will set the attributes to be taken from the SAML assertion. You will get the attributes supplied by the IdP (and the names used) from the IdP's metadata.
    You may find that you can agree the attributes and naming system by agreement with the IdP, on supplying the project SAML metadata.

    Required authentication context class references and comparisons

    Special requirements will need to be agreed with the IdP.

    Separate multiple values with a comma.

    OATH

    (Allow Google authenticator as second factor)

  • OAuth / OpenID Connect

    (Use this for the OAuth2 user authentication endpoint)

    (Use this to retrieve the access token in Authorization Code grant flow)

               

    Name to be displayed to user.

    This is the callback url for the authentication step. Must be served over HTTPS

  • PDF templates

        

  • Regexes

        
    ...
    Name Regex

  • Registration settings

  • Rules

                     

    Must be checked to enable this rule.

  • SAML metadata  more...

    For an IdP or HUB project this sets the SAML metadata and settings for each relying party (RP, aka service provider).

    You must add an entry for every RP you want to allow to connect to your project IdP or hub.

    Click Show metadata to display

    Note

    Metadata is a two way exchange:

    1. This project needs the metadata for every RP that will be allowed to connect to it. This metadata will include endpoint URLs [e.g. where to send the assertion back to], RP signing certificate and possibly the encryption certificate, the attributes required by the RP and their format, etc;

    2. Each RP will need this project's metadata (endpoints, signing certificate, etc. These are in the Project SAML metadata.)

                               

    Under no circumstances should you change the projectid, type or name fields.
    Do not edit node names or your metadata may not function correctly.
    Node names are case sensitive.
    Note that certificates must not have line feed characters - these must be entered as "\n" text equivalent

    • projectid Do not edit
    • type Do not edit
    • entityid Issuer of the SAML response. (If you edit this, you must ensure the SP is aware of the new Issuer value.)
      You must save changes and refresh before displaying the new metadata from Show metadata
    • name Name of the SP
    • issuer Issuer field in SAML authentication request from SP
    • callback URL where the SAML response is to be returned
    • slo URL where the SAML logout response is to be returned
    • displayname Displayed to the user at sign-in to the IdP
    • encert SP certificate for encrypting attributes. Leave empty if not encrypting for this SP.
      (Note: Before pasting certificate data in here, newline characters (ASCII 10), must be replaced with "\n".)
    • encert SP certificate for checking signature of authentication request.
      (Note: Before pasting certificate data in here, newline characters (ASCII 10), must be replaced with "\n".)
    • requireauthnccr Set to 1 to require AuthnContextClassRef to be set to specific values by the SP; otherwise set to 0
    • allowedauthnccr Array of AuthnContextClassRef and corresponding assurance required levels.
    • sigalg Signing algorithm. Normally sha256
    • reqsig Normally set to 1 to require authentication request to be signed. Otherwise, set to 0
    • signresponse Normally set to 1 to sign response
    • encalg Only required if encrypting attributes. Supported value: "aes128-cbc"
    • encrattr Set to 1 to encrypt attributes. (Requires SP encryption cert.)
    • showconfirm Set to 1 to display a confirmation page before returning SAML assertion.
    • fields Comma delimited list of POST fields allowed in authentication request. Normally you must include RelayState. ()Case sensitive.)
    • assertions Number of assertion statements in SAML response. Normally 1.
    • sessiontime Session time in minutes. Normally 20. Required by some SPs.
    • attrnameformat Used to set "Attribute NameFormat" value in assertion.
    • nameformat Used to set "<saml:NameID Format" value for SAML subject. Must be one of the following:
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified  (most common)
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
      The value used is determined by agreement with the SP.
    • sessionnotonorafter Include session period in assertion. Required by some SPs.
    • extranamespaces Array of namespaces used in assertion XML. Normally must include:,br />"xsi": "http://www.w3.org/2001/XMLSchema-instance".
    • map Array of internal attribute names and the corresponding names to be used for the attributes in the assertion. Only attributes included here will be returned.
      Returned attributes can be made up of concatenated attributes by inserting a pipe character (|) between the name of each internal attribute to be added. For example, to return a "name" attribute consisting of a user's first and last names, use "givenname | surname".
      Use an asterisk (*) to specify parts of an address e.g. "address*postcode" will return the user's current postcode.
      For more elaborate assertion formats, set a JSON entry "custom" : "custom_rule_name" and write a rule with that name.

  • SMS settings

  • Strings

  • User verification settings

  • Wallet Pass templates

  • Web hooks

    Web hooks allow event notifications to be POSTed to third party services (e.g. Zapier, Slack, etc.,)

               

    Must be checked to enable this web hook.

  • Options for Web Interfaces

    These provide default options for web interface pages, some of which may be overridden by run-time parameters.

New client

New project

A Personal Data Store that permits a user to apply consented sharing to their data

Sign in

    

New sign in credentials

You must enter new sign-in credentials

Must have at least 8 characters, with upper and lowercase characters and numbers.

Your account

Send second factor by

Edit admin accounts

...
Name Email Mobile Action

My History

...
Date Event Info IP

API Usage History

...
Date Event Info User ID IP

Recover clients

...
Date removed Company Client ref Action

New Desk administrator or user

Select the client that this user will administer


No Access project settings

Checked items will be inaccessible

Desk setup

Desk System Administrator details

This is the person who will be the administrator of the Desk system. It may be you or someone else.

A text message will be sent with a sign-in password, as well as an email informing the system administrator of the new account.

All other data will be created for you.

Once you have created the system, the new System Administrator may sign in, update their credentials and tailor the system as required.

Idp (SAML) settings

You will require this information for service providers to connect with

        

Service Provider (SAML) settings

You will need to give this information to the SAML IdP

Only required if you require assertions to be encrypted

        

New Rule

Do not include spaces

        

New social provider

Do not include spaces

        

New web hook

e.g. zap new account

e.g. zapier. Do not include spaces.

        

        

New OAuth client

Project Export

Certificates and keys

Exporting with certificates and keys should not be selected if you are going to share the project with a third-party.

Check to remove any connection credentials (e.g. database connection credentials)or other secrets from the exported project.
Check this if you're going to share the export with a third-party.

Import Project

When importing a project, any existing keys and certificates will be maintained, unless a project with the same project ID already exists. In this case, see the choices below.

Handling a duplicate project ID

Select one of the following options for the case where the project you are importing has a project ID that matches an existing project

This is like creating a new project from the one being imported. Any keys in the imported project, including first factor keys used in securing users' first factors, will be cleared and replaced by a fresh set.
New signing and encryption certificates will also be created.
Select this only if you want to replace an existing project with the imported project
The imported project will maintain its existing keys and certificates.