Lets say we have a list of microservices based on Azure FnApps - user-service, search-service, product-service etc...
Each of the service is deployed gobally.
Eg :
user-service-uk.azurewebsites.net
user-service-west-us.azurewebsites.net
search-service-south-east-asia.azurewebsites.net
search-service-uk.azurewebsites.net
search-service-east-us.azurewebsites.net
..... ETC
We have an APIM interface wrapping all the api-operations and performing AuthZ & AuthN. So this cannot be removed or replaced.
myapis.azure-apis.net/user
myapis.azure-apis.net/search
myapis.azure-apis.net/product
What is the best way to do geo-traffic management in this scenario.
Our current approach is using APIM policies.
<choose>
<when condition="#("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://user-service-west-us.azurewebsites.net/" />
</when>
<when condition="#("South East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://user-service-south-east-asia.azurewebsites.net/" />
</when>
<otherwise>
<set-backend-service base-url="https://user-service-west-us.azurewebsites.net" />
</otherwise>
</choose>
But with more micro-services growing and our app venturing into more regions, we are facing maintainence nightmare for the policies.
We explored Azure Front Door, but the URL Rewrite doesn't let us carry the suffix of the pattern matched.
Eg:
For the url, https:myapi.azure-afd.net/user
Is there a way to set up the Routing-Tab's URLRewrite when the url matches with /user/* Custom Rewrite to /* (meaning entire url-suffix except /user)
PS:
An alternate approch we thought of is creating one Azure Traffic Manager profile per microservice
Eg:
https://user-service.trafficmanager.net
https://search-service.trafficmanager.net
https://product-service.trafficmanager.net
However, with 100+ new microservices coming in, we would end-up in a burst of ATM profiles.
As far as I know, to handle the geo-traffic management, you could use Azure traffic manager with geographic traffic-routing method. You could choose to distribute traffic based on specific geographic locations per endpoint. The same location can't be specified in two endpoints.
In this case, what you need is to create three traffic manager profiles and multiple endpoints to distinguish the client's region. Traffic Manager uses the source IP address of the DNS query to determine the region from where a user is querying.
https://user-service.trafficmanager.net ---> endpoints
{user-service-uk.azurewebsites.net, user-service-west-us.azurewebsites.net,...}
https://search-service.trafficmanager.net ---> endpoints
{search-service-south-east-asia.azurewebsites.net, search-service-uk.azurewebsites.net,...}
https://product-service.trafficmanager.net ---> endpoints
{product-service-south-east-asia.azurewebsites.net,...}
Related
I have developed a set of microservices (resource servers) using Spring Boot 1.5.x + OAuth2 with JWT. Right now each microservice is protected using Spring Security i.e. JWT access token is verified at individual resource server level. API Gateway does not have spring security in place, so it just routes the requests to appropriate server and propagates the authentication headers to downstream services.
I wanted to know if there are any disadvantages of this setup compared to the one where AccessToken is verified at API gateway level only. Or is it just a matter of opinion? Doesn't keeping security at API Gateway level breaks principle of loose coupling, because each microservice may better understand the role of a given user in its own context?
API management can do a small check on your JWT (fail early), BUT your microservices are the only one that can really manage all the security stuff !
If you set security only on api management it means that someone that can access your network will be able to push request to your API unauthenticated.
You will not be able to log who do what. And finally, if you need to set some kind of ACL, it will not be possible (When you ask to list orders, you can only list YOUR order).
Perhaps you will think of decoding your JWT on the api management layers and push a header with user name to your backend to prevent all the thing I spoke about above, but I think it is not really a good practice.
First, access to network will means I'm able to be anybody. Then JWT is much more than just a username. For instance, perhaps you use scope on your authentication layers. ( scope read orders / scope modify orders / scope delete orders). This is useful to restrict what an application can do (either at client_id level) or what a user accept to give to the application ( scope share email ...).
For this JWT on the backoffice is mandatory.
Ok you can do like username and extract data on api management and put specific headers to call backend, but really ? why do specific stuff ? oauth2 with JWT can do this for you.
Well this is an interesting question. In our team we discussed about this topic a lot. Basically you have some parameters affecting the individual answer to this question. But you should always decode and verify granted tokens on the microservice level, too. Because they contain relevant information for authentication and in some cases even for authorization. If your microservices run in a enclosed environment (e.g. on enclosed Kubernetes cluster, where only the API-Gateway is available to the outside) you could use this "mixed" solution.
You can really consider just to verify the AccessToken at the API-Gateway and let the other microservices rely on the API Gateway. The API Gateway could than exchange the AccessToken into another AuthToken, only valid in the microservice-context. This new generated AuthToken can for example contain more sensitive application-bound information, because it is not exposed to the client. The Client gets only a so called opaque token. See https://medium.com/tech-tajawal/microservice-authentication-and-authorization-solutions-e0e5e74b248a
I have a single ASP.NET MVC app - website and API controllers. I'd like to use Azure API Management to manage these APIs but retain the same URL so that it is seamless for our consumers. We have a custom domain setup on the app service for this web app that is currently used to serve up both the site and APIs(e.g. Website: xyz.com, APIs: xyz.com/api1, xyz.com/api2, etc.). Also we use AAD for auth. and have the redirect URI setup to the custom domain(xyz.com). Everything works great at present.
The issue arises after we configure API Management to expose our APIs and potentially use it as a passthrough. In order to ensure that the URLs remain the same after API Management is introduced we set the custom domain to be on the API Management instance itself and removed it from the app. service. This is how our current setup looks -->
User hits xyz.com and the request proceeds as follows -> Traffic Manager -> APIM(xyz.com) -> App Service(xxx.azurewebsites.net)
After that last point above, AAD auth. should kick in and once it has the access token after successful auth. it should redirect the user and the page should load. But it doesn't. Instead we get a blank page and if we refresh it, then and only then does it proceed to auth. and load the page.
We have tried setting our redirect URI to both the custom domain(xyz.com) as well as the base app service name that Azure generated(xxx.azurewebsites.net).
Directly hitting the API urls specifically(e.g. xyz.com/api1) works fine. It goes through APIM and responds as expected. The only problem is that the website doesn't load as outlined above.
The moment we take APIM out of the equation, and set the custom domain back on the app service again, everything works as expected.
I'm trying to figure out if we've misconfigured our assets for this scenario somehow or if APIM doesn't support pass through for the website in this manner. Any thoughts/suggestions here would be much appreciated!
Wow, that was a lot of text.
Ok, let's see:
Visitors -> Traffic manager -> APIM -> backend (your website) - ok got it.
this is like a common way of using APIM, and it should work. However, maybe your policies are not set up correctly?
Have you built your product/API/Operations? Do you see requests coming from APIM hitting your site? What responses are you getting?
Now, of course, you will need to define and set up APIM (products, APIs, and every operation) to pass it throw to your backend. This means if you (as a visitor) need to list all products, you would need to go through the APIM operation (sed GetProducts ). Your request will be passed through the Inbound policy(adjust and build the request if needed), pass it to the backend( to your website with custom APIs), and the response will be sent back from the backend back to the visitor.
Now to this: to protect your Web API Backend in APIM, you could use OAuth 2.0 authorization with Azure AD:
big picture overview:
Register an application (for your backend) in Azure AD to represent the API
Register another Application (the client) in Azure AD to represent a client app that will call your API
And I guess this is the one for you grant permissions to allow the client app to call the backend app
And, of course, add the validate-jwt policy to validate the OAuth token for every incoming request
Read om on this here https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
Can Azure Traffic Manager be used with Mobile Apps specially with social login? I have configured a traffic manager and two app services (say, mobileapp1 and mobileapp2) to work with it.They seem to work pretty nice with postman and the response and everything is working. Now, I have declared traffic manager's URL as client in xamarin client app and the app throws exception when I am logging in into azure. After logging in facebook, when I am passing the token to server using this line
var user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
it throws an exception at this line saying invalid operation.
In continuation to this doubt.. I have two mobile apps connected with one traffic manager. Both of them have facebook login configured. So, is it supposed to work? What happens if, when the user is registering he/she is redirected to mobileapp1 and azure authentication is done there while in some subsequent attempts user is redirected to mobileapp2. Does the identity database of mobileapp2 know about the user? This is when I am using the authentication service that comes with mobile app and not B2C.
Based on your code, you are using Client-managed authentication with Azure Mobile Apps. For App Service Authentication / Authorization, such as mobile client type, a JSON web token (JWT) would be issued to the client and the it would be presented in the x-zumo-auth header when sending request to mobile backend. For more details, you could refer to How authentication works in App Service. Here is a JWT token when using Azure traffic manager with Mobile App, we could use jwt.io to decode the token:
For the JWT token, it would use the WEBSITE_AUTH_SIGNING_KEY environment variable to sign audience, issuer, Claims. For more details, you could refer to here about how to use custom authentication for your application.
Each Mobile App has the different WEBSITE_AUTH_SIGNING_KEY, you could use kudu and click Environment to find the it. Moreover, I tried to update my two mobile apps to use the same sign key, but failed for no permission.
Your LoginAsync would send the following request:
POST https://<yourname>.trafficmanager.net/.auth/login/facebook
Body {"access_token":"<access_token_from_facebook>"}
You could use fiddler to capture the network trace.
Can Azure Traffic Manager be used with Mobile Apps specially with social login?
For custom authentication, you could configure the sign key in your web.config file. For social login and use the authentication provided by azure, you could no share the sign key between different mobile apps. Moreover, if you set Routing method to Geographic and your mobile apps are in different Geographic locations, I assume that your scenario may work as expected.
UPDATE1:
After some trials, I found you could specific the WEBSITE_AUTH_SIGNING_KEY setting under the "SETTING > Application settings" blade of your mobile app to override the WEBSITE_AUTH_SIGNING_KEY environment variable as follows:
Note: The signing key needs to be a SHA-256 hashed string, you could sync the key between your two mobile apps or generate your custom key. After configure the setting, you could leverage kudu to check the newest WEBSITE_AUTH_SIGNING_KEY.
UPDATE2:
my problem is figuring out how to use social auth with two different mobile apps where redirection by traffic manager is happening on the basis of performance
As the official documentation mentions about the traffic routing method Performance as follows:
Performance: Select Performance when you have endpoints in different geographic locations and you want end users to use the "closest" endpoint in terms of the lowest network latency.
I did some test, you could refer to it. Here is the Endpoints under my Traffic Manager profile:
Note: My two mobile apps have configured the same Client Id for my MSA authentication and set the same WEBSITE_AUTH_SIGNING_KEY value under "SETTINGS > Application settings" for encoding / decoding the token.
For my /api/values API endpoint, I just return the WEBSITE_HOSTNAME environment variable as follows:
return Request.CreateResponse(new { WEBSITE_HOSTNAME =Environment.GetEnvironmentVariable("WEBSITE_HOSTNAME") });
For the Performance routing method, all my requests would be routed to bruce-mobile02.azurewebsites.net:
For the Weighted routing method, I configured the same WEIGHT for my two endpoints. Per my test, the requests with the same AuthenticationToken that attached as the x-zumo-auth header value for authorization would be routed to my two endpoints as follows:
I am having a difficulty in terms of architecture and wondering if someone has some insights.
The plan
I will have multiple microservices (different laravel projects, catalog.microservice.com, billing.microservice.com) each providing an API.
On top of these will be an angular fronted consuming those APIs.
I will have another micro service (passport.microservice.com) for auth now thanks to laravel 5.3 passport this is even easier.
The flow:
User goes to catalog.microservice.com
user need to authenticate and provides a user and password
request is made by angular (aka client) to passport.microservice.com through password grand type to get an authorization token
now that I have a token I am authorized to call a resource from catalog.microservice.com
catalog.microservice.com needs to know if the token is valid and makes a request (some kind of middleware?) to passport.microservice.com
passport.microservice.com returns the user, scope etc.
Questions:
Is this a good approach?
The token validation in catalog.microservice.com can be a middleware?
The common approach in microservices architecture is to use a single authentication 'gateway', and usually it's a part of an API gateway.
So besides your passport.ms.com, you have somewhat of a proxy that will check access token from the header and if it's invalid - give an error. If the token is valid - proxy the request to corresponding microservice.
This way you don't have to repeat yourself - you don't have to implement authentication N times for each microservice.
Then, if you need more granular control - what exactly a user can access (usually called authorisation), then you traditionally implement it at each specific microservice.
In short, your microservices shouldn't care if the incoming request is authenticated - it's already been pre-filtered for them. Microservices only decide whether the user X can do action Y.
PS. You can combine API gateway with Passport/Oauth facility or you may run them separately - that's up to you. AWS already offers API gateway as a service (proving how trendy microservices are becoming) but I couldn't find any good open source analogues.
Your api should have a gateway that handles the Authentication and communicates to different micro-services.
Its makes sense to authenticate (or reject unauthorised) users at the top level, combine responses from different services and then your clients(Web or mobile) can consume that data.
An advantage of this is that your clients only need to remember just one url.
Example: Only microservice.com is needed and not catalog.microservice.com, users.microservice.com, passport.microservice.com etc.
A single endpoint address (URL) is much easier to remember and configure than many individual API addresses.
Here is a link to an image describing this architecture.
Api Architecture image
I am starting a new project where we are planing to build a restful back end and an AJAX font end. I am approaching the problem by focusing on Identifying all the resources that I have and what the various HTTP verbs will do them, their URI and the JSON representations of those resources.
I am looking for the best design for securing the backend. Here is the list of designs I have considered. I am looking for alternative designs not listed below, and pros, cons recommendations. The system will be implemented with Spring 3.0 and possibly Spring Security 3.0, SSL will be used for many parts of the system but not for all of them, so some requests may come on SSL and some might not.
Option 1: Use the HTTP session
Show a standard login screen, create a server side session and let tomcat send back a jsessionid cookie and have the ajax client include the JSESSIONID cookie on every XHR request. This options just feels like it's the wrong approach for the following reasons.
The connection becomes statefull which is against the rules of REST
I want to be able to split the bakcend into multiple seperate WAR files which means i could have multiple HTTP sessions on the backend, if that is the case then this approach does not work. While I don't need the ability to split the backend into multiple apps today, I would prefer a design that allows for that possibility.
Option 2: Find an open source Java based security library that does this
Other than Spring security I have not found any other Java libraries, any recommendations are highly appreciated.
Option 3: Try to use an existing protocol like OAuth
In my very brief look at OAuth it seems that it is designed for authentication across sites where each site has it's own user database. In this system i want a global user database shared across all the backend ajax services.
Option 4: Use SAML and Shiboleth
This options seems over kill and hugely complex to setup and maintain.
Option 5: Send the username and password with every request
This requires that user sends their username and password with every request, which means that the front end AJAX app must store the username and password as a JavaScript object and if the user navigates away from the page then back the username/password combo will be gone and the user might be forced to log in again. I don't want the front end to try and put the username and password into cookie as that would comprise security.
Option 6: Implement my own authentication / Authorization protocol
Create a REST service that users can present their username/password combination to and then get back and security token, which they must send back to the service with every request. The security token would be digitally signed by the service and would have an expiry time. The token would be only good for most operations high security operations would require a new login screen as port of confirming the operation.
Problem with this approach is I have to invent yet another security protocol which seems like a total waste of time.
I am sure I am not the only person up against this problem, I hope the stack overflow community can point to some options and tools that I have not found yet.
Take a look at Apache Shiro. It is an authentication system that has a session management feature that can be used to share sessions across applications. This may be the easiest thing to do.
Or you could use Spring Security (or Shiro) with a Remember Me cookie that is shared across the webapps (as long as they are in the same HTTP domain). The remember me cookie would be analogous to your token in option 6. You can set the expiration on the cookie that so it is short lived like a session cookie or long lived like a regular remember me.
You might also want to take a look at Jasig CAS - Single Sign-On for the Web. It has a REST API and a protocol (Proxy Tickets) that allows services to proxy user AuthN to backend services like you described in option 6. http://www.jasig.org/cas
Briefly...the application that serves up the AJAX client is protected with Spring Security (supports CAS out of the box) and gets a Proxy Granting Ticket that you embed in the AJAX client. The AJAX client uses the PGT to get Proxy Tickets for your REST services...protected with Spring Security too. The REST services get an authenticated userId without every touching primary credentials.
Alternative, you could keep the PGT on the server and use AJAX calls to retrieve Proxy Tickets that are then used by the AJAX client to call you REST services.
As I understood you are going to secure a rest application, to preface you must know that a security provider consisd of three concepts (3A):
-Authentication
-Authorization
-Auditing
to implement these three together you must provide bunch of tools such as :
-SSO provider
-Session Store
-Open Id pattern
-user credentials integration
....
I have used ACL(Spring ACL) to provide authorization services and oauth2 for authentication.
there is one channel to connect these two together and its scopes(oauth2 scopes) but the problem is scopes are not flexible(pure strings) enough to implement authorization modules such as role_voter, cache_strategy, black_list or,Role_base strategy, exceptional permissions, white_list... (but you can use #EnableGlobalMethodSecurity)
In my case I used authorization server as a resource for oauth2 authentication server(take a look at http://projects.spring.io/spring-security-oauth/docs/oauth2.html), then I considered two spots to check authorization, the first I issued ACL to front-end and forced programmer to design her page dynamically up to ACL concept, the second is in back-end on service layer(BLL) using Aspect when one rest is going to be called. I sent the service key as an actee to check if current user has enough access control to do that. and for auditing you must monitor all requests I mean you must use an listener in your gateway or broker...