i2Rest Advanced Setup

We assume that you have completed our basic guide, so let's proceed updating i2Rest Server configuration on the way to the full functional server instance.

SSL

The first thing we recommend to add to the basic server configuration is a https protocol connections protection. Please follow detailed guide.

Request authorization

Most of requests to i2Rest Sever require authorization. Such requests as IBM i command call, API call (except anonymous API call) and Мanagement api call without Oauth2 token with appropriate scope will not be served. Let's observe i2Rest built-in authorization model configuration options on example.

    "OAuth2":
  {
     "scopes": {"management_functions" : {"description":"Invoke i2Rest manager APIs"}},
     "users":
     {
        "USRX":{"description":"John Johnes","valid_clients":{"TSTCLNT":{"scopes":["management_functions"]}}}
     },
     "clients":
     {
        "TSTCLNT":{"redirect_uri":"<main gate URL>/oauth2/redirect", 
                   "description":"Test client", 
                   "valid_scopes":["management_functions"],
                   "valid_grant_types":["authorization_code"]}
     },
     "tokens": {"type":"token"},"codes":{"type":"code"}
  }   

The snippet above shows us Oauth2 object, representing built-in authorization model. In general worlds i2Rest authorization model is something like WHAT is allowed and to WHOM, and HOW it realized. WHAT parameters - are the "scopes", HOW parameters - "tokens", WHOM parameters - "users" and "clients" (built-in authorization model implies that both "users" and "clients" has to be registered as an IBM i users). So we can see that user USRX using client TSTCLNT is allowed to do some actions within "managment_functions" scope.

Мanagement api call

Look at the simple template bellow (its actually a basic config modified to perform a Мanagement api call) :

So, what you have to do before we can test authorized call to i2Rest Server instance:

a) Register two users on IBM i - one for a "сlient" parameter and one for a "user" parameter.

b) Fill the template above with IBM i users values and save template as *.json anywhere on IBM i IFS.

c) Restart sever to apply your new configuration *.json.

Now let's test the configuration obtaining Oauth2 token with Soap UI, and than proceed to Management api authorized call.

RUN_PROGRAM API call

Unlike anonimous API call we performed in our basic guide authorized API call requires Oauth2 token with "run_program" scope and local session defined. Look at our

---

This section describes the advanced configuration options of i2Rest Server. To configure, the file in the JSON format is used, the settings reference is here

i2Rest Gates

i2Rest Gate is the endpoint where the server listens for incoming requests. The server uses up to three endpoints to process requests from clients, administrators/managers and sessions. Configuration file can contain up to three gate objects to setup these endpoints. If the configuration does not contain a setting for some gate, then the default setting is used - file: protocol at temporary location.
Detailed description of all available configuration options for gates is here

i2Rest Gates protocols

http

This is a common protocol, without encryption. You can use this protocol in a fully secure network environment. Example:

"gates":
   {
      ...
      "main": {"url":"http://192.168.1.123:5678", ...},
      ...
   },

https

To protect the connections, use the https protocol. i2Rest Server uses standard IBM i GSK API to protect connections. All required parameters are configured using DCM, see detailed guide. Example:

"gates":
   {
      ...
      "main": {"url":"https://192.168.1.123:5678", "dcm_server_id":"MYSERVER", ...},
      ...
   },

file

When your i2Rest Server instance and its clients both located on the same IBM i server, it is reasonable to use file: protocol. For example, you can use this protocol for management gate, to perform management functions using local i2Rest Client. i2Rest Server is able to listen incoming requests at some unix socket defined as a file at IFS. In this case, the server will not be accessible externally. i2Rest Server uses temporary file: endpoints when it can't find configuration for some gate. Temporary file: endpoints are created at /tmp folder, for example /tmp/AS5WRD7DCJ. Example:

"gates":
   {
      ...
      "session": {"url":"file:///tmp/session_gate", ...},
      ...
   },

i2Rest Sessions

Ссылка или дублирование "что такое session system".
Ссылка на reference настройки
Упомянуть о сессиях на другой IBM i и на другой платформе
Привести примеры настройки сессий

• Обычные сессии (*LOCAL)

   {
      "name": "*LOCAL",
      "submit":"SBMJOB JOB(I2RESTS) USER(${user})    \
                   CMD(CALL I2REST/I2REST PARM(      \
                      '-session'                     \
                      '-url'  '${surl}'              \
                      '-uid'  '${uid}'               \
                      '-user' '${user}'              \
                      '-swap_to_user'                \
                      '-scopes' '${scopes}'          \
                      '-init' 'ADDLIBLE I2REST'      \
                      '-dcm_client_id' 'MYCLIENT'))"
   },
* Анонимные сессии (*ANONYMOUS)
* Варианты обычных сессий (system_XXX) - для задания особых параметров запуска, например логирования, запуск в выделенной подсистеме и прочее
* Запуск сессии на удаленной машине (SBMRMTJOB)

= Настройка API = 
* Используем PCML, дать ссылку на что такое PCML, какие особенности PCML в i2Rest
* Примеры PCML
* Примеры расширенных PCML, включая тег openapi30
= Настройка параметров доступа OAuth2 =
== Модели настройки доступа ==
Стандартная и custom модель, стандартная - бесплатная. Custom - позволяет настраивать собственные правила или справочники для пользователей, клиентов и токенов.
== Стандартная модель ==
=== users ===
=== clients ===
=== scopes ===
=== tokens ===
== Custom access model ==
User exits для реализации custom модели
== Standard UI pages ==
i2Rest Server comes with a default set of web-pages to be shown to user in the user-server dialog (for example in Server and Client OAuth2 flows). You can use the snippet bellow as a default settings, just copy and paste them to your configuration file. 
<pre>
      "login_page"            : "/pages/Login/index.html",
      "decision_page"         : "/pages/user_decide.html",
      "bad_auth_page"         : "/pages/bad_auth.html",
      "enter_code_page"       : "/pages/enter_code.html",
      "device_connected_page" : "/pages/device_connected.html"

Whenever you want to use pages with your own design - you are free to create them, place them on IFS and set up your config.

---