Prior to add ZFS in Windows Server 2016, you created a relying party trust to represent an application
that used ADF's for authentication.
So the same mechanism for federating with another organisation by setting up a federated partner as
a relying party.
That mechanism was also used for integrating web applications with ADF's.
And that's because those web applications had used W's Federation or SAML 2.0 as the protocol for brokering
authentication with ADF's.
It's still possible to configure applications to use those protocols.
But since the rise of OAuth 2.0 Open ID Connect PDFs has continually added support for those protocols.
There was limited support for OAuth and ADF's in server 2012 or to using relying parties.
The idea of an application group was introduced in ADF's 2016.
An application group is a separate configuration in ADF's, completely apart from a relying party.
But at a high level, they serve a similar purpose.
They're both containers for the configuration required to integrate an application with ADF's.
But application groups can be just that.
Groups of smaller components that work together to make up an entire application that could include
a web application on its own, or a JavaScript single page application that works with a back end web
API on a web server or a server that communicates with another web API or a native application on a
desktop that communicates with a web API or a mobile app that uses several web APIs, and the list goes
on.
The point is, each element of each of those applications have individual configurations, but they
ultimately are part of the same application.
You could say they have the same security context.
Let's talk first about types of applications that make up an application group.
There are three types of applications a public client, a confidential client, and a Web API.
A public client could be a native application running on a desktop or a single page application running
in the browser or a mobile application running on a device.
This type of application has a client ID configured that it sends and requests to identify itself with
ADF's and it requests tokens from the ADF's server.
The Public Client app can then send HTTP requests to protected resources such as web APIs on servers
using those tokens.
A confidential client is a web application that runs on a server and is usually accessible to a user
via the browser.
The Web app is called a confidential client because it can maintain its own secret credential to authenticate
with the ADF's server.
You couldn't store a secret in a single page JavaScript application or in a config file on a desktop
client, because that secret could be compromised.
So the fact that the server can securely store that secret away from prying eyes is what makes the web
application a confidential client.
The Web app can request tokens from ADF's to access other resources like web APIs on other servers.
The web app makes those requests by authenticating with its client ID and the secret that's known to
the web app and the ADF's application group configuration.
So it's kind of like a username and password that's stored on the web app server and in the ADF's application
group configuration.
The last application type is the web API, which is just a resource server that accepts bearer tokens
from the public and confidential clients in order to return data to them.
These are essentially the relying party applications in modern authentication, but if a web API needs
to make calls to another web API, then the first web API is acting as a confidential client in that
case, and it can use a stored client ID in secret to get a bearer token from ADF's to use when calling
the second web API.
And remember, that Bearer Token is another name for the access token we talked about in the previous
clip on ORF 2.0.
Let's take a look at the application group configurations in advance to see how different application
types are configured.
When you create a new application group, there are several templates to choose from.
These give you a pre-configured group of elements that represent the components of typical applications.
You can get more information on each of these templates by selecting one and clicking more information
at the bottom.
Let's walk through the different templates.
First we need to give the application group a name.
I have the first template selected, so I'll click next.
This template has a public client and a web API.
The first configuration is the public client in this template, which is called a native application.
This could be an app running on a phone, tablet or desktop.
There's a client identifier created, but you can change this if you like.
A confidential client is a web application that runs on a server and is usually accessible to a user
via the browser.
The Web app is called a confidential client because it can maintain its own secret credential to authenticate
with the ADF's server.
You couldn't store a secret in a single page JavaScript application or in a config file on a desktop
client, because that secret could be compromised.
So the fact that the server can securely store that secret away from prying eyes is what makes the web
application a confidential client.
The Web app can request tokens from ADF's to access other resources like web APIs on other servers.
The web app makes those requests by authenticating with its client ID and the secret that's known to
the web app and the ADF's application group configuration.
So it's kind of like a username and password that's stored on the web app server and in the ADF's application
group configuration.
The last application type is the web API, which is just a resource server that accepts bearer tokens
from the public and confidential clients in order to return data to them.
These are essentially the relying party applications in modern authentication.
But if a web API needs to make calls to another web API, then the first web API is acting as a confidential
client in that case, and it can use a stored client ID in secret to get a bearer token from ADF's to
use when calling the second web API.
And remember, that Bearer Token is another name for the access token we talked about in the previous
clip on OEF 2.0.
Let's take a look at the application group configurations in advance to see how different application
types are configured.
When you create a new application group, there are several templates to choose from.
These give you a pre-configured group of elements that represent the components of typical applications.
You can get more information on each of these templates by selecting one and clicking more information
at the bottom.
Let's walk through the different templates.
First, we need to give the application group a name.
I have the first template selected, so I'll click next.
This template has a public client and a web API.
The first configuration is the public client in this template, which is called a native application.
This could be an app running on a phone, tablet or desktop.
There's a client identifier created, but you can change this if you like.
Then the access control policy can be configured and there are no scopes in this case, but it actually
configures the open ID scope by default and you can modify these later if you need to.
If you look at the standalone application templates, these are just portions of the templates above.
So just the client component or Web API component.
So the client server application templates are combinations of the individual application templates.
And what's interesting is that as your application evolves, you can add components to your application
group to represent new parts of your total application.
Let's open up an existing application.
This application group has a client and a server component.
Let's say we needed to add a web API to this application that the web app will call.
We can click on add application at the bottom, and that opens up a dialog where we can choose one of
the standalone templates to configure a web API, for example, and that will get added to our application
group.
So that's a tour of application groups in ADF's.
Next, let's create a sample application to use as a protected resource and to view claims return from
ADF's.
In the process, we'll also configure an application group.