Securing Web API with Azure AD (ASP.NET Identity)

0
5


[Music] In this topic, we are going to talk about
securing Web API with Azure Active Directory. We have some other modules specifically on
Azure Active Directory, but we are going to apply it to a scenario here and talk about
how security applies to Web API and some of the complexities that are involved with that.
It is not quite as straightforward as you know clicking a check box or turning something
on in the platform. And so I am going to walk through a scenario here of typical application
that we run into and how we are able to leverage Azure Active Directory to provide authentication
services for the app, but then also allow the Web API tier to be split. So we’re
talking about scalable applications and being able to keep our different layers at the application
separate, that brings in some complexity especially with authentication. If we do not have domain join membership,
which we typically do not in PaaS type systems, then we need to have some other mechanism
to synchronize our identities and make sure that everything can authenticate and we can
have trusted clients that we are talking to. So in this scenario, we are going to talk
about a web app. So in this case, we will have a front-end here and I will just put
FE here and this will be a web app. We can actually say this is a spot-type application
or heavy JavaScript type application and then in the back-end we actually, and we will call
this BE, this is our back-end and this will be Web API. Now both of these are ASP.NET
applications. This one is heavy. The front-end is heavily JavaScript and the back-end is
heavily MVC or Web API in this case that we are talking about, and then obviously we would
have a datastore over here. We will just call it SQL for the argument sake that the Web
API will communicate with. Now our users are coming in to the front-end application over
here and these users need to access this app and maybe this app is locked down. So we do
not want to just everybody in the world to hit this, but remember these are public endpoints
that are exposed here. So this thing is exposed to the public Internet. Unless we have ACLs
in place, anybody can access it. But if we were able to leverage something like OWIN,
so we have an OWIN framework that helps us abstract the ways some of the intricacies
of the identity system. And what this allows us to do is basically define a relationship
between our Azure AD down here and our application. So we define our application down here and
this is basically metadata about this guy, and so when we define that metadata down here
in the Azure AD, there is a key that is involved. Again, this is on server side and then we
have a key involved in our application again on the server side and that key will allow
these two to communicate, basically OWIN working through that. So when the application fires
up, it will use OWIN to initiate and initialize all this glue that kind of glues our Active
Directory to there and then it becomes easy in our application to say whether this person
is authorized. There is literally a property inside our application that says whether this
request is authorized. If it is not, we will have to go get a token and when we go get
a token that is defined through our OWIN configuration here. So in our OWIN configuration, this will
essentially redirect this application to a default screen that basically asks them for
the username and their password and this resides in Azure. So this is the Azure AD login. If
anybody has used Office 365, this is the same login screen that you are going to see there.
Now, we can customize it for our apps and put the app name and that kind of stuff in
there, but we are going to ask them for what is your username, which typically is their
UPN or their email and what happens is once we have that, we can ask Azure Active Directory
behind the scenes, hey! Is this a federated user or a cloud user? When I say cloud user,
I mean someone who does not have an on-premises connectivity to Azure, which basically would
be like if we had Azure Active Directory over here and we had a synchronization running
there with DirSync or Azure Active Directory Sync. If we do not have that, he is going
to say that is a cloud user and we are going to prompt them for their password here. So
they would enter the password. Whether it was right password or not, then they get into
the application. If they were a federated user, so let us say we had the synchronization
running here, when they type in their UPN, it is going to say, oh! they are federated
user and it is going to redirect them back over here to on-premises, they’ll get a
authentication request to make sure that they can authenticate, it will come back to Azure
Active Directory with either a yes or no, and at that point a token will be generated
or not for the web app. Now this works all fine and everything is
pretty easy to configure here. Very small amount of code that has to be added for OWIN.
We do some configuration I mentioned over here on this side in Azure. This is all Azure
configuration, but then we start sprinkling in the Web API. Now, the Web API is a way
for us to get data. So we logged into the app over here, but then this guy is going
to make REST calls over to this Web API letter. Now that Web API has methods there and we
can decorate those with the authorize attribute, which also integrates with OWIN. So this Web
API has a configuration with OWIN as well. So in this model, what can happen is once
we get the authentication token over here from our initial login, we can actually pass
that every time that we come over here to Web API, and say here is my token, this guarantees
I am allowed to access that data. Now because he has this relationship defined
here, he can actually check on that request and say, hang on a second, let me check that
out and make sure that is clear. So he will check and make sure that that token is actually
valid and if it is valid, he will let them have access to that data. So in this model,
we can have a two-tier application because we have our UI here and we have our service
layer here and in this model, we can actually have the token actually being passed between
those different layers. So kind of a hard thing to do when we did not have some of these
nice features like Azure Active Directory and OWIN.>>So I imagine that I could also tie
in with this something like a two-form factor like Azure MFA?>>Sure, yea and it also supports
third-party, so we do not have to necessarily use AD FS. If they want to use something like
a third-party RDP, we can actually plug that into the system too if so.>>In fact, I can
show you what that kind of looks like here. So on my screen, I have fired up in my Azure
subscription, I had created an ACS namespace. So one thing you need to be aware of is this
is kind of the current state, it still exists and eventually it is going to evolve into
something else we do not know exactly yet, but as you see right here on the screen, we
can actually add in a Facebook application, Windows Live ID, Google or Yahoo, and this
is another way we can put in those public providers in there to authenticate against
that.>>Yes, it is a great point Mark and that is the way we can integrate even more authentication
systems. So when you see those things on the Internet, it is leveraging your Facebook credentials
to log on to a certain website. This is actually what is happening behind the scene, so we
could leverage the same thing in our apps. Exactly. So that kind of wraps the topic on
Identity Integration especially with Web API in our Azure applications.

LEAVE A REPLY

Please enter your comment!
Please enter your name here