I have developed a set of Jersey-based REST APIs and deployed them to a Tomcat application server running on Elastic Beanstalk. Our application architecture requires that these REST APIs be accessed from an AngularJS web front end. The web front-end requires user authentication and we want all the accesses to these APIs to be restricted to users who are authenticated. This is a pretty common application architecture pattern.
Now mapping this architectural pattern to AWS services, we configure a Cognito user pool to authenticate users. We map this user pool to an identity pool, to which we attach a policy that allows for access to Beanstalk applications. From here, I don't know what to do next in order to configure secure access to REST APIs. A number of areas in this technical architecture are still not clear to me.
1) How to secure REST APIs on the server (i.e. AWS) side
Because we are using Tomcat container to host Jersey application, the "standard" JEE approach is to declare security constraint in web.xml, as demonstrated in the example below:
<security-constraint>
<web-resource-collection>
<url-pattern>/rest/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
I am wondering if this role-name "admin" will be ingested by Elastic beanstalk? So if I defined a role "admin" in IAM, and specify the above stanza in web.xml, will Tomcat app server at runtime perform the check? In my application, if I use standard SecurityContext.isUserInRole("admin"), SecurityContext.getUserPrincipal() etc, what kind of values will be returned?
2) web front end service invocation
because we are using AngularJS, the standard approach is to use the built-in $http service to invoke remote REST APIs. Suppose a user logs in through Cognito successfully, and obtains a JWT access token, how should we pass it to the http call to the REST API? Will AWS Javascript SDK automatically add proper HTTP headers to the $http service call or we need to handle this explicitly in our code?
I have researched quite a bit in the Elastic Beanstalk documentation, in particular the section of "integration with IAM service". However, the documentation does not seem to cover my questions above.
I would like to understand:
1) architecturally, how my questions above could be resolved in AWS Beanstalk. I am sure it can be done as it is a common architectural pattern. I just couldn't find the right answer in the documentation.
2) is there a pointer to some sample code? I went through some Java web app samples and built one by myself. However, these samples do not cover my requirements above.
Appreciate if any friend could enlighten me on this topic.
zx999
Related
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
We have an enterprise web application implemented based on Spring-Security for authentication/authorization. This application is currently deployed on-premises on client side and usually we connect it to existing AD/LDAP systems.
Now we'd like to setup this web application within Amazon AWS for demo purposes. Therefore we need a kind of an user access frontend, where users can register and as soon as an admin approved this, the user should have access to the webapp ui. In addition a simple analytics layer is needed, to see some information about the user access.
It is important to have this "frontend" (could be a simple website based on a CMS like WordPress) just to explain the demo, to have the user registration functionality and the analytics layer. We explicitly don't want to include this in the existing web application, so it must be decoupled from each other.
What could be the right approach to setup such an environment? I just need the right direction to dig into the topics.
After a first research, we see that Amazon Cognito could be the right backend service for user data management. But we don't see "an easy way" to enable a simple frontend as described above (e.g. I didn't find a wordpress plugin to connect wordpress user data management with Apache Cognito). Also on the backend side I haven't find useful information how to integrate Apache Cognito with Spring Security.
If you are looking for a simple frontend we launched a new feature which gives you basic signup/login pages for your user pool.
I have an ASP.NET web api running on a Windows EC2 instance together with DynamoDB data layer. I've been looking for alternative choices on aws to secure my web api.
For that purpose, I read AWS STS and API Gateway docs. API Gateway is the first choice but I wouldn't like to use it because it forces me to learn node.js.
Cognito seems the best choice for me because it will also handle both mobil and web users. I know that Cognito also provide security on aws resources.
My question is:
Is it possible to secure Web APIs running on EC2 instances without using security tokens. Can cognito control all incoming API calls without need any additional security steps?
Thanks
Such as two factor authentication, 3rd party OAuth, Connecting to LDAP.
I have added the above security to Wso2 Identity Server. But please help me achieve the same with Wso2 ESB.
Thanks
Where you want to add the security? What you want to secure?
I see two parts where the user security may play role in ESB:
For the carbon (management) console, I may disappoint you, that may not be so simple. See the Custom carbon authentication . It seems you need to enable other authenticators or add your own (see the file authenticators.xml, they are disabled by default) and "patch" the carbon to use it. However - for our best practices the management console (and the management services) should be not accessible from untrusted network .
If you're talking about securing the web services, this is not something an end user (person) is accessing. Ok - excluding the REST services. There are multiple options available to secure web services. From basic authentication (and username token), to STS (security token service), signing and encrypting the payload. See Securing web services, however here we assume some knowledge about the service security.
I am working on a web application implementing online shopping functionality. I am using Struts2 + Spring + Hibernate. I am using Spring security to implement authorization and authentication.
Now my client wants to develop an iOS/Android App for the same where users of my web application can login and use some of the functionality using the app.
Mobile App will access the REST based web services on JSON which will be implemented using Jersey. Here are my questions:
Users are going to have a role from three of the roles. Depending on the role they should be able to access the specific resources. I am thinking about using Spring Security 2.0 with Jersey and authenticate the users using OAuth 2.0. Is OAuth 2.0 right applicable choice?
Also, Jersey doesn't support oAuth 2.0 on server side. Still I guess I should be able to use any other OAuth provider to secure Jersey services right?
If oAuth is not the right choice then what I can use to provide role based authentication and authorization for Mobile App users to my REST web services.
Don't forget you can use simple HTTP BASIC auth (with SSL, of course).
For comparsions of OAuth versions, see this.
After having to deal with the same problem I did some research and currently I can see 3 solutions.
Pivotal actually have a piece of software which they use for their cloudfoundry services, called UAA (User Account and Authentication) Server. You can deploy this to your own server, and it's role is basically to provide OAuth2 access tokens. You will need to create your own Resource Server which will serve different resources if the correct OAuth token is provided in the request. (they have a couple of sample apps in the UAA repo which you can use) https://github.com/cloudfoundry/uaa
Google actually provide services like that. If you host your backend on appengine you can use cloud endpoints to expose your API and they take care of Authentication and Authorization.
https://cloud.google.com/appengine/docs/java/endpoints/
You can create your own architecture. Basic approach would be to have an Authorization server (to generate tokens), an Resource Server (to serve your API) and some sort of storage for users and tokens.
Hope that helps a bit, I'm personally going to go with the UAA to try it out.