We have just started splitting our monolith into services. We are going to extract the authentication/authorization service out of the monolith first. Now we have a choice - API Gateway to provide authentication vs a standalone service (Like IdentityServer4 for example).
Our auth scenarios are pretty broad - web app, mobile apps, internal tools, Oauth1 that needs to be deprecated, some hand-written API authentication.
I'm leaning towards the separate service approach, because of pros:
We can deploy/scale auth and gateway separately
We can swap gateway for another one easier
Auth server is open source and written in familiar language, easier for us to undestand - customizing it is likely to be easier
But the Cons I can see:
More moving parts
We will need to integrate Auth Server and Gateway that may be hard
I wonder what are other pros/cons of both approaches that I'm missing?
Related
We want to use Web API for inter-operable purposes. i mean our web api can be exposed and used in different type of apps ( Asp.net mvc, php, android, windows store/phone and ios).
We are not using wcf and prefer web api. Will it be a good choice ? we just need http and https.
Please guide the best.
if you only need support http protocol yes, web api is an excellent option, web api has a lot of features that can help you to build robust http services, and yes, I mean is a good choice.
be careful when you build yours web api service, use best practices, security in your service, and think in rest architecture, not only simple web services and you will have a true rest service
If you want to read more about this (to have a good base, not the final or only way to do this), see the rest maturity model and json api.
WCF is the best way when you need to support others protocols that only http.
Regards
I have reading and developing my understanding with SOA, I found this approach of development useful. However there are couple of thing confusing me which are:
Background: we are designing online financial application, recently we are in phase of designing brain storming sessions. (audit & logging need to be done)
1 - how to make sure Secure inter process communication?
My thinking: to restrict external access to these API's by firewall. So these can only be call internally by system.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
My Thinking: For read we can use Rest and for ACID compliance transactions we can utilize soap as its provide point to point security. Or for IPC we are thinking to utilize soap as its provide audit mechanism also.
3 - What is Role of API gateway? specially is it involve in inter process communication?
I am confused on this specially with IPC. I think all request even services to services call will perform via API gateway. Kindly elaborate this in detail if I am wrong.
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
What ever I have research we can do this.
5 - What is major difference and pros and cons of SOA and Micro SOA?
My view: Msoa is extention of SOA.
Thanks in advance.
Can anyone draw a diagram or provide link of MSOA architecture diagram with API gateway.
APIGEE is primary source of my understanding, then google it specifics which move in different directions.
Security is our major concern.
1 - how to make sure Secure inter process communication?
Internally, whitelisting IP's and firewalls are probably the most secure. If these servcies scale and have dynamic IP's you may have an issue with that, in which case shared secrets can work, but ned to be put in place and respected across all services. JWT's are quite good for this (similar to SAML, but not as painful), used with an authentication microservice.
Externally - tokens, OAuth2 depending on how much pain you want to go through.
2 - what will be preferred protocol rest or soap in context of private api (IPC) and public APIs (exposed to clients for e.g mobile,web and desktop)
I would use REST, SOAP is slowly becoming an antiquated standard, you can secure comms p2p by using TLS or HMAC signing.
3 - What is Role of API gateway? specially is it involve in inter process communication?
An API gateway is usually used to expose legacy APIs to the public, or to manage a large set of internal services via single amanged interface. An API gateway can also help manage tokens for clients and offer a single token for multi-service access and obfuscate the internal APIs from the external interface.
Gateways tend to also offer developer portals and some kind of self-enrollment process as well as control flows for request content (inbound and outbound).
Tyk.io is an open source API Gateway - you can see the kind of features to expect from a gateway on their home page
4 - is this possible to keep some services public and some private in micro services architecture? how to logically separate both of them?
Yes, you can with an API gateway. So long as there are no inter-service dependencies.
5 - What is major difference and pros and cons of SOA and Micro SOA?
I think one is a subset of the other, SOA tends to be interconnected with a messaging structure like an ESB, but micro-SOA will bhe even more specialised and may not use an ESB.
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)
I have an web application built using RESTful services (JAX-RS).
There are REST calls, and simple JSPs with js files to handle data.
Now I want to implement authentication and authorization in service. What I did earlier was to implement simple filter and inside each service check for #HttpRequestContext for if session has user object. Since it I want to expose service to say, external webapp, I will have to hard code system as there is no standard.
I feel this is not good design. Is there a design pattern to solve this common issue ?
I have a web service that accepts CAS proxy tickets over HTTP Basic authentication headers via Spring Security. How do I perform integration testing with my client since there seems to be no programmatic way to fetch CAS tickets?
Since the CAS setup is one of the more tricky aspects of the project configuration I really need that to be part of our automated integration tests but I have hit a roadblock.
You be interested in the CAS RESTful API: https://wiki.jasig.org/display/CASUM/RESTful+API
The RESTful API follows the same basic protocol as the original CAS2 protocol, augmented with some additional well-defined resource urls. This is particularly helpful for applications that need to programmatically access CAS.
Hope this helps.