Creating an Application

Software AG Products 10.7 | Using API Gateway | Applications | Creating an Application

Creating an Application

You must have the API Gateway's manage applications functional privilege assigned to perform this task.

You can create an application from the Applications page.

To create an application

1. Click Applications in the title navigation bar.

2. Click Create application.

3. Provide the following information in the Basic information section:

Field	Description
Name	Type a name for the application.
Version	Version of the application. By default it is 1.0 but can be modified to a required value.
Team	This field is visible when the enableTeamWork is set to true in the Administration > General > Extended Settings section. Team to which the application must be assigned to. You can select more than one team. To remove a team, click the icon next to the team.
Description	Type a description of the application.
Requestor comment	This field is visible when Approval configuration for Create application is enabled in the Administration > General > Approval Configuration > Create application section.

4. Click Continue to Identifiers >.

Alternatively, you can click Identifiers in the left navigation panel.

You can save the application by clicking Save at this stage and add the Identifiers and APIs at a later time.

5. Provide the following information in the Identifiers section:

Field	Description
IP address range	Provide the IP address range or range of trusted IPv4 or IPv6 addresses that identify requests from a particular application. You can add more range options by clicking +Add and adding the required information.
Partner identifier	Specifies the third-party partner's identity. The specified partner can access the APIs if business-to-business communication between trading partners is enabled and where partners can invoke the exposed APIs to exchange information. For example, if you have enabled business-to-business communication between trading partners using APIs, partners can invoke the exposed APIs to exchange information. These APIs are available by associating Trading Networks with API Gateway. A partner can access the APIs that appear in the Partner Profiles and associated Partner Groups page. Once APIs are added as part of Partner, respective application is created in API Gateway with name partnerName Application and appropriate Partner ID. For more details on information on enabling business-to-business communication between trading partners and required configuration, see webMethods Trading Networks Administrator’s Guide Note: No identification or enforcement of application happens in API Gateway using this identifier.
Client certificates	Click Browse and select the client certificate or certificate chain to be uploaded. The client certificate specifies the X.509 certificates that requests from a particular application. Note: API Gateway supports .cer and .pem certificates for identifying consumer applications. You can add multiple certificates by clicking +Add
Claims	Provide a set of claims for the JWT and OpenID clients. A claim is a unique identifying information that identify requests from a particular consumer application. The claim set is identified by a unique Name and is defined as a name-value pair that consists of a Claim name and a Claim value. You can add more claims and claims sets by clicking +Add and adding the required information.
Header key	Specify the HTTP header key to identify the requests from an application.
Header value	Specify the HTTP header value to identify the requests from an application. You can add multiple header key and value by clicking +Add
Other identifiers	Select one of the options to identify requests from a particular application and provide the required value: Hostname. The host name to identify requests from an application. Payload identifier. The payload identifier to identify requests from an application. Team. The team to identify requests from an application. A team can contain one or more groups or LDAP groups the application can be identified against a user belonging to any of these groups by the specified team. Token. The token to identify requests from an application. Username. The username credential to identify requests from an application. WS-Security username. The WSS username to identify requests from an application.

6. Click Continue to APIs >

Alternatively you can click APIs in the left navigation panel.

You can save the application by clicking Save at this stage and add the APIs at a later time.

7. Type a keyword to find the required API and click + to add the API.

Adding an API to the application enables the application to access the API. An API developer while invoking the API at runtime, has to provide the access token or identification token for API Gateway to identify the application.

8. Type the required Requestor comment.

9. Click Continue to Advanced >

Alternatively you can click Advanced in the left navigation panel.

You can save the application by clicking Save at this stage and add the APIs at a later time.

10. Specify the origin from which the responses originating are allowed during response processing for the application.

11. Click +Add to add the origin.

You can add multiple origins using

.

12. Click Continue to Authentication >

Alternatively you can click Authentication in the left navigation panel.

You can save the application by clicking Save at this stage and add the Authentication strategy at a later time.

13. Click Create strategy.

A strategy is a way to authenticate the incoming request and provides multiple authentication mechanisms or multiple authorization servers for a single authentication scheme. You can create multiple strategies authorized by an API for an application.

14. Select one of the Authentication schemes:

OAUTH2. Provide the following information:

Field	Description
Name	Provide the name for the strategy.
Description	Provide a description to describe the strategy.
Authentication server	Specify the authentication server. The available values are local, which is the default server or any other configured external authorization server.
Audience	Provide a value or URI, the intended recipient of the authorization server scope. The application that receives the token verifies that the audience value is correct and rejects any tokens intended for a different audience.
Generate Credentials	Enable the toggle button to generate the client dynamically in the authorization server and provide the following information: Type. Select one of the client types: Confidential. A confidential client is an application that is capable of keeping a client password confidential to the world. This client password is assigned to the client app by the authorization server. This password is used to identify the client to the authorization server, to avoid fraud. An example of a confidential client could be a web app, where no one but the administrator can get access to the server, and see the client password. Public. A public client is an application that is not capable of keeping a client password confidential. For instance, a mobile phone application or a desktop application that has the client password embedded inside it. Such an application could get cracked, and this could reveal the password. The same is true for a JavaScript application running in the users browser. The user could use a JavaScript debugger to look into the application, and see the client password. Application type. Specify the application type. WEB. A web application is an application running on a web server. In reality, a web application typically consists of both a browser part and a server part. The client password could be stored on the server. The password would thus be confidential. USER_AGENT. A user agent application is for instance a JavaScript application running in a browser. The browser is the user agent. A user agent application may be stored on a web server, but the application is only running in the user agent once downloaded. NATIVE. A native application is for instance a desktop application or a mobile phone application. Native applications are typically installed on the users computer or device (phone, tablet etc.). Thus, the client password will be stored on the users computer or device too. Token lifetime. Specify the token lifetime in seconds for which the token is active Token refresh limit. Specify the number of times you can use the refresh token to get a new access token. Redirect URIs. Specify the URIs that the authorization server can use to redirect the resource owner's browser during the grant process. You can add multiple URIs by clicking +Add. Grant type. Specify the grant type to be used to generate the credentials. Available options can be authorization_code, password, client_credentials, refresh_token, and implicit, which are dynamically populated from the authorization server. For example, if the authorization server does not support client credentials, the option is not available in the options list. Scopes. Select the scopes that are to mapped for the authentication strategy. Note: in API Gateway 10.2, the scopes are automatically created when you associate an API to an application. From API Gateway 10.3 onwards you have to select scopes from the authorization server that have to be associated with the strategy.
Client id	Specify the Client identifier for a client application available in the authorization server that identifies the client application in the authorization server to map the client to the API Gateway application. This is required if you have a client application available in the authorization server and do not want to dynamically create a client.

JWT. Provide the following information:

Field	Description
Name	Provide the name for the strategy.
Description	Provide a description to describe the strategy.
Authentication server	Specify the authentication server. The possible values are local, which is the default server or any other configured external authorization server.
Audience	Provide a value or URI, the intended recipient of the authorization server scope. The application that receives the token verifies that the audience value is correct and rejects any tokens intended for a different audience.
HMAC algorithm	Select if the authorization server is returning a JWT with HMAC algorithm and provide the shared secret value to validate the JWT.

OPENID. Provide the following information:

Field	Description
Name	Provide the name for the strategy.
Description	Provide a description to describe the strategy.
Authentication server	Specify the authentication server. The available values are local, which is the default server or any other configured external authorization server.
Audience	Provide a value or URI, the intended recipient of the authorization server scope. The application that receives the token verifies that the audience value is correct and rejects any tokens intended for a different audience.
Generate Credentials	Enable the toggle button to generate the credentials required to identify the client application and provide the following information: Type. Select the client type, Public or Confidential Confidential. A confidential client is an application that is capable of keeping a client password confidential to the world. This client password is assigned to the client app by the authorization server. This password is used to identify the client to the authorization server, to avoid fraud. An example of a confidential client could be a web app, where no one but the administrator can get access to the server, and see the client password. Public. A public client is an application that is not capable of keeping a client password confidential. For instance, a mobile phone application or a desktop application that has the client password embedded inside it. Such an application could get cracked, and this could reveal the password. The same is true for a JavaScript application running in the users browser. The user could use a JavaScript debugger to look into the application, and see the client password. Application type. Specify the application type. WEB. A web application is an application running on a web server. In reality, a web application typically consists of both a browser part and a server part. The client password could be stored on the server. The password would thus be confidential. USER_AGENT. A user agent application is for instance a JavaScript application running in a browser. The browser is the user agent. A user agent application may be stored on a web server, but the application is only running in the user agent once downloaded. NATIVE. A native application is for instance a desktop application or a mobile phone application. Native applications are typically installed on the users computer or device (phone, tablet etc.). Thus, the client password will be stored on the users computer or device too. Token lifetime. Specify the token lifetime in seconds for which the token is active Token refresh limit. Specify the time in seconds for which the token refresh is applicable Redirect URIs. Specify the URIs that the authorization server can use to redirect the resource owner's browser during the grant process. You can add multiple URIs by clicking +Add. Grant type. Specify the grant type to be used to generate the credentials. Available options are Authorization code, Implicit, Resource owner, Client credentials. Scopes. Select the scopes that are to be associated to the generated client. Note: In API Gateway 10.2, the scopes are automatically created when you associate an API to an application. From API Gateway 10.3 onwards you have to select scopes from the authorization server that have to be associated with the strategy.
Client id	Specify the Client identifier that identifies the client application in the authorization server to map the client to the API Gateway application. This is required if you do not choose to generate credentials to identify the client application.

15. Click Add.

The strategy is configured and listed in the Strategies table.

16. Click Save.

The application creation request is sent for approval. If you are one of the approvers, then the application creation request is automatically approved, the application is created, and listed in the Manage applications page.