I have searched the World wide web and the official AWS documentation for a solution to implement the mTLS over Imap connection in AWS Workmail.
Unfortunately, without any luck, I did not find any information. I have spoken with tech support over at AWS, and they did not give me the relevant information.
It seems like they do not support this feature on Workmail, the only place where they do support it is on AWS API Gateway.
I'm really out of options; I'm not very familiar with the AWS environment and would like to know if someone has done this configuration in the past and how it can be done. It does look like a simple thing that many other email servers do support (such as Microsoft Exchange)
Related
I'd like to use Spinnaker's Kayenta application to provide canary deployment analysis using AWS Managed Prometheus as its source for metrics data.
The open source Spinnaker's Kayenta application looks like it only supports basic and bearer token authentication. It looks like it does not support signing a request using AWS SigV4, which is the authentication mechanism used by AWS Managed Prometheus.
Has anyone else thought through this? Do you have suggestions on how to put these together? One option would be to add the feature to Kayenta, which will take time; another might be to put a signing proxy in place (there's a signing proxy from AWSLabs that could be adapted...
Love to hear your thoughts on what might be doable.
I would like to explore what approaches AWS provide to implement a reverse proxy pattern using native AWS services. I can think of the following services that may or may not be appropriate depending on exactly what functionality is required: Application Load Balancer, API Gateway, CloudFront and AWS Amplify. Can anyone point me to any documentation that would help me understand the suitability of these services or indeed know of any other AWS services that I have not considered? Does anyone have any knowledge or recommendation that they are willing to share?
Thanks in advance
I'm reading the AWS docs and am a little confused as to why x.509 certificates are associated to specific IAM Users in AWS. I can't really find an answer so I feel I'm missing something.
Can anyone tell me why this is? I've done my Googling and read up on the documents but it seems that the logic behind why this is, is implied.
As far as I know, this is legacy functionality, no longer serving any useful purpose. Many years ago, X.509 certificates were used to sign requests for AWS SOAP APIs.
All of these are likely deprecated if not gone entirely.
In some cases -- like EC2 -- the SOAP functionality was deprecated and later completely removed from the API and SDKs in late 2015.
So this IAM feature would only be used for legacy systems using other AWS services that still support the old SOAP APIs that expect X.509-based authentication, assuming there are any. If there are, the documentation has long since been deleted or is buried, as is the case for S3, which only supports SOAP over HTTPS these days, and appears to expect Access Keys rather than certificates.
Perhaps SimpleDB still supports the old SOAP API. SimpleDB? One of the original Amazon Web Services like SQS and S3, SimpleDB was -- sort of, kind of, in a manner of speaking, loosely -- a predecessor to DynamoDB... it was quite an innovation back in its day, and it is still alive though perhaps not well, and you will be hard-pressed to find anyone talk about it, or find much evidence of it in the AWS documentation, though it's there if you know where to look. SimpleDB hasn't been deployed in any AWS region that launched after about 2013.
I am currently working on a web portal for a foundation. Applicants for a grant will receive access data in advance independently of this portal. New applications will then be created and processed in the portal itself. Once an application is complete, it is sent off. Later the application will be approved or rejected.
There are a number of technical specifications on which I have no influence. The frontend should be implemented using Html+Javascript. The backend should use the Amazon Web Services (AWS). If there is a need to program something for the backend - then C# should be used.
I know how to implement the classic client-server solution. At the moment, however, AWS offers me an unmanageable set of services. And here I'm hoping for suggestions as to which of the services I should take a closer look at. Ideally, no complete 'server solution' should run on a virtual server. Instead, Lambda functions are mentioned again and again. So would Amazon RDS and AWS Lambda be a sensible and sufficient combination? Did I miss something?
Thank you very much for your suggestions.
One solution would be to use AWS S3 to server HTML, CSS, JS, Images and other static content. You could use AWS Lambda via AWS API Gateway to serve as a backend. AWS Lambda would then connect to AWS RDS or AWS DynamoDB if you would prefer a NoSQL solution.
Image taken from AWS Github repo
You can get a more detailed description of how to set this up at
https://github.com/aws-samples/aws-serverless-workshops/tree/master/WebApplication/
I would like to add Amazon services to my CodeName one App, I have downloaded java-SDK from Amazon and added a library to my App. Everything working properly in simulator once I gave Android build.
If I try to access Amazon AWS in my android app I'm getting an error like "NoClassDefFoundError".
Here my question is CodeName one supports Amazon AWS or not.
If Codename One supports integration with Amazon AWS then how can I integrate and use below AWS services
Amazon Cognito,
Amazon Cognito Sync,
Amazon API Gateway,
Amazon DynamoDB,
AWS Device Farm,
Amazon SNS(Simple Notification Service),
Amazon Analytics.
You can't just add an arbitrary JAR to Codename One, because we don't support all the features of Java SE as explained here.
There are two ways in which you can support Amazon and you can see samples of both approaches in the libraries section of Codename One.
Wrap the native Android/iOS libraries - there is a long tutorial for this here and in the developer guide.
Wrap the webservice/JSON API's which is a better approach in many regards as it is 100% portable and will bring you into platforms like UWP, Desktop, Web etc. This is the approach taken by parse4cn1.
Option 2 is superior for solutions like AWS as it's much easier to debug and doesn't require any native code etc. Ideally we'd love to have a proper AWS cn1lib similarly to the parse cn1lib.