Theory of APIGEE:
There are 3 types of APIGEE products available in the market:
Apigee Edge
Apigee Sense
Apigee Monetization
Apigee Edge:
This is an API Management layer in which we have the below 3 sub sections:
a. API Services: To create, publish, and manage a portfolio of API proxies. As well as implementing a security access
b. Developer Services: This gives developers access to tools that help developers to discover, build and test applications.
c. Analytics Services: To monitor the health and performance of the application
Apigee Sense:
This is a behaviour detection and correction tool used to analyse the api calls made and see if there were any malicious attacks like content scraping etc. It would then alert the Administrator who can then use Apigee Sense to take corrective actions through tools provided by Apigee Sense.
Apigee Monetization:
This Platform which can be used for usage reporting capability as well as for Payment and handling bills etc.
So, overall, the way in which API Services work is like below:
API Service ->
Router -> Routes the request to the right MessageProcessor. So, 1 Router can have more than 1 message processor linked to it.
Now, Message processor, maps the request which would be handled by backend, applies policies on the incoming request message payload and waits for the backend service to complete the response.
Message processor is also responsible for validating the apikey and OAuth Tokens in its internal Cassandra database. It also uses openldap component to store the ldap of the logged in user.
Also, message processor asynchronously emits data to the qpid server of Analytics services which then passes on the analytics data to postgre sql server wherein the analytics information is aggregated (for showing up in API Metrics in the API Management portal)
Once the appropriate request for reports is made in analytics services, we get back the reports for analysing api performance, error checks etc.
Also, the management server is where the developers would be making the configurational changes for the different api proxies.
All, in all, there can be one or more api paths that can be configured per api proxy, one or more api proxies exposed per api product and one or more api products exposed per api app
So, EDGE platform consists of one or more organizations. Usually, we will have more than 1 org to manage access to different apis.
Each organization contains -> Developers, Application, API Team (which is responsible for creating proxies, api products, policies, keys, other items etc.) and it has many environments.
Each environment has a proxy defined in it and each proxy has a set of flows. (Like, PreFlow, ConditionalFlow, PostFlow, PostClientFlow and each flow has flow variables defined like request.path / request.url. We can provide conditions on the policy execution themselves using these flow variables or we can also provide conditions prior to execution of these flows as well. We can have our own custom flow variables and define conditions based off them.)
We also have Role Based Access control wherein we can create some custom roles specific to say new developers (/Restricted Developers), QA Testers , Business Users etc. who can access a portion of the API Management UI depending on their role. (-> Note: This role is only about ability to access the analytics section, ability to create api proxies, ability to create api products etc.)
So, lets walk through the methodology in which we create a sample API proxy, API product wrapping the API proxy, an App wrapping the API products, and finally the portal which would be the view point for the created App.
Click on Specs in Develop tab once you login to your apigee.com :
Either define the specs or import the specs from the swagger document available.
Example Swagger URL is:
Once the Spec is defined, click on API Proxies and Add an API proxy.
Now, click on Reverse Proxy for a simple setup or click on ‘USE OpenAPI Spec’ to create a specification based out of whatever specification was created using above step:
Select, the proxy name which we would want to use as the proxy url and select the base url of the target end point. In the below case, any request which hits http://eycompassgroupuserproxy/ would get redirected internally to https://eycompassapiphasetwo.azurewebsites.net/
Select the ‘Policy’ tab and check the apikey validation:
Select a couple of flows which should be available within the defined API Proxy
Define the virtual hosts where the proxy would be server from:
Click on Next and select, both prod and test environments to be able to create http and https api proxy urls for both the environments and deploy it in whatever environment you would want this api to be exposed in
Now, once the proxy is created like below, we can invoke : https://vamseemudradi-eval-prod.apigee.net/eycompassgroupuserproxy/api/common/ groups/permissions?apikey=XXXXXX and this would call underlying api:https://eycompassapiphasetwo.azurewebsites.net/api/common/group/permissions?apikey=XXXXXX
Now, the way to derive the apikey XXXXXX which needs to be sent in order to invoke the API can be got after we create the API Product based off this API proxy and API App based off the API product. The steps for achieving these are detailed below:
Create an API product:
(Here, I have given public access to the API proxy by selecting ‘Public’ against Access Level and empty OAuth scopes (as I am using apikey for the request to properly hit the underlying api from the api proxy))
Now, that I have created the API product : eycompassgroupuserapiproduct , next step is to create the App based off this API product. However, before that, we will see how to add a Company associated with the App (which we can use while defining the App):
In the Developer Programs tab, we add a Company called EYCompassForVIATeam by filling details like in image above.
In the Developers tab, we will create a Developer like below:
Next, we will select the Apps tab on the left pane like shown above, and click on “+App” on top right:
Note that, here, we aren’t able to associate the App with a complete Company like ‘EYCompassForVIATeam’ (which we created earlier) mostly due to this account being a free version.
Now that the app: eycompassgroupuserforviaapp is created, we should be able to get the api key to use in order to invoke the api successfully
The APIKey’s Value ‘ABCDEF’ (Actual value isn’t shown for security purposes is got for you by clicking on ‘Show’ link in above image. Save this value for later use) which we did not get in an earlier highlighted url is now derived and we can successfully invoke the API using POSTMAN / API proxy Trace tool itself like below: Go to API Proxies, select the proxy which you created earlier and then select the TRACE tab (on right side of the screen)
https://vamseemudradi-eval-prod.apigee.net/eycompassgroupuserproxy/api/common/groups/permissions?apikey=ABCDEF (Not ABCDEF actually but the Key got from the App’s show link can be invoked from TRACE or from POSTMAN like below)
As a next step, now realizing that the proxy is all working good, we would next create an APIGEE EDGE portal based off the app which we just created.
Once you have signed in to the APIGEE EDGE portal url shown above, you can then execute the APIs shown like below:
For our specific app, we require to register this particular Reply URL within our AAD as we have an app / tenant based constraint. This constraint can be validated by adding the REPLY url of this particular portal and clicking on Authorise and entering the ClientID required for OAuth validation (OAuth validation is internally required by our Swagger specification and not by the API proxy) once signed in.
So, overall, the security model which we have includes 2 steps:
1. OAuth2.0 authentication for the logged in user who should be registered as a valid user in the AAD settings of our App.
2. ApiKey authentication used on the API proxy so that this would take care of authentication at the proxy level even prior to hitting our publicly exposed App Url.
Happy life. Cheers 😊
コメント