I2Rest Advanced Setup

This section describes configuration options of i2Rest Server. Basic configuration allows only demo server functionality, and must be extended to supply full functional server instancence. Combining examples bellow you can achieve server functionality that suits your requirements.

• SSL conections secure
• i2Rest Gate URL definition using unix socket
• How to require OAuth2 authentication (тут только *LOCAL сессии и минимальную настройку юзера, клиента и скоупа для run_program, pcml для echo)
• How to allow command call API (тут только *LOCAL сессии и минимальную настройку юзера, клиента и скоупа для run_command)
• How to allow calls to management API
• How to call API located on remote IBM i server
• Custom scopes Это на будущее, сейчас можно не описывать. Мы с тобой как-то обсуждали про то, что можно добавить собственный скоуп, использовать его в настройке полномочий и передавать его в сессию
• API configuration examples

Request authorization

Most of requests to i2Rest Sever require authorization. Such requests as IBM i command call, API call (except anonymous API call) and management api call will not be served without OAuth2 token with appropriate scope. There is a OAuth2 object, representing built-in authorization model. i2Rest built-in authorization model configuration options on example.

    "OAuth2":
  {
     "scopes": {"management_functions" : {"description":"i2Rest management APIs call"},
                "run_program"          : {"description":"Run *PGM and *SRVPGM"}, 
                "run_command"          : {"description":"Run CL command"}
  },
     "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 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. And these are exactly the settings of Oauth2 object that we need to perform a Мanagement api call.

Мanagement API call

So, what you have to do before we can test Мanagement API call to i2Rest Server:

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

b) Fill the OAuth2 object template above with IBM i users values. Then add the snippet to your basic server configuration(with or without ssl protection) and put your new *.json anywhere on IBM i IFS.

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

Now let's test the configuration obtaining Oauth2 token with SoapUI, 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 System defined. So that's how we will change your basic server configuration (with or without ssl protection) to perform authorized run_program API call:

a) Add the snippet bellow to the session systems object:

{
      "name": "*LOCAL",
      "submit": SBMJOB JOB(I2RESTS) USER(${user})
                   CMD(CALL I2REST PARM(
                      '-session'
                      '-url' '${surl}'
                      '-uid' '${uid}'
                      '-user' '${user}'
                      '-init' 'ADDLIBLE I2REST'))
                      '-dcm_client_id' 'MYCLIENT'))"
},

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

c) Fill the OAuth2 object template above with IBM i users values and add to your *.json.

d) Add the "run_program" scope to scopes object.

e) Change the pscms object as follows:

   "pcmls":
   [
      {
         "pcml_mount"         : "echo",
         "pcml_file"          : "<complete name of i2restecho.pcml on IFS (for example /tmp/PCML/i2restecho.pcml)>", 
         "valid_in_anonymous" : false
      }
   ]

f) Restart server to apply your new configuration *.json.

Now you can update your SoapUI ECHO test project with Authorization profile and perform your authorized API call.