I'm creating my service in Google Cloud platform Kubernetes cluster, it is a simple application that has two endpoints one is public another is secured. For authentication, I use Cloud Identity. Cloud identity is using Firebase under the hood and JWT token has some attributes such as name which in my case is "firebase" and audiences which corresponds to my project id.
For AppEngine app I can use cloud endpoints and it verifies JWT, but what I should use when deploying app to Kubernetes ? I saw that one option is Istio are there more options ?
You can use Cloud Endpoint with GKE.
Check this official tutorial : Getting started with Cloud Endpoints on GKE, it may help you.
For your information, you can also consider Cloud Run as a fully serverless alternative. It provides a built-in authentication layer.
I have an application which is built using Spring MVC and the backend is REST API also built using spring MVC framework.
The request from the browser first hits the springMvc app which then calls my REST API for data. I do not have any needs to expose my API's publicly. So I am not thinking to use any API gateway.
For security, am thinking to host my REST app in a private subnet and host the springMVC app in public subnet in a VPC.
My question is what if some developers would like to test the API's directly , what provisions are available in AWS to manage this in development environment.
I am using AWS cognito for authentication and am just going to validate the token in the REST app for additional security. At netwrok level, I am planning to use Netwrok ACLs to restrict the REST app to be only called by my springMVC app. Basically one public subnet and one private subnet.
Please help if my understanding is correct in this regards and would it cause any design issues later on.
If at some stage later, I plan to expose my API's to lets say a mobile app, I might have to do some rework. Is it worth it to think about future now and design accorindgly considering it might not take much time if I am on AWS.
You can use API Gateway to create private APIs that are only accessible by your VPC. You should consider using this option if possible. There are a lot of things that are difficult to manage when it comes to APIs such throttling, caching, and logging. Using API Gateway a lot of the scaffolding and instrumentation work for the API will already be done. You can also connect Cognito user pools to the API Gateway.
This blog post has a good overview and an example.
I'm a beginner in context of google-cloud-endpoints and the associated product "google-cloud-app-engine".
I've created a simple google app angine project/application and created an API-Key by using the google cloud platform's console.
To my app-engine's endpoints API definition I've added the annotation
"apiKeyRequired = AnnotationBoolean.TRUE" as stated in
Add API restriction by adding an API key to your app engine application
and my client application which uses the generated endpoints client API was also updated accordingly to send the generated API key for all API requests.
As I would like to test the "API-Key" mechanism locally on my development machine (using a local app-engine environment) before deploying the backend to the cloud, I would like to know, whether it is possible to test the "API-Key"-restrictions locally. I mean, somehow the locally executed app-engine backend app has to be aware of the created API key. Maybe there is a property which I have to provide to my app-engine backend application's POM.xml file...I don't know, whether the google app-engine SDK supports API keys for local testing in context of the "endpoints framework v2" actually. The newley introduced API Management Platform (API-Gateway) can maybe not be "simulated" locally...?!
Thank you so far for your effort!
API key restrictions should work locally. You just need to include GoogleAppEngineControlFilter in your web.xml.
I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.
Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.
I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)
I have a Google App Engine application deployed which contains and manages user data. My users may want to share their personal data with third party sites. Think Garmin sharing running data with myfitness pal or Strava.
The google documentation is gives good examples for using endpoints with iOS, Android, and javascript based web apps. These examples use a client id but not a "client secret" and do not involve refreshing the access tokens.
I have a javascript app running on a third-party site that does one time lookups against the api well.
I’d like to create a sample server app, preferably in java, that would connect periodically using an assigned client secret and refresh access tokens.
I have found documentation for accessing Google API's at the second link below but it is not clear if "Google APIs" include Google App Engine endpoints or just the standard suite of google apis.
What is not clear to me is that at the first link the documentation suggests that a client library needs to be generated from the backend endpoint api using maven or the endpoints.sh tool. Examples are provided for iOS/Android but there is no discussion for third party access.
Does anyone know is the server access configuration I describe possible with custom endpoints? Has anyone encountered example code for a server app that uses refresh tokens against an endpoint api?
Thanks!
End Points Documentation:
https://cloud.google.com/appengine/docs/java/endpoints/auth
OAuth Documentation:
https://developers.google.com/identity/protocols/OAuth2InstalledApp