I get quite a lot of questions about the user roles available in ICS. Some of the questions relate to user access to data. For example, how do I prevent developers seeing payload values, such as credit card number.
The starting place for eliciting such information should be the ORCL docs - here I read
Here are those roles in the cloud admin console -
That's a lot more roles than detailed in the doc.
Suffice to say, many of these are cloud admin roles -
Identity Domain Administrator allows me to manage users etc.
Let's just concentrate on the following -
I will grant the user role to Uncle Paudge -
I will grant the monitor role to Pat Mooney -
I will grant the runtime role to Snowy Moran
Now let's log in as the various users -
He has access to all the top level components.
This is the optimal role for developers -
As the doc states -
Enables you to access all parts of Oracle Integration Cloud
Service to perform the following tasks:
• Create, deploy, and monitor integrations.
• Upload security certificates.
Now to the question, what if I do not want developers to see confidential info contained
in the payloads passing thru ICS?
At one level, the developer can do everything, well almost. She can log payloads, when activating integrations -
But as you can read above, this is not recommended in a production environment.
Also worth noting, the developer with the user role can manage all of the settings -
Best solution in this case, is to have a separate production environment. The developers can
do their stuff in the Development environment. Deploying to Production can be restricted. You could also use the REPL based Admin tool for ICS. This tool was developed by the Oracle A-Team and is detailed in a previous post.
I now log in as Pat Mooney the monitor -
at first glance, it looks as if Pat has access to all components, but
let's click on integrations -
I click on Dashboard -
However, the monitor role does allow access to the settings -
This is something you will have to keep in mind.
Let's now look at the runtime role -
But let's go to Postman and try the ICS REST API
First attempt, without any authorisation - I get Authorisation Required.
I add Snowy's credentials -
As you can see, our mobile developer cannot just execute any ICS REST API.
The API I selected was on that lists all integrations on ICS.
He can only execute an ICS integration, with this role.
Here is one I prepared earlier -
The URL is as follows -
https://myICSEnv/integration/flowapi/rest/NC_CREATEORG_REST/v01/createNewOrg?orgName=NiallCOrg
I execute this in Postman, using Snowy's credentials -
The starting place for eliciting such information should be the ORCL docs - here I read
Here are those roles in the cloud admin console -
That's a lot more roles than detailed in the doc.
Suffice to say, many of these are cloud admin roles -
Identity Domain Administrator allows me to manage users etc.
Let's just concentrate on the following -
- user
- monitor
- runtime
I will grant the user role to Uncle Paudge -
I will grant the monitor role to Pat Mooney -
I will grant the runtime role to Snowy Moran
Now let's log in as the various users -
Uncle Paudge (Developer / user role) -
He has access to all the top level components.
This is the optimal role for developers -
As the doc states -
Enables you to access all parts of Oracle Integration Cloud
Service to perform the following tasks:
• Create, deploy, and monitor integrations.
• Upload security certificates.
Now to the question, what if I do not want developers to see confidential info contained
in the payloads passing thru ICS?
At one level, the developer can do everything, well almost. She can log payloads, when activating integrations -
But as you can read above, this is not recommended in a production environment.
Also worth noting, the developer with the user role can manage all of the settings -
Best solution in this case, is to have a separate production environment. The developers can
do their stuff in the Development environment. Deploying to Production can be restricted. You could also use the REPL based Admin tool for ICS. This tool was developed by the Oracle A-Team and is detailed in a previous post.
I now log in as Pat Mooney the monitor -
Pat Mooney (Integration Monitor / monitor role)
at first glance, it looks as if Pat has access to all components, but
let's click on integrations -
I click on Dashboard -
However, the monitor role does allow access to the settings -
This is something you will have to keep in mind.
Let's now look at the runtime role -
Snowy Moran (mobile developer / runtime role)
Snowy develops mobile apps and needs to call ICS to access backend services.
He sees all the icons when he logs in, but cannot access anything.
But let's go to Postman and try the ICS REST API
First attempt, without any authorisation - I get Authorisation Required.
I add Snowy's credentials -
As you can see, our mobile developer cannot just execute any ICS REST API.
The API I selected was on that lists all integrations on ICS.
He can only execute an ICS integration, with this role.
Here is one I prepared earlier -
The URL is as follows -
https://myICSEnv/integration/flowapi/rest/NC_CREATEORG_REST/v01/createNewOrg?orgName=NiallCOrg
I execute this in Postman, using Snowy's credentials -
No comments:
Post a Comment