A trusted application record tells the system that a specific application is allowed to access the ERP Instance.
Trusted Application record can be created manually or through a marketplace activation. Anyway, it is good to understand the information stored in such a record.
Anatomy of a Trusted Application record
A Trusted Application record contains many fields. To better understand them, read below.
This is the multi-language name of the application. Used mostly for interactive display in UI clients. Not important for the functioning of the application.
This is the application identifier. It is passed as parameter by the applications, when they claim who they are in front of the ERP Instance.
The Application URI should be unique for the ERP Instance. Preferably, it should be globally unique, so that the application can be listed in a marketplace. Use short, concise identifier. This will appear in logs and other files. Avoid non-latin and special characters.
It is advised, that you incorporate this identifier as constant in your application and use the same URI for all "trusts" for your app.
It is best to base your app URIs on your web site and some extension. For example, mywebsite.com/myapp1 is a good URI.
Client Type specifies the confidentiality abilities of the your application.
Client types are:
Confidential client applications are able to keep secrets. Public apps are generally unable to hide a secret from an advanced intruder.
Server executed apps are usually confidential. They are executed in a trusted environment and, if properly secured, can keep a secret.
Application Secret Hash
This is a bit of a challenge. You have to use a tool to get the hash. Type this in the browser (replace "mysecret" with your secret):
Basic Authentication Allowed
If true, this application allows login with user name and password. When a client application uses basic authentication it must provide the application uri along with user name and password. Use with caution, because basic authentication is less secure than oauth! If a user is specified in System User, the basic authentication is allowed only for this user.
Impersonate As Community / Internal User Allowed
Allows the app to request login from a community (external) or internal user.
When both options are OFF, the app would not be allowed to request a user to be authenticated. This is a common scenario for service applications with no UI.
If any or both options are ON, the app is allowed to impersonate, e.g. request login. The login would be successful only if the authenticated user is of one of the allowed types.
- Service app - both options OFF.
- Internal interactive app - only Internal users allowed.
- Public web app - both Community and Internal users allowed.
Avoid allowing only Community and disallowing Internal users.
Usually, community accounts can be freely created by anybody. So, allowing only community accounts could create confusion for the internal users and force them to create a separate, external (community) account.
It is strongly not recommended for a user to have duplicate accounts, just for the purpose of having both community and internal accounts.
Impersonate Login URL
This is used only for applications, which use the Authorization Code Flow. It is called after a successful login and receives the generated code used to retrieve identity and access tokens.
Usually, this URL is a dedicated endpoint in the app environment.
The endpoint should conform to:
You can specify multiple valid URLs by comma-separating them (typically, to handle different environments like QA or testing).
Impersonate Logout URL
Specifies a comma separated list of allowed URIs to redirect to after logout.
Disables the access of the application.
The scope (according to RFC 6749) for which the application was trusted. The scope is an unordered list of space-delimited case-sensitive strings. Each string denotes a permission.
The following token scopes are used :
Allows the user application to update data in the ERP Instance. Without this scope, the application can only read data.
The following token scopes are PLANNED for near future developments:
Allows the application to access the security infrastructure of the ERP Instance. Generally, this scope should NEVER be trusted to user apps.
Scopes, reserved for future use:
This is the service user, which will be used to initiate sessions, when the application requests token with Client Credentials.
System User Allowed
Specifies whether the application is allowed to request service access.
System User Login URL