Difference between revisions of "I2Rest Advanced Setup"
Pavel.lobko (talk | contribs) (→Мanagement API call) |
Pavel.lobko (talk | contribs) (→Request authorization) |
||
Line 9: | Line 9: | ||
"OAuth2": | "OAuth2": | ||
{ | { | ||
− | "scopes": {"management_functions" : {"description":" | + | "scopes": {"management_functions" : {"description":"i2Rest management APIs call"}}, |
"users": | "users": | ||
{ | { |
Revision as of 15:41, 26 June 2020
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 ssl 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":"i2Rest management APIs call"}}, "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. 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.