We are planning to implement CDC in our project and Pact is being considered as primary candidate. Currently I am working on a POC to set up end to end flow with CI/CD integration with GitLab. I have couple of questions related to Authentication/Authorization/security.
Consumer - Pact Broker: Consumers here are external partners. I see client side certificates as an option. I am not able to find much documentation or info on Web for the options available. Pact broker will be hosted in AWS. Can we place this behind a gateway?
Pact Broker and Provider: Both components are part of our infrastructure. In this case I understand that we will be generating a GitLab trigger token which will be passed as part of future requests to Provider pipeline. We will be using same token every time.
Could you please advise options available in both cases to make the communication more secure.
Thanks in advance.
We are planning to implement CDC in our project and Pact is being considered as primary candidate.
Good choice! :)
I have couple of questions related to Authentication/Authorization/security
The OSS broker doesn’t have any security controls other than basic auth and read-only/read-write access permissions (which isn’t very appropriate for external use for obvious reasons). There is basic support for redacting credentials in the UI, but you can still get them through API calls (even for read-only accounts).
Consumer - Pact Broker: Consumers here are external partners. I see client side certificates as an option. I am not able to find much documentation or info on Web for the options available. Pact broker will be hosted in AWS. Can we place this behind a gateway?
Where did you see that client certificates were supported? I’m sorry to say that is incorrect.
You can definitely put it behind a gateway/reverse proxy type thing: https://docs.pact.io/pact_broker/configuration/#running-the-broker-behind-a-reverse-proxy
You would need to add your own authentication layer for this purpose, so using a an API gateway for this that might be a good starting point.
Pact Broker and Provider: Both components are part of our infrastructure. In this case I understand that we will be generating a GitLab trigger token which will be passed as part of future requests to Provider pipeline. We will be using same token every time.
The provider side authentication is the same as consumer.
Alternatively, we have created Pactflow, which is a commercial version of the OSS Broker designed for enterprise use which has a full security model wrapped over the OSS broker including API tokens, and secrets, teams management and other useful features (see https://pactflow.io/features/ for more). We are also almost ready release CI users and fine-grained permissions management.
Related
I’m trying to pick up API gateway.
What are the different use cases for alb vs API gateway? I’ll be honest to say that I am not completely familiar with the concept of an API. I know we can invoke it backend, and the analogy that it’s a restaurant menu. However, beyond that, I am not clear what the difference is. Is it that applications using ALB has a user interface, but not API gateway? I tried reading through documentation on the features, but got even more lost. As such, I am hoping someone can share the use cases for both services so that I can visualise what it’s used for and the reason for the features. Thanks!
API GW is focused on API and has some additional options - e.g. API definition via swagger, execution of a lambda function, converting the call to an event bridge event, support of authenticators (iam, cognito), multiple deployment stages etc.
The load balancer listens on a port and that's about it.
Q: In what cases would you require these API GW features as opposed to just using an ALB?
A: One obvious benefit is a serverless or "low code". Let's say you want an API which processes asynchronous requests.
It is possible to create an API endpoint which queues all incoming requests to a SQS queue with just one AWS CLI command with no programming (provided the resources do exist):
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services.html
Each API endpoint can be served by a different AWS resource including EC2/ALB.
ALB is well suited for things like traditional monolithic applications (LAMP, Java application servers etc.)
I have been doing some research about using some AWS service as OAUTH2 for our application running in 3 docker containers (backend, frontend, database). Backend has an API which is not open to public obviously and accessible only within docker network. We are looking for extending our app with a chat service, which we want to implement as a service, so we build our app following microservices architecture, since we will add other services later on. So when user logs into our app, his session will be also "shared" with chat service.
Our chat service will be using sockets and since sockets require direct connection to user resources, we can not just implement an integration layer which will supply all resources required by chat service, but we have to either:
implement sockets within our application API (which we dont want to do, we want it as microservice),
open API endpoints for chat service to use, but this option requires OAUTH2 and thats what we try to deal with.
I am not sure if there is some other way to handle this and be also ready for a long run, but if this works, which AWS service would fit the best for us to use, which would play OAUTH2 role for handling security in this matter?
I also checked this post but it didn't help me much in my case. I'm open to any suggestions, I've checked AWS lambda, AWS cognito, AWS amplify, pretty confusing, many features, we don't want to overload the architecture with features we don't need.
What exactly is the thing you want? User accounts managed by AWS? Use cognito.
Users logging in with Apple, Facebook, Etc? Use cognito again.
Just have some backend code that once a user logs in, create a token or session so they can chat with that.
There are many youtube videos on AWS cognito but a lot of them suck. The best one is written in React but before they came out with hooks. Here is part one. https://www.youtube.com/watch?v=EaDMG4amEfk
I am working on a project wherein a mobile app (Flutter app) should create a unique identity (IOT thing) of my IOT device machine (on AWS) as soon as the user logins onto the app and also it should establish a connection (and subsequent communications) with the isolated IOT device after its configuration (Somewhat similar to Google Home configuration process).
The process starts with user logging onto the app (using AWS Amplify/Congnito to automatically add the user account in the cloud). Subsequently, the app needs to configure the IOT device (ESP32) and send Wifi credentials of home network by connecting to ESP's WiFi AP. However, since both the app and IOT device are isolated from each other (except during the configuration process), I don't have much idea on how exactly will mobile app connect (creating a unique IOT thing automatically) and communicate with the isolated IOT device over AWS IOT cloud.
I have worked with some of the AWS services like AWS Lambda, DynamoDB, AWS IOT for quite a while, hence I am aware of the basics. One of the possible solutions for the above maybe Fleet Provisioning by a Trusted User feature provided by AWS IOT (I did read it's documentation, but still confused). We can also use ESP32's Bluetooth feature for the app to scan nearby devices with which it needs to connect with, but I am not sure how will the connection establish through AWS cloud.
Since I am a beginner to AWS cloud services, it'd be great if someone can provide a possible solution for the above in detail. Also if possible, please provide a solution which would work incase of a large-scale deployment of the above project.
The parts you may be missing are missing are 1) MQTT messaging, which is the IoT message broker service provided by IoT Core, and 2) the need for an application program interface to handle creating and activating devices.
MQTT is a lightweight and widely adopted messaging protocol that is designed for constrained devices.
Your devices (things) will need to communicate back to AWS via MQTT messages, which are captured and processed by the IoT Rules service.
These rules typically trigger Lambda functions, which implement the process logic you need for your application.
See https://mqtt.org/ and https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html
2} you will want to implement a simple API to handle device activation. The AWS API Gateway service makes it easy to implement APIs. For example, you can implement an endpoint for POST /device/ to create a device. That endpoint can trigger a Lambda handles device provisionsing.
Let me briefly describe the context. Near future will bring changes which means in short introducing API Management solution for the company (large). A lot of different systems around, SOAP, REST, some other protocols.
The goal is to have one marketplace when user/customer could easily search through those mess. The case is that most of the avaliable APIS/Services are behind departments gateways, there are many of services behind such GW coupled by deparment context mostly. The main goal of GW's is to protect backend services in a way that those gateways verifies token with Identity & Authorization Provider (one common for company).
How can i publish those services which are behind those gateways? There are no swagger definition available for most of them. I have some concept idea but would be more than happy to know production solution for that case.
By using wso2 API Manager You can publish REST, SOAP, Websocket API's and you can provide different types of authentication like OAuth2, JWT, etc.
You can provide Scope(Authorization) for each API's
If you are a beginner wso2 API Manager is shipped with Pizza Shack API for learning purpose. Start the wso2 API management server and visit https://localhost:9443/publisher with authentication admin:admin. Once you visit the publisher portal it'll guide you to publish API.
Here is the link for documentation regarding the publishing of API's https://docs.wso2.com/display/AM210/API+Publishing
How can i publish those services which are behind those gateways?
There are no swagger definition available for most of them. I have
some concept idea but would be more than happy to know production
solution for that case.
The swagger definition is another way of publishing API in API manager if you have already swagger definition you can just import. But whatever API's you'll publish in API manager inside it stores as a Swagger definition.
If you are using Wso2 API manager for Production use please refer the following:https://docs.wso2.com/display/AM260/Product+Administration which will describe the necessary changes and fine-tuning to be done for production.
Further if you can have multitenant setup, in which each tenant will have a separate store which is a great feature https://wso2.com/library/articles/2016/08/article-multi-tenant-api-management-with-wso2-api-manager/
We are developing a merchant application in that we have various modules like Schedule, Booking, Invoice e.t.c, each of this module are runs in different server, those are exposed through as RESTful granular services. UI layer will communicate with these granular service accordingly. To identify the request and redirect to specific micro service runs in service layer of various sever we have created a service gateway. Some of the service required data manipulation on the go which is presently accomplished through Mule ESB and some routing activities are also managed through it.
Actual purpose of the Service gateway is to match the request with service dictionary available and redirect to the respective micro service, at present its been developed in j2ee framework and runs in wildfly server. So to achieve the same process in light weight manner we come across a micro service manager like"getKong" and Customising "nginx" server to manage microservices, Mule ESB.
Along with Service Bus management is it advisable to use the Mule ESB as MicroService maanager as like getKong or any other valuable suggestion ?
In my personal opinion, you have three options:
If you don't need to perform authentication/authorization or/and
Throttling and your routing can be quite complex/complicated than is
completely fine to do it in Mule ESB.
If you do just URL rewrite nginx is probally the best choice for
minimum overhead and maximum performances.
If you really need an API manager with all the rich features than is
fine getKong or, if you want to stay in the MuleSoft
world and your are willing to pay, you can have a look at API
Gateway.
Hope this helps