Create a separate folder for images under WSO2

Author: chanakaudaya

vendor-specific/wso2/API-manager-3rd-party-KM-integration.md

@@ -10,7 +10,7 @@ If the requirement is just to share the same user base with the API platform, go
 ## Architecture
 WSO2 API Manager comes with a componentized architecture where each component can be deployed separately if required. Even within a single runtime, these components run with clear separation by communicating over well defined APIs. This API driven product design allows the product to be extended by using these interfaces. Using an external IdP as the key management component of the WSO2 API Manager is possible with this design. Let’s take a look at how this can be achieved.
 
-![WSO2 APIM 3rd party KM](WSO2APIM-3rdParty-Authorization-Server-Integration.png)
+![WSO2 APIM 3rd party KM](images/WSO2APIM-3rdParty-Authorization-Server-Integration.png)
 Figure 1: WSO2 API Manager 3rd party key manager integration
 
 The above figure depicts the standard integration of an external Identity Provider as the 3rd party key manager for WSO2 API Manager. There are 4 main components of API Manager is depicted here along with the users of those profiles.
@@ -47,7 +47,7 @@ In a typical workflow of API management, here is how this custom implementation
 Note: In the above figure, it has connected the same user store (LDAP/AD/JDBC) to both WSO2 API Manager and the IdP. This will make the integration flowless since additional user-level information can be extracted for the users with this approach. If we don’t use the same user store, we can’t support scope validation and backend JWT with user claims. But this is optional and based on the grant type and the backend implementation, you can decide on whether to share the user store or not.
 A sequence diagram view of the above mentioned workflow (starting from login into API Store) is depicted in the below figure.
 
-![APIM 3rd party KM integration workflow](API%20Store%20integrate%20with%203rd%20party%20KM.png)
+![APIM 3rd party KM integration workflow](images/API-Store-integrate-with-3rd-party-KM.png)
 Figure 2: Sequence diagram view of component interaction
 
 ## Reference implementation

vendor-specific/wso2/Cloud-Application-Security-Pattern.md

@@ -13,7 +13,7 @@ With the introduction of more and more cloud based applications, user management
 ## Architecture
 Using a centralized Identity Provider (IdP) is the solution to address the above challenges and come up with a user-friendly, scalable experience to identity admins as well as users. 
 
-![Cloud-Application-Security-Pattern](Cloud-Application-Security-Pattern.png)
+![Cloud-Application-Security-Pattern](images/Cloud-Application-Security-Pattern.png)
 
 As depicted in the above figure, cloud applications are configured within the WSO2 Identity Server (or any IdP) as service providers. Based on the authentication mechanism supported by the relevant application (e.g. SAML2, OIDC, WS-Federation), WSO2 IS can be configured. In the meantime, WSO2 IS needs to be configured as an Identity Provider within the relevant cloud application side. Once these settings are done, when a user tries to log into the respective cloud application, it will be redirected to the WSO2 IS authentication endpoint. Now users can provide the credentials which are stored within the enterprise user store (AD, LDAP, JDBC) which is connected with the WSO2 IS. 
 

vendor-specific/wso2/Microgateway-Pattern1-Decentralized-Gateway.md

@@ -5,7 +5,7 @@ With the adoption of microservices style of architecture within the enterprise,
 
 ### Architecture
 
-![Decentralized API Gateway](Microgateway-Pattern1-Decentralized-Gateway.png)
+![Decentralized API Gateway](images/Microgateway-Pattern1-Decentralized-Gateway.png)
 Figure 1: Decentralized API Gateway pattern
 
 As depicted in the above figure 1, In this deployment mode, api consumers can either use oauth2 tokens or jwt tokens. In the case of oauth2 tokens, microgateway will communicate with the key manager component. If there is a requirement to implement shared throttling across apis, microgateway will communicate with the external traffic manager. Analytics data will be published to the analytics runtime. In this deployment pattern, api publisher and store are deployed separately and will be exposed to api and application developers. These components will not have any interaction with microgateway components during the runtime. 

vendor-specific/wso2/Microgateway-Pattern2-Locked-Down-Gateway.md

@@ -5,7 +5,7 @@ Sometimes applications needs to be deployed in environment where there are no co
 
 ### Architecture
 
-![Locked-down API gateway pattern](Microgateway-Pattern2-Locked-Down-Gateway.png)
+![Locked-down API gateway pattern](images/Microgateway-Pattern2-Locked-Down-Gateway.png)
 Figure 1: Locked-down API Gateway pattern
 
 As depicted in the above figure 1, WSO2 API Microgateway has the ability to run in this type of environment with it’s built in security (JWT based), rate limiting (local) and offline-analytics capabilities. The applications and microservices will get the same set of capabilities from the API Microgateway, though there is no connection at all with the rest of the components of the API Manager. The Analytics data will be collected into files and will be uploaded to the analytics runtime when there is a connection established with that component.

vendor-specific/wso2/Microgateway-Pattern3-Seasonal-Gateway.md

@@ -5,7 +5,7 @@ If you have already deployed WSO2 API Manager (all-in-one) in a centralized mann
 
 ### Architecture
 
-![Seasonal API Gateway pattern](Microgateway-Pattern3-Seasonal-Gateway.png)
+![Seasonal API Gateway pattern](images/Microgateway-Pattern3-Seasonal-Gateway.png)
 Figure 1: Seasonal API Gateway pattern
 
 With the API Microgatway, you can quickly set up a seasonal gateway with a selected set of APIs and scale them up and down as necessary without impacting the existing deployment. 

vendor-specific/wso2/Microgateway-Pattern4-Multi-Data-Center-Gateway.md

@@ -5,7 +5,7 @@ Large enterprises which has global operations requires their applications to be
 
 ### Architecture
 
-![Multi data center API gateway pattern](Microgateway-Pattern4-Multi-Data-Center-Gateway.png)
+![Multi data center API gateway pattern](images/Microgateway-Pattern4-Multi-Data-Center-Gateway.png)
 Figure 1: Multi data center API gateway pattern
 
 As depicted in the above figure 4, the only component which shares data across data centers during the runtime is the analytics component which can connect to the other data centers in an offline manner. With the API microgateway, multi data center deployment has become much simpler and easier to implement and maintain. The above mentioned data centers can span across multiple cloud IaaS providers (Amazon, Google, Microsoft) as well.

vendor-specific/wso2/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.md

@@ -4,7 +4,7 @@
 If your enterprise is deeply integrated with microservices and wanted a fully fledged microservices implementation, service mesh is a pattern which you cannot ignore. Service mesh defines a network to communicate between microservices with a similar level of protection on top of them as external communications. Some might think this as an overkill but there are enough practical examples where people has implemented microservices with service meshes for better security, visibility and management of the overall microservices implementation. WSO2 API Microgateway can be used as a sidecar proxy in a service mesh kind of microservices architecture. It provides capabilities like authentication, rate limiting, circuit breaker, timeouts as well as monitoring. 
 
 ### Architecture
-![Service Mesh sidecar API gateway pattern](Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png)
+![Service Mesh sidecar API gateway pattern](images/Microgateway-Pattern5-Service-Mesh-Sidecar-Gateway.png)
 Figure 1: Service Mesh sidecar API gateway pattern
 
 In this deployment pattern, each microservice has an API Microgateway running alongside it in the same localhost. In kubernetes, both microservice and the API microgateway runs in the same pod (can be in different containers). All the communications across microservices will go through API microgateway for ingress and egress traffic. WSO2 API Manager analytics component can be used to analyze the interactions happening through the sidecar gateway.

vendor-specific/wso2/Microgateway-Pattern6-Hybrid-API-Gateway.md

@@ -4,7 +4,7 @@
 In all the deployment patterns mentioned above, the management aspect of the deployment needs to be handled by the enterprise. It gives them the utmost flexibility and control over the platform. But sometimes, organizations with limited IT staff and skill set wants to outsource some of the management and hosting capabilties of the platform while keeping the important components. This is what exactly the hybrid API gateway pattern provides. 
 
 ### Architecture
-![Hybrid API Gateway pattern](Microgateway-Pattern6-Hybrid-API-Gateway.png)
+![Hybrid API Gateway pattern](images/Microgateway-Pattern6-Hybrid-API-Gateway.png)
 Figure 1: Hybrid API gateway pattern
 
 In this deployment pattern, the critical runtime component of the API platform which is the gateway will be running under the control of the enterprise. It can be run on a private data center, public IaaS cloud or both. In the meantime, the management components of API publisher, Developer Portal, Analytics and Key manager will be hosted and maintained by WSO2 within their public API Cloud. 

vendor-specific/wso2/Security-Federation-Pattern.md

@@ -13,7 +13,7 @@ Out of the above 2 options, we are discussing the second option in this pattern.
 ## Architecture
 A typical enterprise software system consists of different types of applications like web, mobile and cloud based. Providing security to all these heterogenous systems requires a well designed Identity solution which is capable of understanding the protocols which are implemented by these systems. To enable federated authentication to these applications, this identity solution should understand the protocols supported by the outbound side as well. Here is the solutions architecture diagram of federated security pattern.
 
-![Security Federation Pattern](Security-Federation-Pattern.png)
+![Security Federation Pattern](images/Security-Federation-Pattern.png)
 
 As depicted in the above figure, the applications on the far left corner are configured to identify WSO2 Identity Server as the Identity Provider (IdP). Then WSO2 IS is configured to consider these applications as service providers so that when a user tries to access any of these applications, user will be redirected towards WSO2 IS for authentication purpose. At the WSO2 IS side, 3rd party IdPs are configured as Federated Identity Providers (IdP). If this 3rd party system is a legacy application or an application which is not supported OOTB or through the connector store, users can write a custom outbound authenticator.