Is it possible to generate a technical SAML and propagate it while making a REST API call?
While flink documentation doesn't really talk about SAML anywhere, is it possible to rely upon external Scala/Java dependencies for achieving this?
You can put an authenticating proxy in front of the Flink REST API and manage it however you want.
Related
Is there any way to restrict access to the REST API provided by Apache Flink, e.g. using Basic Auth, Api-Key, etc.?
I refer to the "Monitoring REST API" (which is confusingly not only monitoring but also job control).
One solution others have used is to put nginx in front of the Flink REST API as a secure proxy.
There is a FLIP about custom netty handlers (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=184616200) that comes with sample use cases such as authentication.
For instance, basic auth = https://issues.apache.org/jira/browse/FLINK-23273 (https://github.com/cloudera/flink-basic-auth-handler)
Could anybody explain how Apache Camel is able to behave as a routing and mediation engine on a JAXRS API?
As far I've being reading about I've not been able to figure out what's it for?
You can consider Apache Camel as a great integration framework. It doesn't provide functionality itself, but it makes easy to glue multiple services and protocols together.
Apache Camel can expose a REST endpoint using the CXFRS component. This means it listens for a REST call on certain endpoint (URL). On invocation it doesn't invoke the implementing bean (service) itself, but executes a defined mediation route (invoke a route with its Exchange object).
It is very useful when you need to integrate multiple services or translate the call to other protocols. You can implement a REST service by a bean itself and it's ok until the bean provides some functionality or data itself. For integration you often need more flexibility to integrate multiple sources and protocols. Then Apache Camel can be much more practical tool.
I have an angular app on a node js server. On another machine, I have an API server. My dilemma is how to communicate with the API server. The first approach is to send all my AJAX calls directly to the API server. The downside of this approach that the client will see how I send the requests to the API, including the secret key I send in the headers. This means I will have to work harder to secure my API. The other approach is to send my requests to my node js server, and then forward them to the API server. The downside of this approach, however, is increased latency, since it will require two serial HTTP requests. I would love to hear from you what you think is the best way to handle this.
Thanks.
First approach, and you "have to work harder to secure your API". I recommend JWT autthorization.
The most popular and reliable solution for this widely followed architecture style (Front End App to Backend API Server) is OAuth.
OAuth is very easy to setup and use with Angular Js.
As far as AJAX calls are concerned, if your application entails this behavior make sure your API is enable with CORS capability.
I have set up a Symfony based API which is being used by an Angular front end which is totally dependent of it (User registration included)
I have read multiple threads recommending using WSSE or FOSOAuthServerBundle but I'm not sure about the best method ?
If I understood correctly, WSSE has to send for each API request x-wsse headers which make me think it is not the best suited for performance.
About the FOSAuthServerBundle I have never used it and looks a bit complicated to me compared to WSSE, thus that's why I'm asking there before trying to implement it.
I have 2 simple groups of user (basic and admin), what would be the best way to secure my API, additionally providing an easy way to keep user persistence (I mean accesses through the different pages)?
How should it be in the Angular front side ?
Thanks for your help.
Refs: http://blog.tankist.de/blog/2013/07/16/oauth2-explained-part-1-principles-and-terminology/
http://obtao.com/blog/2013/06/configure-wsse-on-symfony-with-fosrestbundle/
It all depends on what your requirements are.
First of all, OAuth 2 is an authentication mechanism/spec which you can use in combination with sessions/bearer tokens/... This also applies for local accounts (since you want to do user registration).
FOSAuthServerBundle is a bundle to implement the server-side of the OAuth2 specification. This basically means you can expose your OAuth2 side of the API to other applications and allow them to use your accounts to authenticate. Think google login, twitter login, etc but for your own app.
This all has nothing to do with the way you validate / authorize your requests after the initial login has taken place.
Do you want to implement stateless authentication? Then I would recommend using the new JSON Web Token (JWT) specification.
See Symfony Bundle (LexikJWTAuthenticationBundle) and JWT description (JWT.io)
There are many resources on it from the angular side of things and the API part is pretty straightforward.
WSSE does not seem suited to implement in a RESTful API and I have no experience using/implementing it so I cannot comment on it too much.
I'm about to build a community platform from scratch. We are going to create the WebServices first and the community might have some third party components, so having solid WebServices is a good idea anyway.
Since the service is stateless we need authentication for every single call. Is it a good idea to implement the OAuth protocol for our service provider to perform this task although we are the only consumer right now?
By the way: We will deliver a mobile application before a website is launched.
The whole point of OAuth is to allow other websites (consumers) to get access to your data (you are the provider). Since you are the only consumer of your data, there is no need to implement OAuth at this stage of development.
Be lean, build something fast and put it in front of users/testers. Only at this point you will discover real bugs and get a feedback on the service so that you can improve it and steer the development in the right direction.
Note: OAuth as provided by App Engine (second paragraph) only supports users with Google Accounts (even if OpenID is used).
From my experience I created the REST WS in a authentication agnostic way: jersey methods accept everything, then there are several filters in order to validate the requests.
I used OpenId authentication for the web part, OAuth and BASIC AUTHENTICATION (with SSL) for API.
Probably it is not needed to create everything from the beginning, but remember to de-couple as much as possible your REST endpoint from the authentication: you will have a great benefit when you want to release APIs.
Last "philosophical" thing: OAuth is not totally stateless, in fact you have a temporary token that authenticates a user and it is similar to a session in the browser!