I am working in IVR team. I write SOAP web services, write java client to access those web services and set data in the session variables of the CISCO API and IVR can then able to access that data. I am very good at this.
Currently, my manager plans to move from CISCO IVR to Amazon Connect. Amazon Connect has all infrastructure and IVR can be set up in 45 minutes.
My task is to access existing legacy SOAP web services(which has access to our databases) in AWS Lambda and give that data to IVR.
I went through all the documentation, but not able to figure out where to start. Could some one give me guidance on where to start.
Here's an article about calling SOAP services from a Lambda function, with a walkthrough of the process: https://blog.codecentric.de/en/2016/12/serverless-soap-legacy-api-integration-java-aws-lambda-aws-api-gateway/
It goes further than what you may need, adding API gateway on top of the Lambda function. You may not need that if you're just planning to call those Lambda functions from Connect.
There's also an article in Connect documentation on integrating with Lambda: http://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html
Related
I have a requirement where I have to schedule a console application, which fetches certain records from database and calls an ASP.NET web API. Could someone help me with how to restrict the web API to not get called from anywhere else?
Please help me with any useful links, tips, or steps to follow.
There are a few ways you can lock down access to your application for an rpc call.
You can restrict access via IP with IP filtering.
If you're using windows authentication, you can grant permission to specific AD User or Groups in your web config file.
If you're using forms authentication and basically just need to make an RPC call, you can create an endpoint for your console app which accepts a username/password parameter (using https, of course).
If your setup is more advanced, you can use tokens and ASPNET Identity to limit access.
These are just a few ideas. Basically just google ASPNET security and you'll get a ton of ideas.
I would appreciate with help on this. I watch a hyperledger comoposer tutorial where Zach Gollwitzer said there are 2 options to secure the rest-server API of the business network, one was to put it behind an API Management gateway and the other with multi-user mode. I would like to know how I can export the Rest rever API To AWS API gateway. What file is used to do this. thanks in advance.
When your rest server is started you should be able to 'hit'
http://localhost:3000/explorer/swagger.json which describes the various API endpoints.
Hopefully this is enough for the AWS API gateway.
I need help in integrate AWS API gateway with luman as end point. I have working project with one web part(Laravel) and three luman project for different micro services. We are using AWS API gateway to point out to luman services. Right now we don't have any authentication on web services on luman. Anyone can have access to these if he know URL. We are planing to use oAuth2 for authentication. but i am not able to understand how it work. As we have mobile app for this project too. So my question is.
Is oAuth need to be implemented on luman project or on AWS API gateway.
In both cases how it will work. Also we are planning to move luman project to private network(no internat) which will not have public access. in that case we need to use lambda function to communicate with the private network.
So how it will work in this case.
Please suggest.
If you want to know how AWS API Gateway works with oAuth I'd recommend checking AWS public documentation and AWS Compute Blog.
My mobile app needs to make secure API calls to on-premise backend services which is not exposed to internet but accessed only by mobile client. How can we secure the backend calls via AWS cloud?
Thanks in Advance
AWS does not have an out-of-the-box solution for what you are looking for. Amazon Cognito's Identity component was designed to secure access to AWS API's, not a developer's. You will have to build your authentication and authorization service for your mobile clients.
Another AWS technology that you may want to consider in your design is Amazon Virtual Private Cloud (VPC), which would allow you to bridge your on-premise network into the AWS cloud. From their you would have to properly secure systems and APIs.
Update 2015-07-09 AWS has announced Amazon API Gateway. Using API Gateway you can build a REST interface to your existing API (or to AWS Lamdba functions) secured with credentials retrieved via an Amazon Cognito authflow. See this blog post for additional announcement details.
I have been looking into whether it is possible to use Shibboleth/SAML with Amazon Web Services.
I'm finding very little information on this. As far as I can tell, it is possible to install Shibboleth/SAML on an EC2 server as a Service Provider.
What I am not so sure on is whether it is possible to tie all of AWS to Shibboleth - and how this would work.
My knowledge of all three are vaguely fuzzy - I've been doing a great deal of reading, but I'm not really familiar with this technology at all.
If I understand you correctly, what you are trying to do is use identity federation to grant a user temporary security credentials to perform AWS api calls. You would like your users to authenticate to your own identity provider (Shibboleth in this case), and be granted access to AWS services based on that authentication.
A good example of this that you can use as a framework is in this AWS sample code.
In a nutshell:
You need a proxy that the users connect to, passing in their authentication credentials. You would then verify them by authenticating to Shibboleth, AD, LDAP or whatever.
You need a Token Vending Machine that your proxy would then call to get a valid AWS secret key using GetFederationTokenRequest.
Your client would then use the token given to it to make the AWS api calls.
The concepts of federated identity include terms like STS, SP, and IdP, if you are looking for a starting place to research the topic more.