1 00:00:03,050 --> 00:00:08,030 Let's start this module by talking about claims in ADF's. 2 00:00:08,030 --> 00:00:13,130 Claims are the key component that are used to determine the outcome of all web based authentication 3 00:00:13,130 --> 00:00:17,690 and authorizations, claims or statements made about users. 4 00:00:18,350 --> 00:00:20,870 Each claim has a type and a value. 5 00:00:21,470 --> 00:00:25,880 That type can be a well known type ID or you can create your own if needed. 6 00:00:26,450 --> 00:00:29,600 And claims are retrieved from an attribute store. 7 00:00:30,230 --> 00:00:33,710 That attribute store is Active Directory by default. 8 00:00:34,310 --> 00:00:40,580 But in ADF's you can also pull information about users from other attributes stores like a SQL Server 9 00:00:40,580 --> 00:00:42,590 database or an LDAP store. 10 00:00:43,260 --> 00:00:47,880 Claims are mainly used for authorizing access to claims based applications. 11 00:00:48,510 --> 00:00:54,900 Typically that authorisation happens right within ADF's, but you can also send claims back to the application 12 00:00:54,900 --> 00:00:56,550 the user is trying to access. 13 00:00:56,550 --> 00:00:59,430 So authorisation decisions can be made there too. 14 00:01:00,030 --> 00:01:05,430 Let's actually look at the list of claim descriptions right in ADF's 2019. 15 00:01:06,060 --> 00:01:11,790 Each claim has a type and the value gets populated from the attribute store during the authentication 16 00:01:11,790 --> 00:01:12,660 process. 17 00:01:13,290 --> 00:01:18,870 These are the claims that ADF comes with by default, but you can add custom claims here or you can 18 00:01:18,870 --> 00:01:22,920 return completely different custom clans using a claims rule in code. 19 00:01:23,490 --> 00:01:29,760 But these are the claims that ADF's publishes in its Federation metadata XML file, which tells other 20 00:01:29,760 --> 00:01:34,860 partner organisations that want to federate with the server just which claims the server can send and 21 00:01:34,860 --> 00:01:35,550 accept. 22 00:01:36,150 --> 00:01:39,510 And that's defined in these columns here, which you can edit. 23 00:01:40,110 --> 00:01:45,780 You can see some expected claim types about the users being authenticated, like the user's name, email 24 00:01:45,780 --> 00:01:47,760 address and group information. 25 00:01:48,310 --> 00:01:53,590 But there are also claims here like information about the authentication method the user used in things 26 00:01:53,590 --> 00:01:59,230 like the device OS version and device registration information if device registration is in use. 27 00:01:59,860 --> 00:02:05,890 There are also claims here related to 6.509 certificates and whether the user is inside the corporate 28 00:02:05,890 --> 00:02:06,610 network. 29 00:02:07,270 --> 00:02:11,920 You can edit these clean descriptions, for example, if you want to change whether they're published 30 00:02:11,920 --> 00:02:17,230 in the Federation metadata XML document and you can add your own plane descriptions here that can also 31 00:02:17,230 --> 00:02:19,030 be issued by ADF's. 32 00:02:19,680 --> 00:02:20,730 By default. 33 00:02:20,730 --> 00:02:24,330 The values for many of these claims come from Active Directory. 34 00:02:24,890 --> 00:02:29,900 But seeing as they're defined here using known claim types, the values could come from any attribute 35 00:02:29,900 --> 00:02:35,150 store that's compatible with PDFs like an LDAP store or a SQL Server database. 36 00:02:35,150 --> 00:02:37,220 And you'll see that in the next module. 37 00:02:37,850 --> 00:02:43,400 Some claims are a product of the environment the user is logging in from, like the claim inside corporate 38 00:02:43,400 --> 00:02:50,510 network or about the computer the user is accessing PDFs from like his known device or the claim could 39 00:02:50,510 --> 00:02:56,180 be a byproduct of the authentication process itself, like the authentication method and timestamp. 40 00:02:56,840 --> 00:03:02,740 And again, these claims could be evaluated while authenticating and authorizing the user in advance 41 00:03:02,750 --> 00:03:07,970 and they could get sent back to the application the user is requesting access to or to the Federation 42 00:03:07,970 --> 00:03:09,050 Partners server. 43 00:03:09,820 --> 00:03:14,470 A really powerful feature of ADF's is that it contains a claims rule engine. 44 00:03:15,070 --> 00:03:19,870 So besides allowing you to pass claims through that are retrieved from the attribute store, it can 45 00:03:19,870 --> 00:03:24,550 also transform the claim to another value based on logic expressed in a rule. 46 00:03:25,260 --> 00:03:30,930 For example, you might want any administrator within Active Directory to have admin access within your 47 00:03:30,930 --> 00:03:31,980 application. 48 00:03:32,540 --> 00:03:38,390 But there are several group names for administrators like domain admins, enterprise admins and security 49 00:03:38,390 --> 00:03:38,960 admins. 50 00:03:38,960 --> 00:03:42,290 And you don't want your application have to take that into account. 51 00:03:42,920 --> 00:03:46,160 The app only needs to know if the user is an admin. 52 00:03:46,730 --> 00:03:51,830 You could retrieve the user's groups from Active Directory as claims and evaluate them within a claim 53 00:03:51,830 --> 00:03:56,570 rule and then pass back a single claim that indicates the user is an administrator. 54 00:03:57,200 --> 00:04:00,110 That's a simple example of a single claim. 55 00:04:00,680 --> 00:04:06,080 So keep in mind that all the user's claims are sent back inside a security token, and we'll talk more 56 00:04:06,080 --> 00:04:09,860 about the different formats for those tokens in the next couple of clips. 57 00:04:10,460 --> 00:04:16,250 When ADF retrieves claims for an authenticated user, they move through stages in advance where they're 58 00:04:16,250 --> 00:04:20,960 evaluated and possibly transformed before being sent back to the calling application. 59 00:04:21,560 --> 00:04:23,870 This is called the claims pipeline. 60 00:04:24,470 --> 00:04:30,080 The three stages in the claims roll pipeline are acceptance of incoming claims, authorization of the 61 00:04:30,080 --> 00:04:33,260 claims requester and issuance of outgoing claims. 62 00:04:33,890 --> 00:04:39,260 The actual evaluation of claims that each point in the pipeline is done by the claims engine. 63 00:04:39,860 --> 00:04:45,380 And when you need to control the flow of those claims, you use business logic called claims rules. 64 00:04:46,010 --> 00:04:51,470 Claims rules allow you as the administrator to control the claims pipeline at the different stages. 65 00:04:52,090 --> 00:04:58,090 They're evaluated in order so each rule can create or transform claims that are used by the next rule. 66 00:04:58,760 --> 00:05:00,170 In the acceptance stage. 67 00:05:00,170 --> 00:05:05,540 The claims rule engine accepts claims that are either coming from the attribute store that ADF's is 68 00:05:05,540 --> 00:05:12,200 using, which is typically Active Directory or in the case of a federation scenario, the claims would 69 00:05:12,200 --> 00:05:17,750 be coming from a federated partner's identity provider, which might be another ADF server. 70 00:05:18,470 --> 00:05:24,440 Either way, in the acceptance stage, claims are extracted and any claims that aren't expected or trusted 71 00:05:24,440 --> 00:05:25,520 are filtered out. 72 00:05:26,120 --> 00:05:28,100 Then claims rules are run. 73 00:05:28,730 --> 00:05:34,280 Let's take a look at these claims rules in advance for the default claims provider trust, which is 74 00:05:34,280 --> 00:05:35,480 Active Directory. 75 00:05:36,080 --> 00:05:42,110 Let's go to claims provider trusts and we only have the default configured which is Active Directory. 76 00:05:42,740 --> 00:05:49,670 So I'll right click and edit claim rules when the user authenticates the claims for the user are retrieved 77 00:05:49,670 --> 00:05:51,530 from the claims provider trust. 78 00:05:52,130 --> 00:05:57,560 You can see the following claims rules are created by default and they involve passing through specific 79 00:05:57,560 --> 00:05:59,930 claims retrieved from Active Directory. 80 00:06:00,560 --> 00:06:02,150 Let's look at this first one. 81 00:06:02,150 --> 00:06:04,730 Pass through all Windows account name claims. 82 00:06:05,330 --> 00:06:10,460 This takes the incoming claim type, which is the Windows account name and just passes it through to 83 00:06:10,460 --> 00:06:14,570 the next claim rule and ultimately to the next stage of the claims pipeline. 84 00:06:15,170 --> 00:06:20,090 This rule is based on a template, though, and that template allows for filtering this claim. 85 00:06:20,690 --> 00:06:26,390 So it's only passed through with the claim has a specific value if the claim value matches a specific 86 00:06:26,390 --> 00:06:30,710 email suffix, or if the claim value starts with a specific value. 87 00:06:31,310 --> 00:06:37,190 You can click this button to see the actual claim rule language that this template is creating underneath. 88 00:06:37,820 --> 00:06:40,820 Now let's close this and let's look at adding a rule. 89 00:06:41,500 --> 00:06:47,020 These are the claim rule templates that are available in advance, and these same templates are actually 90 00:06:47,020 --> 00:06:50,650 available in the issuance stage of the claims roll pipeline also. 91 00:06:51,320 --> 00:06:56,750 I won't go through them in detail, but you can see there's a template related to LDAP attributes one 92 00:06:56,750 --> 00:07:01,100 related to group membership, a template that allows you to transform an incoming claim. 93 00:07:01,100 --> 00:07:05,930 The template we just saw which lets you pass through or filter a claim and a template that lets you 94 00:07:05,930 --> 00:07:08,480 write custom rules using claims rule language. 95 00:07:09,110 --> 00:07:13,070 You'll see an example of this in the demos later in this module. 96 00:07:13,670 --> 00:07:19,070 Once the acceptance transform rules are run, the claims are passed to the authorization stage where 97 00:07:19,070 --> 00:07:20,780 more claims rules are run. 98 00:07:21,380 --> 00:07:24,260 Let's examine these rules in a DFS. 99 00:07:24,920 --> 00:07:26,600 In the authorization stage. 100 00:07:26,600 --> 00:07:32,840 Access control policies are run on the individual relying party trust or a server resource in an application 101 00:07:32,840 --> 00:07:35,000 group in the case of OAuth clients. 102 00:07:35,660 --> 00:07:38,090 Authorization rules also have templates. 103 00:07:38,090 --> 00:07:39,500 So let's take a look. 104 00:07:40,130 --> 00:07:45,860 Here are the built in access control policies that come with ADF's, but you can create your own and 105 00:07:45,860 --> 00:07:48,260 I'll show you that later in this module too. 106 00:07:48,860 --> 00:07:54,680 These policies are evaluated after the user has authenticated with whatever credentials you've configured 107 00:07:54,680 --> 00:07:56,540 as the primary credentials. 108 00:07:57,200 --> 00:08:02,750 You can see there's a policy that allows access to every authenticated user, a policy that permits 109 00:08:02,750 --> 00:08:06,140 access based on membership in a particular security group. 110 00:08:06,740 --> 00:08:11,480 There's a policy that allows anyone to access the relying party if they're coming from the intranet 111 00:08:11,480 --> 00:08:17,330 and policies that require multi-factor authentication to be invoked under specific circumstances, like 112 00:08:17,330 --> 00:08:22,640 if the user is coming from the Internet, has an unauthenticated device, or if they belong to a certain 113 00:08:22,640 --> 00:08:23,210 group. 114 00:08:23,850 --> 00:08:29,550 The parameters for some of these templates, like the groups the user needs to be a member of are configured 115 00:08:29,550 --> 00:08:36,240 when the template is applied to a specific relying party that's indicated by the parameter value in 116 00:08:36,240 --> 00:08:37,530 the rule properties. 117 00:08:38,160 --> 00:08:43,680 The authorisation stage of the claims pipeline results in a decision whether or not the token requester 118 00:08:43,680 --> 00:08:47,730 is allowed to obtain a token for the relying party that they're trying to access. 119 00:08:48,390 --> 00:08:54,510 In other words, if the user fails primary or multi-factor authentication, then the process stops here 120 00:08:54,510 --> 00:08:56,760 and an error is returned to the caller. 121 00:08:57,410 --> 00:09:02,180 If authentication was successful, then the claims are passed to the issuance stage of the pipeline 122 00:09:02,180 --> 00:09:07,130 where again they could be filtered, transformed or pass through using the same claims templates we 123 00:09:07,130 --> 00:09:08,780 saw in the acceptance stage. 124 00:09:09,420 --> 00:09:14,460 And like the authorization stage, the rules here are configured specifically for the relying party 125 00:09:14,460 --> 00:09:17,190 application the user is trying to access. 126 00:09:17,820 --> 00:09:23,310 Now that you understand how claims are issued by ADF's, we'll talk next about the different security 127 00:09:23,310 --> 00:09:30,270 protocols that those relying parties use to set up trusts with ADF's and exchange information over https. 128 00:09:30,930 --> 00:09:35,670 Then you'll learn about application groups which allow you to group together the web clients, native 129 00:09:35,670 --> 00:09:42,030 clients and APIs that typically make up a modern application that uses the OAuth 2.0 protocol. 130 00:09:42,710 --> 00:09:49,130 Next, we'll create an ASP.NET Core Web application and Visual Studio to integrate with ADF's and display 131 00:09:49,130 --> 00:09:50,690 the claims that are received. 132 00:09:51,320 --> 00:09:55,220 You can just download the app from the course downloads if you prefer. 133 00:09:55,820 --> 00:10:00,920 But walking through the steps of creating it will show you the middleware that supports show off 2.0 134 00:10:00,920 --> 00:10:02,450 and open ID connect. 135 00:10:03,080 --> 00:10:08,990 Then we'll configure an Add FS application group to authenticate users of the application and return 136 00:10:08,990 --> 00:10:12,200 claims, and we'll examine some of the different claim rules. 137 00:10:12,860 --> 00:10:19,190 After that, I'll show you how to use claims to perform authorization in the ASP.NET Core Web application. 138 00:10:19,820 --> 00:10:24,230 Then we'll package up the application and see how to deploy it to IIS. 139 00:10:24,860 --> 00:10:30,770 If you didn't create the application yourself in Visual Studio, you can just use the packaged application 140 00:10:30,770 --> 00:10:32,150 in the course downloads. 141 00:10:32,780 --> 00:10:39,050 Then you'll see custom access policies in advance which allow you to set up your own authorization rules. 142 00:10:39,690 --> 00:10:46,740 And finally, we'll look at a feature that's new in ADF's 2019, which allows you to customize HTTP 143 00:10:46,740 --> 00:10:48,450 security response headers. 144 00:10:49,080 --> 00:10:54,420 So next, let's talk about how these claims get passed around in various authentication flows. 145 00:10:55,050 --> 00:11:00,630 And in the process, we'll talk about the authentication protocols that ADF's supports.