Now let's create a sample application in Visual Studio and we'll use this app throughout the rest of
the course to test authentication and to view the claims that are returned from ADF's.
If you'd rather skip this clip, you can get the deployment files for this application from the course
downloads.
Let's open up Visual Studio and create a new project.
And I'm going to select ASP.NET Core Web application and give the project name.
We're going to be configuring this to use open ID connect with ADF.
So I'll include DC in the project name.
So that's obvious.
Then let's click create and here we can choose the framework and the project template.
I'm using ASP.NET Core 3.1, which is the latest version of the framework at the time of filming.
I'm going to use the web application template which uses razor pages and I'll leave the default of no
authentication.
We're going to add authentication middleware in code.
Now I'll click Create.
And when the project opens, let's open solutions explore.
The first thing you need to do is right click on dependencies and choose managed NuGet packages.
We need the NuGet package that adds the authentication middleware.
So let's go to browse and search the package source on the Internet for Microsoft, ASP.NET Core Authentication
OpenID Connect.
And here's the package for the Middleware Library.
So let's click that and on the right click install.
You just need to agree to changes and accept the license agreement.
Once the library is added, let's close these panes and the NuGet package manager also.
Now let's add the code to force authentication using the middleware.
We do that and start up.
So let's open that up and scroll down to the Configure Services method.
I've got some code on my clipboard that I'm going to paste in and then we'll go through it.
But first let me just format this a bit and we need to import some using statements for these classes
that aren't being recognized.
You can do that by right clicking and selecting quick actions and refactoring things.
I'll bring in the identity model protocols namespace.
And further up here we need authentication, cookies and authentication.
OpenID Connect.
Okay.
So this code calls the ad authentication method on the service collection.
And the first thing we can figure is the default authentication scheme.
In this case, it's the cookie authentication scheme, which means that every time the page is accessed,
we check to see if the user has an authentication cookie already.
If they don't, then the default challenge scheme is OpenID Connect.
Then we add the add cookie extension and will be adding more configuration to that later in the module.
And in the ad OpenID Connect Extension Method.
Let's look at the configuration here.
Normally you'd put the values in a configuration file, and we'll do that for the deployment.
But it's easier to see the actual values in Code four now.
The first thing is the metadata address.
If we were using Federation as the protocol, this would point to the Federation metadata XML document
to tell our application all about how to decrypt tokens and what claims are available.
Because we're using open ID connect, there's a different endpoint on the ADF's server.
For your environment, you'll need to change the server name.
Everything else will remain the same after that.
We're going to get the client ID value when we configure the application group in ADF's sign in scheme
is actually redundant since we've already specified a default scheme.
But it's good to be explicit.
Require HTTP metadata actually defaults to true.
But if you needed to disable it in a dev environment, you could with this value.
Of course ADF only publishes on https, so this isn't really necessary either.
The response type is an open ID connect parameter that tells us what we want returned.
In our case, we want the authorization code, but we could ask for the access token, ID token or a
combination.
The middleware will use the authorization code to make its own call to get an access token.
The response mode is a parameter that will tell a DFS how to send the token information back to the
client.
Form post is the default, so the browser will redirect to the application the user is trying to access
and the tokens will be passed as form values in a post.
You could also choose to have the tokens attached as a query string value or as a URL fragment in the
case of a single page application, for example.
Next, we need to specify scopes, and these need to correspond to scopes that have been configured
in ADF's for this relying party application.
The only scope we need is the opening scope.
In order to tell ADF's that we're using the open ID Connect protocol.
And the safe tokens value being set to true tells ASP.NET Core that we want to store the access token
and refresh token in the authentication properties class after a successful authentication.
This is false by default.
So I've set this so we can query the raw token values and display them in the browser for the sample.
Now let's move down the code to the configure method.
Here.
We just need to add app use authentication and the order is important here.
This needs to come right before use authorization.
Okay, now let's add the code to display the claims on the screen.
I'm going to open up the default page for the app which is indexed csv html.
Let's replace the code here with some code I've already written.
At the top we're adding a using to Microsoft ASP.NET Core authentication, and that's so we can display
the token values from the authentication properties.
The actual claims are already in the user object, so we can just loop through them and display the
claim type and value in a table.
Then below that is where we get the raw JSON web tokens that come in base 64 format.
I'll show you why later in the module.
Now, the next thing is to open up the code behind for this page and add this authorized attribute to
the top of the class, which tells ASP.NET Core that the user needs to be authenticated in order to
access this page, which of course will force the redirect to add ZFS, since the user won't have an
authentication cookie the first time they accessed the page.
The last thing I'm going to add is some code to the layout page, and this is just some CSS to help
with displaying the table.
I already have that written, so I'll just paste it into the head of the layout page.
Okay.
Let's just build this and make sure there are no errors and the build succeeds.
So next up, let's configure a PDFs to know about this application.
Now let's configure the application group for authentication to our web application.
I'm on the Windows ten management VM we used in previous module to set up ADF's.
A I open up server manager which I installed with the remote server administration tools.
Normally we can administer server features by going to tools and there should be an option for Active
Directory Federation services here.
But this actually isn't supported in the SAT tools.
So we're going to need to either do the configuration remotely using PowerShell or remote into the actual
FS server.
In order to do the configuration, you could do a remote desktop from the Windows Admin Center.
But for the sake of screen real estate, I'm going to remote into the VM that's running ADF's.
I've already opened the ADF's management console from the tools menu in server manager on this VM.
So let's go to application groups and right click and add application group.
We went through these options in an earlier clip.
The one we want, for the simple example is the web browser accessing a web application.
Now let's give the application group a name and click next.
Now we need the redirect, you or I.
This is the address will be redirecting the browser to after a successful authentication.
It'll be a local host address since we're running in Visual Studio.
So we need to know the port number of the app is using.
But first, let's copy the client identifier because we need to send this from the application.
Now let's go back to the VM running Visual Studio and paste the client ID into our code.
Now I know the application will be running on the local host server, but I need the port so we can
get that from properties.
Launch Settings JSON.
The port for the app running on https will be 44386.
But we could change that here if we wanted to.
Let's just remember this port and go back to the ADF's server.
Now we'll type in the address of the application, which is http colon slash slash local host port four
four, three, eight, six and I need to add this path slash sign and oik.
This isn't an actual page in the application.
This is just the path that's picked up by the authentication middleware for Open ID Connect.
Let's add this and click next.
And this is where we can configure the authorization rules.
Let's leave the default to permit all and click next.
Here we can see a summary of the configuration.
So let's click next and the application group has been created.
Let's close this and right click on the application group and select properties.
This shows us a list of all the client and server applications that are part of this application group.
It says native application, but this is actually just the browser in our case.
Let's close this and go back to the VM with our Visual Studio application.
Alta save these changes and let's start debugging.
The browser opens up to our application running on local host and because the user isn't authenticated,
the middleware kicks in and redirects the browser to the ADF's login page.
I have forms authentication set as the primary authentication method in advance so we can explicitly
log in.
I'll enter my credentials and click sign in.
And here we can see the default claims that ADF's is sending back.
Remember, we didn't configure any specific claims.
We'll do that next.
And at the bottom are the tokens that were returned.
And these are basics for encoded.
So they actually contain the claims information that you see above on the page.
I'll show you how to verify that later in the module.
There's the oath 2.0 access token at the top and below that is the ID token for open ID connect.
Now that we have a working application, let's explore claims issuance rules a bit more in the next
clip.
I'm on the ADF's server where I've got the ADF's management console open.
Let's go to the application group we just created and double click to open it.
The web application in the applications list is where you can configure the claims that are returned
to the application.
So let's select that application and click edit.
The properties are displayed and we can modify the access control policy from the tap at the top.
We can configure the scopes in the client permissions tab and we can modify the issuance, transform
rules.
These are where we can figure the claims that are returned.
Let's click that tab and add a new rule.
What I want to do is return all the claims that are available.
So let's do that by adding a custom rule.
This opens a screen where we can type in a custom rule using claims rule language.
I'll give the rule of name first.
And getting into claims rule language is beyond the scope of this course.
But let's just add a simple rule to issue all claims.
That's all there is to the code.
So let's click finish.
We could add more rules to the list of claims rules, but this covers everything will need will use
a different template in the next clip when we look at returning user roles now let's go back to our
VM with Visual Studio and close the running application to clear the cookie from the browser and let's
run the app again.
So we need to log into ad FS, we get to the login page, so I'll enter my credentials and click sign
in and we get an error.
I actually traced this error using Fiddler.
And what's happening is that we're returning so many claims in the response that it's exceeding the
limits of the browser as it's configured by default.
So I don't recommend sending every claim back in a production scenario.
But since we're just training here, I'm going to show you how to override this in the registry on the
local computer.
Again, I don't suggest this for production.
Let's close this and go to the search box and type in rejected.
This opens the registry editor.
If you're not confident with what you're doing here, you should back up your registry settings and
proceed with caution.
Let's go to HK underscore local underscore machine system, current control set services and scroll
down to HTTP and click on the parameters.
Hive.
We need to add a couple of keys here to allow the browser to accept more data in a single response.
And again, this is just so we can see all the claims possible from ADF's.
Let's add a new D-word and give it the name Max Field length and set the decimal value to the maximum,
which is 65,534.
And let's create one more D word registry key and call it max request bytes and set the decimal value
to 16777216.
And that's all we need to do.
Now let's close this and we'll need to restart this VM for the registry changes to take effect.
So I'll speed things up a bit.
And we're back with Visual Studio Open.
Now let's run the app again and we're brought to the ADF's login page.
So I'll enter my credentials and click sign in.
And now we're brought into the application and we have considerably more claims displayed.
Right now there's information about the authentication method used.
There are security identifiers for the groups the user belongs to and I'll show you how to send actual
group names in the next clip.
There's information about the browser type the user used to authenticate.
There's an indicator that the user came from inside the corporate network.
There's the IP address of the user and the scopes that were sent in the open ID Connect request.
Now let's look at the tokens below that.
These are the values from the JSON web tokens that ADF's returned after authentication.
Let's open another browser tab and navigate to JWT audio.
This is a site that allows you to paste in a JSON web token and decode the base 64 encoded information.
Let's go back to the application and let's copy the ID token and over in JWT IO, I'll paste the token
in.
On the right is the decoded value of the token.
You can see the claims are here just as they were in the user claims collection that we iterated over
in HTML.
Now let's remove this token and let's go back and copy the access token and let's decode that value.
It's largely the same values which may not always be the case.
So if you ever need to debug the tokens that are returned from a PDFs, you know how to retrieve them
in your code and where to go to decode the values.
Next, let's look at how we can use claims in ASP.NET Core Code to perform authorization within the
application.