Thursday, May 25, 2017

#575 Interesting Cloud Security Whitepapers

The first one concerns itself with Oracle Cloud Security.











Uncertainty over security is often cited as the major  factor working against cloud adoption.
This whitepaper allays any such fears.


Click here to read.


The second whitepaper also deals with security, albeit in the context of ICS.
It is from the A-Team










Click here to read.


Monday, May 22, 2017

#574 Deploying the Oracle API Platform Developer Portal to an on-premise app server

Nice feature, I just read about today.















The on-prem portal then connects to the Cloud based API Platform
Management Service via its REST interface.

The portal app is contained within the gateway download.













Check out the full doc here


#573 Oracle API Platform CS --> Groovy Scripting in the Logging Policy

According to the official docs -

You can use Groovy notation to access dynamic contents like headers, query
parameters, payloads and some context properties in specific policies.

These policies include:
• Method Mapping
• Service Callout
• Logging
• Redaction
• Groovy Script

So now to a simple example -















The REST request is as follows -



















Let's log the client value



















and write it to the following logfile -


This file will be created in the /customlogs directory in the following
path -

.../domains/gatewayNodeName/apics/

My gateway node is called gateway1.



Btw. The 4 variables for addressing values are -

- headers
- payload
- queries
- msgProperties

Ok, let''s test it out -

















I re-deploy the api to the gateway.

I test via Postman - the same test as shown previously.

I go to my Gateway and look in the /customlogs directory -







and there it is.

I check out the contents -








So what's the issue here?

Yes, that's it - I should be referencing it via the queries variable.

I do the necessary and re-test.







A more in-depth article on Groovy scripting in APIP CS is available here
It is from the Oracle A-Team.


Monday, May 15, 2017

#572 API Platform CS - documenting APIs & Apiary connectivity

Good and accessible documentation is key to ensuring the optimal use of your APIs.
Our new API Platform provides comprehensive support in this respect.

Here is an example, based on the service created in a previous post.
















Let's add some salient documentation to the service definition.

















I republish to the Developer Portal -











and then login to the portal as my developer user, jimmy.













I return to the Management console and add some documentation -














Back in the Developer Portal, jimmy can click on the documentation icon


to view what I just created.















Apiary Connectivity -


Imagine I had adopted an API design first approach to my NiallCStockQuoteService.
I begin by speccing out the API in Apiary -









































































Now let's go back to the Management Console and make a connection to Apiary
for this service.


















I click on the Apiary button.







































Once connected, I then select my Apiary project -












and then click Connect -











































#571 API Platform CS roles and grants

API Platform CS Roles



Here are the roles  -
























You can check out the ORCL docs pertaining to roles here

Administrator - the superuser, includes all other roles.
Manages platform settings.
I login to the API platform Mgt console
as my admin user - cathal - and see the following options -











Let's look at the platform settings -













API Manager - manages API lifecycle and who gets access to
the APIs. She can also monitor API performance.
I login to the API platform Mgt console
as my manager user - unclePaudge - and see the following options -












Application Developer - discover and register their interest in
using APIs. She interfaces with the API Platform Developer Portal.
I login to the API platform Developer Portal
as my appDev user - jimmy - and see the following options -










Gateway Manager - Install and manage gateways.
May also manage API deployments to her gateway.
I login to the API platformMgt Console
as my gateway mgr user - pat - and see the following options -
























According to the above, looks like pat doesn't have any gateways to manage.
However, I do have one created, so I can login as the user who created that and give pat access.

All I need to do is click on Add Grantee.





















Gateway Runtime a service account used to communicate from the gateway to the mgt portal.




API Platform Management Console Grants 

Deployments -

Here is a simple example of roles and grants.

I create a new API - NiallCStockQuoteService based on google finance service.
I do this as the API Mgr user - unclePaudge.





















So, OOTB, the API Mgr user does not have access to the Gateway.

I could login as the Gateway manager and give permissions to unclePaudge, or else
just deploy.

So now I log in as the gateway Mgr, pat.

He does not see the API -















So, what do I need to do now?
The API Mgr needs to grant pat access to the API.















He could grant the global - Manage API permission or the fine grained
Deploy API permission.


Let's go for the latter -



























I now log back in as the gateway manager - pat.
Now he can select the API and deploy it.

































Other API related Grants













Note the Register and Request Registration grants.
The former allows developers to register and use the APIs published to Developer Portal,
whereas the latter, requires final approval from the API Manager.

To demo this, let's deploy the API to the Developer Portal -










I now login to the Developer Portal as jimmy.










I do not see any APIs OOTB.

I now return to the Management Console and grant the following role to jimmy.
















Back in the Developer Portal - jimmy now sees the API.













but he cannot register to use it.

Let's also grant him - Request Registration.


















Back in the Developer Portal and jimmy now sees the Register button.












jimmy registers his interest in the API.



































Back in the API Platform Management Console, unclePaudge can now approve
jimmy's request.






















unclePaudge can approve, and quelle surprise, it is now registered -















enjoy!