Vladimir Vinogradsky opens with a list of features that Azure API Management offers before diving into authentication and authorization. He then demos how Azure API Management is the solution to many FAQs from API developers.
Integrate 2018, June 4-6, etc.venues, London
Good morning everybody. So, continuing the second day sessions, we have Vladimir Vinogradsky and Miao Jiang from the API Management team to talk about the deep dive into API management. So, to introduce myself, I’m Sriram Hariharan. I joined BizTalk360 four years ago and this is the second time I’m attending this event. I take care of the marketing at Document360 which is a new product. So if you want to know more about Document360, we have our booth here and I’ll be happy to talk to you about that.
So, to introduce Vladimir, so Vladimir is from the pro-integration team and he works in the API Management team. Vlad, he has more than 20 years of experience working in the software industry as a developer, software architect, a technology evangelist and, finally, now in Microsoft as a program manager. To introduce Miao, Miao has been introduced yesterday in one of these sessions. Miao also works as a program manager on the Microsoft Azure API Management team at Microsoft. So, ladies and gentlemen, please welcome, Vladimir and Miao. Thank you.
Vladimir: Thank you. Good morning. You guys can hear me okay? So, yesterday, Miao did the session, overview session on API management. He did a little poll about usage and familiarity with API management and we were quite impressed with the numbers. It felt like, you know, three quarters’ already aware of API management and about half are using API management which is great to see. And it’s, you know, marked difference from what we saw two years ago when we first presented at this conference.
But with such mixed audience, it’s always difficult to set the proper level of depth. So the presentation that I’m going to do probably will expand the knowledge of people who already have hands-on experience with API management and maybe we’ll demonstrate to people who are not using API management a little bit of capabilities that we have, and suggest some ways that you might use it. So, hopefully, you’ll find it informative no matter what your level of experience with API management is.
There’s going to be a lot of demos. I’m going to go really fast because we don’t have a lot of time. So, I hope you will enjoy it. So we’re going to cover just three things, right. Two of them are related to security, for obvious reasons, and let me just flip it. So we’re going to cover just three things. Two of them are related to security, for obvious reasons. Security is extremely important, but also get a lot of questions about it. And, more importantly, it’s actually one of the core reasons why customers choose to use API management for the APIs.
And then the last one deals with deployment automation. Again, a topic that we hear very often from customers, and community [SP] did a great job of stepping in and supplying sort of solutions and proposing approaches. And we’re working sort of looking at those and coming up with sort of a guidance that coalesces all these different approaches and, hopefully, we can share it with you today.
So from the security perspective, you know, you guys know that API management has all these three components and all of them need to be secured and we have two sort of participating roles, API publishers who are really customers of Microsoft Azure API management, and then you have developers who are actually customers of our customers. And those developers write applications and those applications have users, right. And those users may be actually customers of publishers or developers, depending upon what kind of situation it is. You know, if app developers are employees, then potentially this will be also customers of our customers. But, potentially, if this is a sort of a public API and if app developers write applications using public APIs, then it’s their customers actually.
So there’s like a lot of different moving parts. So we’re not going to talk about the publisher security because it’s sort of provided by Azure and you guys are very familiar with that. We’re going to focus on the first two, and when I talk about developer portal authentication, that’s obviously the top one. And then the second one is data plan security. There’s both sides there and it really deals with API security end to end. And we’re going to start with developer portal security, so developer authentication.
So let me set the stage a little bit to explain why you need to authenticate in fact. I mean, it’s obvious but also there is sort of underlying reason for this. I don’t know if you guy’s aware, but API management has this concept of users who are sort of developers who come to the developer portal. Those, you know, belong to one or more groups and those groups can be given visibility or access to API products, to one or more API products. And those products really are just combinations of APIs.
And so if you look at the groups who have built-in groups, and any user who comes to the portals automatically classify in one or more of those, you know, admins are the users who single sign-on from the Azure portal. That’s the only way to get into that group. Unauthenticated users are guests, and everybody else is developers. So it’s very simple system. And then you can define your custom groups in, you know, arbitrary, or use groups, for example, from Azure AD which I’m going to demonstrate.
Products are normally, by default, require subscriptions. To be a subscriber, you need to have an identity with the system, so you need to authenticate. So if you have an identity or an account with API Management, then you can create a subscription. And that subscription has two keys which are completely equivalent. You can use any of them. And the reason we provide two is so we can implement key rotation. But other than that, they are absolutely equivalent.
Now, you don’t always have to have subscriptions. There is a concept of an open product, what we call…or product not requiring subscription. And in that case, we can actually use APIs within that product without having any keys or subscriptions to it, and I’m going to show you that as well. So in terms of what sort of authentication capabilities we offer. Any tier of API Management has those, right? So those are essentially username and password, old and trusty. And then there’s intranet identity provider federations with a bunch of sort of top tier providers.
And then for authentication against custom authentication mechanisms that don’t fall into any of these categories, we offer a feature which we call delegation which essentially is sort of redirect single sign-on kind of feature which allows you to essentially plug in any sort of mechanism for authentication. You know, if you have a user database somewhere, etc., that’s what you’re going to use.
Now, if you go to standard or premium, you’re going to get those two options and those are very interesting. Obviously, Azure AD actually enable, you know, a totally different set of scenarios. It allows you to actually start authenticating your employees or your partners, and you can do it either by essentially allowing access to API management for multiple tenants. Some of them may be yours, some of them maybe belong to your partners or customers. But also you can do, you know, guest accounts, a new feature in Azure Active Directory where you can actually create guest accounts for your sort of partner ecosystem in your own tenant. And we support that as well.
And then Azure AD, it essentially subsumes everything else we have before, right? So it has federation with all these other IdPs that we have already. It supports username, password. It has great ability for you to manage users, impose policies, create custom sign-in screens, etc. So it’s a very sophisticated tool as well.
They have this ability to federate with arbitrary OAuth providers where you can actually plug in some of the sort of other top tier providers of identity in the enterprise such as Ping Identity, etc., and therefore it can be kind of, you know, one-stop shop for all your authentication needs.
So with that, let’s go and see a demo. Okay. So here, they have an Active Directory that I created. It’s a very, you know, sort of standard Active Directory. I have a couple of users here, Jane and John. So Jane is a developer and she sort of works for IT. And John is in accounting and he works for finance. And I’ve got a group here, this single group that I created, which is called app developers. And, naturally, the only user out of those two in that group is Jane.
And you see we have one user and if you look at the members, we have Jane as a member. So a very simple set up. So now, if we go and switch to API Management tenant info that I will switch to my usual login directory, here we go. Let me just go to…it throws me to the Dog Food portal and I don’t want to do that. Here we go. So here, we have a new API management instance right there.
So if you look at identity configuration here, you will see that I have Active Directory. And if you click on this guy, you see that this is my directory I just showed you, right. So I made that association and the only users who are able to log in into my API Management instance as developers are users who have access or who have account in this Active Directory. So now I have a few products here, API products, and they include different APIs. But if you look at access control, you’ll see that only, you know, Platinum product is available only to app developers group in addition to administrators, right.
So only users who belong to my employee Active Directory group app developers are able to see that product. The rest are accessible to developers and guests, and as we know, since John is not part of app developers but he has ability to log in in API management, he’ll be classified as a developer. And then, of course, anybody without credentials will be classified as guest. And they both will see starter and trial products.
Now, the difference is the trial product is actually open product, right. It doesn’t require subscription so APIs within that can be called directly by anyone. And for that, obviously, you know, it seems like a scary thing to do but sometimes, for trials, it’s okay especially if you can set some consumption limits on it or some throttling. And that may be a good way for people to try it without a hassle of creating an account.
So any case, that’s the situation here. So now let’s go to the portal here and try to sign in as different identities and see what the result is going to be. So I’m going to go in and sign in first as Jane. So I am authenticating against my AD account, signing in, and Jane has full access. Jane will see all products including Ultimate [SP] and we can verify that by going to Products and see that…I’m sorry, Platinum, and we can see that, you know, she has access to that, all the APIs in that product. So everything is as we expect.
Now if we sign as John, so we’re not going to see Platinum, right, but we’re going to see all the other products, you know, like starter and trial. Trial is not shown because it doesn’t really require subscription so there’s no reason to show it as a product because there’s no subscription sort of gesture you can do in it. But it’s there. So here, hopefully I typed it correctly. We’re going as John, right, and if we go to Products, you can see that Platinum is not there.
So what I did is, you know, I enabled Active Directory accounts log in into developer portal without sort of hassle of creating new accounts and usernames and passwords and stuff like that. So that’s great. The other thing I was able to do is actually partition access to my APIs based on your roles or groups within Active Directory which is pretty cool. Now, if I go and actually sign out completely and remain a guest, right, so at this point, I’m just anonymous user on the portal, in theory, I should not see Platinum but I will see a starter.
Now, if you go on API and, you know, starter actually has [inaudible 00:12:46] being the local weather. Numbers API is completely open. I can demonstrate that by going to Numbers API. And as you can see, if I go to try it, that’s something that I can certainly do. And I can make a call and get a response and get some interesting math facts right there. And then I can call again but, you know, this product is severely throttled, right, to avoid people sort of spamming you with access and sort of denial of service attacks.
So it allows you only very limited access but you can certainly try it without having any accounts. However, if I go into a starter product, right, and you can see that these three APIs are there, and if I go to one of these APIs and try to call it… And this was glitchy this morning, for some reason. Let me just do it again. So what you should be greeted with… Oh, sorry. If you go to try it, right, you will see, hopefully… Let’s do it again. Yeah, there is something going on, maybe it’s a browser thing. So you will be prompted with a prompt to subscribe to that product.
Then if you go to subscribe it, it will say, you know, now you need to actually create an account. And, of course, since you don’t have account in Active Directory, no luck. You can’t log in and you can’t get access. Now, unfortunately, the warning sign is not showing but you can see that I don’t have subscription. You see that there’s a little red mark there, and there is no way for me to obtain one without actually signing in. So that’s sort of authentication piece, developer authentication piece. So go back to the slides.
So let’s just summarize a few sort of things that we already discussed. AD is great for business to employee, obviously, but also great for business to business, right? So, again, you can associate more than one tenant with API Management. So you can actually give partner Active Directory tenants direct access to API management, or you can create guest accounts in yours and do it that way. And for those kind of situations, we have recently released a feature where you can designate a login directory, login tenant, specifically for those guest accounts.
B2C actually is great for everything, right? So, essentially, if you are doing B2C or Vista, you know, as the name suggests, it’s, you know, right there. But also for if you want to just use username, password or do identity federation with sort of OAuth providers out there that are not supported directly, Azure AD B2Cc is the way to go. Delegation feature is great for customers and that’s your escape hatch if there is no…you know, if you have something custom going on, some legacy thing or you want to just do a single sign-on between your developer portal that already exists in ours, that’s a great way to do it.
We have this wonderful option, which I didn’t show you but it’s there, that allows you to essentially redirect all guests to sign in. So, essentially, whenever, you know, an unauthenticated user comes to the portal, they’ll be immediately thrown in to Sign in dialog box without seeing any content on the portal whatsoever. And one thing you probably noticed in the subscription model, I know some of the customers in the audience actually expressed interest in more flexible subscription models, where you don’t necessarily have people owning subscriptions but rather wanted groups owning subscriptions or creating guest account in abstract, we are working actually on changing that, making subscription model more flexible. So if you guys have any feedback, please find us and we’d love to take it.
Let’s go to data plan security and talk about that. So, again, gateway sits in between. It receives a request, does something to it. You know, in this case we’re going to be talking about authorization, but potentially we can do cache and transformation and other things, and then it forwards it on to the backend. So you need to secure both sides, right, so that’s an important thing.
So what do we have for you in a store to do this? Keys. Keys, as you saw, enabled automatically, simple to use, simple to start with. We’ll also support OAuth2 and OpenID Connect through JWT token validation. And we’re going to extensively talk about that and I’ll do some demos around this. We also support client certificate authentication. We’re actually, you know, beefing up our support for client cert authentication but it’s a great way to, you know…it’s a very strong sort of authentication mechanism if you want to authenticate applications or specific devices.
We support IP filtering. We have, you know, fairly flexible policy that can be set dynamically obviously. It allows you to essentially enable access to a single or a set of IP address or, on the contrary, block access to a single or a bunch of IP addresses. And that can be useful, for example, there’s a noisy IP that, you know, for some reason sort of, you know, pinging you all the time, so you can kind of block it out very easily with that policy.
We’ll also support actually any authentication mechanism that is not supported directly but that can be externalized in HTTP endpoint. And I’m going to show you example of that actually. It’s very valuable capability. We pour into it, you know, a lot essentially when we, you know, responding to RFPs or talking to customers. But here, I’m actually going to demonstrate how it works.
And then, of course, don’t forget [inaudible 00:17:52] importance there, really, you know, a very nice protection mechanism and I’ll show how it actually works very well with this guest access, right. You know, you can’t really grant guest access without using protection through rate limits and quotas. On the other side, we have direct support for HTTP basic, mutual certificate authentication. You know, shared secrets. Something like key is very easy to use, obviously.
IP filtering there actually refers to the fact that on the side of the backends, you can actually provide exclusive access to an IP address of the API management instance itself, right. In that way, you will ensure that nobody else can sort of run around and call your APIs directly. And then, of course, you can actually use virtual networking capabilities in Azure to do some interesting stuff and further secure access to your backends and make sure that gateway is always in the way of every request coming in.
So let’s talk about some frequently asked questions that come up time and time again. So what do you guys think? Which one is better? You can just, you know shout out any opinions there. Token? Okay. I would say it depends, right. That’s the best answer a security professional can give, right? And, in general, in software development, right, that always depends. So, you know, this is just to show, right. They’re different, right.
So key is extremely simple. Both have bearer tokens, right, so whoever has either the token or the key can call the API. They actually have different properties in terms of how you validate them. They can be used to authenticate different subjects. There is no way to actually authenticate a particular user with a key, right? So if you need that, obviously, key is not a great way to do it.
JWT, on the other hand, has a very robust credential. It has very good protection mechanisms for mitigating some of the common attacks, like for instance, replay attack, right. But also it’s harder to use and it requires, you know, additional setup. So keys are nice to start with, right, but in certain, you know, scenarios, you know, JWT and OpenID Connect or OAuth are actually the right way to do it.
You know, the other thing is actually what situation you’re in. If you’re providing a sort of generic horizontal data, weather, you know, sports scores, things like that, right, data that is not sensitive, data that is meant to be shared. Especially since if you give a key, you know, in exchange for some consideration to your developers, right, essentially, it’s on them to keep this key secure. If someone steals this key, you’re not exposed really, right? They will be taking it out of their quota. And, of course, you can mitigate that problem with them on a one-off basis as just resetting this quota for them as someone stole their key and they just discovered.
So in those situations, key is perfectly fine approach and it’s simple and it works really well. However, if I’m accessing my, you know, my data from my health provider, it’s better not be key. It’s better be something that is strong that authenticates me and not necessarily, you know, a developer. So, again, it depends. So now, can I disable keys? And you guys should already know the answer to this question. So what is it?
Vladimir: Yes, exactly, by using basically products that don’t require subscription. That’s very easy to do. There’s only one limitation with that. Well, actually two. One limitation is that when you use open product, you can have one API in only one open product. Otherwise, you can have actually API in any number of products but only one single open product. That way we can apply scopes for policies correctly.
And the other thing that you’re going to lose tracking of who developer is, so you lose a little bit of metadata. That’s not a big deal. You can sort of mitigate that but, you know, that’s just something to keep in mind. Often asked question is we already use keys, can we use them with you when we migrate to API management? Put API management in between, can we use the keys we already have? And the answer is yes, you can because you can actually create subscriptions for the, you know, application developers or whatever sort of, you know, your subscription notion is.
And then you can actually explicitly set the keys for those. The keys that we generate are I think 256 bits but I think that we allow like 2048 bits. So you can actually make keys longer if you want more security or you can set arbitrary keys that make sense to you if you already have. So that’s fairly flexible. Is it safe to use the API management IP in firewall rules to control access to my backends?
And the answer is yes, but it’s conditional. So that IP will change if you join or leave virtual networks. So you need to sort of understand that. The other thing when it’s going to change is if you delete or suspend your service. When you recreate it or unsuspend it, it may not necessarily have the same IP address it had before. Barring that, yes, IP address is stable and you can definitely use it.
And then last one, how do I ensure exclusive access to backend APIs from APIM? And unfortunately, there’s no magic and you have to use one or more of those and we suggest more, obviously. You can use authentication between us and backend that is exclusive. You can use IP filtering on your backend but that’s sort of fairly easy to defeat. And then you can use private networking. And speaking of that, we have actually great support for private networking with sort of ability to join virtual networks in Azure.
So now there is a few things to understand here. First of all, we require dedicated subnet that is totally sort of dedicated to API management instance. It has to have enough IP addresses. Not just for us to join but for us to scale, so you need to allocate proper number of IP addresses. This is all described in documentation. There’s a link on the slide but, you know, these things to keep in mind. The other thing is that we are sitting in your virtual network. You control the security groups and sort of all the routing rules within your network.
So you can easily deprive us from access to the dependent [SP] resources or access that we need to control the service. So there’s certain configuration that needs to be there for us to operate correctly. And we have a lot of support calls where people kind of, you know, don’t neglect to do this or by mistake sort of set their rules in such a way that prevent us from operating correctly.
So that’s a little bit of a hassle. We’re working on sort of removing that particular problem, but it’s going to take us probably a few months to do it. So in the meantime, please keep in mind that we have these dependents. You have to respect the rules that we need. We have complaints that some of them are unnecessarily broad in sort of your opinion and we agree and we’re again working on mitigating and narrowing down the set of sort of open channels that we need to operate correctly within your virtual network.
Of course, here, you can basically do, you know, wonderful things. Your backends can be completely private, accessible only to API management. You can set network security groups to do that and API management exposes all external endpoints. We control DNS routing and everything else. So from that perspective, it’s sort of a fairly easy setup. We also support internal configuration. The idea here is that you can call API management endpoints internal only, so coming only from within the VNET or from on-prem.
There is no external access so that’s useful, but what’s more useful and what people do most often is this. They actually put firewall in front of us and therefore there is sort of a layer defense here. First, you know, the request hits application gateway firewall, and then it goes to API management, then it goes to basically one of the backends, etc. It’s the most involved configuration test set up and it has some glitches [SP] which I’m going to tell you in a few minutes.
Here, I am in API Management. I’m going to be using this single API here, httpbin. So right now as you can see, in inbound, there is no policies. There’s just, you know, policies getting inherited from a larger scope. We don’t worry about those. So this API actually maps to this little website. If you guys don’t know about it, you should learn it. It’s a wonderful tool. It allows you to actually test APIs and they have lots and lots of different methods for testing different things with APIs and API clients.
So it’s a really, really great API and I’m going to be using it here because, you know, I’m going to be using some of the endpoints that basically reflect back the request payload so we can see what’s going on.
The other thing I’m going to be using here is this wonderful website. It’s run by OAuth 0, and it allows you to basically generate JWT tokens. So we’re going to be generating JWT tokens on the fly and sticking them into requests and sending requests and seeing what happens. The way I’m going to do it in the interest of time and still, you know, fiddling with the UI, I’m going to be doing it all programmatically using our management APIs. So I’m going to be setting policies using an API and here is the operation that I’m going to be using.
As you can see, this is a PUT and I’m doing it on httpbin.org API. And I’m setting policy there and I’m supplying policy in line. And then the top two requests right here, these actually will call the API that I saved the policy on. And I’m going to show you first time how this all works and then, of course, at the top there, there’s a JWT token that will be substituting through a variable into this calls as you can see.
So with that, let’s start. So if you look at the validate JWT policy as a whole, it’s a pretty involved policy there. So first of all, you can supply header name. You can supply sort of failed HTTP code and, you know, error message. Those are all optional parameters. You can require expiration time or not. You can require, you know, scheme or not. You can require that the token is signed or not. And usually, you know, all of those default to True [SP] because that’s actually the right way to do it.
You know, clock skew, essentially, you can allow a little bit of a clock skew between the server and the client. You can, instead of providing subscription key in line through the issue assigning key element there, you can actually specify a metadata endpoint which we will query to get the key. And we will query periodically, and so if you rotate the keys, we’ll pick them up. So that’s normally how you do it and you do it definitely like that with something like Azure Active Directory. But you can also stick them inside as Base64 encoded key and it can be either, you know, a cert or it can be just a symmetric key like in our case.
And then you can go and validate certain registered claims such as audience and issuers. And then we have this required claim block which allow you to basically validate the rest of the registered claims as well as public claims and custom claims, you know, and also match the values, right. We have this ability to match all or any values for the claim if it’s a multi valued claim.
So it’s kind of, you know, pretty sophisticated policy but we’re going to start very simple. So we’re going to start with this policy which basically checks for two things: is there a token and is it signed? And, of course, we require expiration to be present, and that’s pretty much all. We really don’t care what’s inside the token as long as it comes from the right trusted authority. We should be able to call the API.
So here I’m going to make a call first. So first of all, let’s check if there is a policy there. Not found. There is no policy in fact. I thought I actually showed you that. There is nothing here. So here, first we’re going to go and just call this method to set the policy created. You see the response. So the policy should be set. So if we go back here and refresh, here it is. So it’s there, set. I’m not going to do this flip anymore to sort of minimize time.
So at this point, essentially what we’re going to do is we’re actually now validating tokens. So if I don’t provide the authorization header with the token, there’s going to be a problem, which is, right. So this is good. So we’re actually expecting the token and we need to validate it. So now let’s [inaudible 00:30:03] this and let’s go get us some token that we can call with. So two things must be present. Issuer, always, and expiration we require by just way of configuring the policy today.
So this is, you know, you can see it sort of dynamically generates this token here, so I can grab it. And the signing key I supplied there on the, you know, in Verify Signature block here is exactly the one that I’m substituting within the policy. So now, let’s drop it in, okay, and make a call and see what happens. Seems like we’re going through and you can see through the reflected response, right, that, you know, you see the token is getting passed and it seems like it’s working fine. That’s great.
So now, we can progressively tighten up this policy and validate more and more things. So for instance, in this case, what we’re basically saying, we’re saying, “You know what? We should actually require bearer in the token.” So right now we’re just posting it clean. So let’s require that. So let’s drop it in here, configure it. Now, as you can see there is no bearer in the token, so if I call now, you will see, it’s going to work. So it takes a little bit of time for the gateways, you know, it’s a distributed system, to pick up the policy change. So now it did.
And now, since we don’t actually have a properly formed token, it basically denies us access. So now, that actually should work and it does. So, okay, now we’re actually requiring there in the token. That’s great. That’s progress. So let’s go and now ask for issuer as well. So you see we added issuer claim as well, so we want that. So let’s go put it in. And tell me what do you think? Is it going to work if I’m going to call right now with the token that I have? No? Why?
Participant: [Inaudible 00:32:21].
Vladimir: Well, it is pleasant but it’s different, right. So it’s JWT IO versus FOO. So in this case, let’s make a call and it’s not going through and we’re going to just call a few times. You see I’m doing this a few times just to make sure that policy is propagated. So that’s great. So at this point, we should go and maybe change it to the right one and make sure it works. Okay, set that, hopefully it’s propagated now or it is propagating. Come on. Yep, working.
So that’s great. So what else can we do here? Well, we can also do the audience. Audience is kind of important. It prevents sort of the token redirect attacks where essentially you take token that’s targeted at this API and use it with that API. So for that, we can actually require audience and I am basically saying that the audience should be equal to the hostname of API management instance. So all API is, you know, I’m kind of waving my hands around there but it’s easy enough.
So let’s go and stick that in over here and that is not… I will tell you a secret. This is not on our token so that should not work. Now let’s go and test that. Okay, that’s lovely. So, at this point we can add this audience in and this claim is abbreviated like that. And we can actually type in the host name of my API management instance here, grab this token. And as soon as we paste it, we should be in good shape. And we are. And we can go on, you know, and do other things here and I have a few other things you can do. For instance, you can actually, you know, add groups now. So I edit the custom claim groups.
And at that point, you see like over here, the only thing that I actually want is that claim to be present. I’m saying I don’t care what the values are. As long as it’s there, I’m good. That’s probably not the best thing so you probably want to say, “Oh, in fact, my groups are finance and logistics and if it’s one of those, I’m good. I don’t care which one.” But, you know, I might care actually and this is what you can do sort of on top of just doing sort of plain validation of tokens.
You can actually go and do something like this where I’m doing conditional flow policy below here. And as you can see, I’m looking at the method, you know, that it is @POST. And then I am actually diving into this token essentially. As you can see, this JWT method allows me to sort of untag the token as JWT and then use sort of claims [inaudible 00:35:41] to get into some properties and find out if the group is finance.
So if @POST in Finance, then it’s okay. If not, it’s forbidden. So, essentially, @POST operations will be allowed only to customers who have Finance as a group. So if a request has this group, then it’s going to work. And just, you know, we’re going to skip the rest. I’m going to just go with this one and see it’s working. It’s pretty cool. Here we go. So let’s set it in. It’s there, so it’s propagating right now.
So what we need to do, we shouldn’t forget, we should add that group. And for now, we’re going to put group name as “foo,” which means that we should be able to call only @GET method but not @POST method. So let’s copy this token here, right, and make a call. Well, frankly, hold on. It’s probably didn’t propagate yet. Well, it shouldn’t work on @GET. Oh yes, that’s right. You’re absolutely right. It’s too early in the morning.
So, basically, if I say logistics, then it’s going to let me do my @GET but it shouldn’t allow me to do my @POST, which it doesn’t. And I’m not going to, you know, show you that Finance actually works but it does, trust me on that. So that’s sort of validate JWT. Validate JWT is very powerful and you can use it in very flexible ways. It’s a great way to pre-authorize your request before forwarding them on to the backend.
One thing to keep in mind when we do that, the token actually, you know, goes to the backend. That’s actually always happening, keys, tokens, everything that you actually do not explicitly remove from the request will go to the backend. So you have complete option to actually go and do extra validations on the backend or you can unpack that token and supply that information some other ways like through header to decouple your backend from the authentication mechanism that is used currently which is JWT.
So you have lots of options there but keep in mind that sort of all of these options are open to you. So let me talk about custom authorizer for a moment. It looks like a big and scary policy but it’s not. So let me just walk you through this. It does very simple things. So, first of all, it goes in… So the idea here is very simple. I don’t know how to authenticate this request because I don’t support, you know, in API Management, that authentication mechanism natively. So what I’m going to do is I’m going to implement the authorization, actually an external authorizer. In this case it’s a function. And that function is very simple.
When authorization header value is 1, it says it’s okay. When it’s anything than 1, it says, “I can’t allow it.” But you can imagine it could be SAML validator or basic authentication thing that checks credentials against database, etc. So, in this case, actually what I need to do, first, I say, is there an authorization here? If it’s not, you know, I basically challenge them to authenticate.
Second thing is I’m going to basically do a cache check. I’m saying, have I already seen this authorization header value? And if so, what was the authorizer’s answer for that? And if I have it in cache, I just serve it from cache. I don’t call authorizer and, in this case, I store it only for five seconds but, you know, your mileage may vary based on your sort of situation. You can choose different time outs. Now, then if it’s not actually in cache, I have to invoke, and this is this Send Request policy, right, that basically makes a call, gets the response, phishes out the status code, and if it’s 200 [SP], mean it’s okay. For 3, it’s not. And then basically caches the result.
And I also added a little tracing here for us to see if the value is actually served from cache versus directly from the authorizer just to see the latency difference in there. So it’s a very simple policy, does very simple things. And this is where I’m going to set it. Again, I’m setting it exactly on the same API, everything is the same. So let me just put it there and it should be there at this point.
So let’s, first of all, send request without authorization header. So I should receive a prompt to authorize. And, yes, I’m receiving for 1 and there is authenticate header there saying, “You have to authenticate.” So in that case, let’s go and send value 10 which we know is no good because only one works for this very secure API. And, you know, at that point the policy… Whoops. So authorization header equals 10. Okay, here we go. Forbidden.
What you witnessed, you know, this little delay was a cold start of the function. So now you know there’s really something is happening there. So to show you more about that, let me go and do this. So, first call with 1. You see that log entry there says “Authorization refreshed” and we have 650 millisecond response. Now, a bunch of it is because I’m in London and this thing is in West U.S., but, you know it’s still pretty high value there and we know we are caching them for, you know, five seconds.
So now I’m going to actually make more calls and you’re going to see what’s going on. So, again, refreshed from cache and look at the latency. Latency dropped dramatically. Now, looking at the latency, just looking at it, don’t get your head down, you will be able to actually see or at least guess very well if it’s served from cache versus the function that I need to call a function for that. So, again, very simple way to do custom authentication there.
So key-based is simple, great. SecurityProperties, I would say it’s similar to basic authentication. Both are secrets. Both are passed on the wire. OAuth and OIDC are fantastic for end-user authentication. That’s industry standard, just use that and validate JWT. It just works awesome with that out of the box. Client certs are, you know, very strong authentication mechanism obviously for apps and devices. External authorizers, you saw, it’s really very easy to use. I’m going to put this policy in our samples. You can grab it and essentially all you need to do is just change the value of this, a little name value that I have for the URL and it will work for you too, whatever your authorization mechanism is.
Note that all these credentials require HTTPS and rely on HTTPS for defense from replay attacks. So you need to disable all legacy HTTPS protocol. So we have SSL settings and you need to go there and if you have an old instance, it has actually a bunch of legacy TLS options available to you. So I suggest you flip them off if you can, if you don’t have legacy clients. That’s a great way to ensure that your HTTPS channels are sort of top-notch and most secure.
Don’t forget to secure the right site. A lot of people forget that when they secure sort of the incoming request side, when before that path needs to be secured as well and we discussed what you do there. And then, you know, WAF is a great way to sort of add extra security to your APIs. But keep in mind one thing, WAF can sometimes produce false positives. Be prepared for that. So when sometimes your calls fail for unknown reasons where they are very legitimate, well, I mean, that’s sort of what WAF does.
It sort of blocks things and sometimes it does block things that actually are valid. So that’s something to keep in mind and not be surprised by. Last, and I’m going to take just a few minutes and I’m going to skip my demo and I’ll tell you why it’s okay, about the DevOps.
So this is essentially the context of that is would have multiple development environments, multiple teams. Some of these environments are shared, you know, production is one of them. Now, I have this problem of multiple teams building, you know, and evolving the APIs and they need to deploy into this one shared thing in such a way they don’t step on each other and don’t disrupt their customers. So that’s the common problem. And the sort of the constraints we’re struggling with, there is a great variety of difference sort of two chains, source control options, you know, engineering cultures, organizational structures that we have to have a solution for.
Therefore, sort of our approach is to do it as an open source project on GitHub that we’re going to share a link to. It’s kind of bare-bones right now. We’re going to, you know, evolve it very quickly hopefully with your feedback, and it’s again welcome and we’re soliciting it. So come talk to us. There’s a lot of great work done by community. I’m not going to, you know, call them out right now, not embarrass them, but we really appreciate sort of all department, community input into that.
And to see some of these great publications that they did on these kind of subjects, just go to our Twitter and just look out at our retweets and likes and you’ll see like lots and lots of good stuff there. So we coalesce around this approach. So in this case, we just consider production and development environments but it can have, you know, any number of environments in between. In this case, we basically say that, you know, production environment is owned by API publishers, you know, the central team that manages that environment. And then developers have their own little individual developer instances.
And, essentially, obviously, the great way to deploy in Azure is using ARM templates and PowerShell. That’s just, you know, the way we do it. So, you know, templates is where it’s at. You know, it’s not perfect but it’s great and it’s consistent across Azure. So what we advise essentially is modularizing your templates, right. So have templates for APIs, each individual API, you know, per template.
You can have them, you know, going on further and say, you know, “I’m going to create templates for separate products in that with or separate other instances, one per service where you have service level settings, you know, networking setting, certificates, you know, scale, tier, those kind of things.” So you can basically break it up. Why? You know, Azure ARM deals better with smaller templates. B, it allows much better sort of parallelization of work on these templates for your developers. C, you can essentially choose to deploy exactly the things that change and not everything…and then sort of save the time on deployment as well.
So modularizing is a great way to do it and we’re going to give you, you know, a good starting point there. Now, obviously, these guys actually deal with different kind of artifacts. They deal with API definitions in open API. They deal with policy files and it’s great because those are lightweight, not very verbose and to the point. And, you know, obviously, would love everybody to know, you know, ARM template schema but it’s probably not realistic. And so it’s perfectly fine to work with these artifacts.
The other thing is that there is a lot of tools, community builds, open-source community builds around API definitions, you know, that involves generators, various sorts of checkers, validators, etc., and it’s great to be able to use all of them.
Now, the question is how do you bridge this divide? You know, the case sort of we’re proposing, we’re using GitHub for this, obviously, you know. It’s very simple. You just fork the repository and essentially then you have to somehow take those artifacts the developers work with and generate the template out of it. And that’s a piece that we’re actually working on and we’ll be providing as an open source. And then, you know, when you’re done, you can sort of test it on your development instance and then provide a pull request to the central team which, importantly, can be validated.
You can actually validate the changes that made. First of all, were the changes made only to the files that are non-sensitive? For example, if it’s just an API file, it’s fine. You know, [inaudible 00:48:09] central team, API is a responsibility of someone else. But, of course, if they’re starting to change configuration of the shared entities, right, then you might have a question of that and you can either deny it or you have to have manual review for example. So there’s a lot of flexibility there.
The other thing you can also enforce is some sort of company-wide standards on what the APIs must look like and, you know, all things of that nature. And, of course, you know, if everything goes well, you can edit [SP] or manually merge those changes based again on your validation results and then deploy them either on schedule or on request.
So I would have shown you demo of this but, you know, that would be an exact like on the slide and we’re going to record a video of that hopefully this week and post it in this repo so you can go in and check it out. And that’s a repo to join and sort of, you know, work with us on that approach. So to summarize, use separate service instance for environments. Developer tier is exactly meant for that. It’s inexpensive and it’s great. You know, any team can have one. They can use it, delete it etc.
Use [inaudible 00:49:10] templates for deployment automation. There’s many benefits of that. Augment with PowerShell or Azure CLI which we don’t yet have but will, you know, as necessary. Get a repository or, you know, use a scripting approach today and if it works for you, there’s no reason to change anything, right. This is not something that you must do. It’s another option for you and if you’re starting from fresh, hopefully you’ll find that useful and will start from that basis.
And then, of course, there’s no single approach that works for everyone so we fully expect to provide just a starting point that people will go and customize. And as I already said, we’re looking for feedback and contributions and, you know, obviously please find us, talk to us, send us email, tweet at us, etc. Some of the resource is similar [inaudible 00:49:49] deck and thank you very much for your attention.
Fill the form below to get all the presentations delivered as a single zip file in your mailbox.
byJon Fancey & Matt Farmer
byMicrosoft Integration Team
Back to Top