1 00:00:03,040 --> 00:00:08,020 Now that you understand what claims are and how they're issued, let's talk about the different protocols 2 00:00:08,020 --> 00:00:13,240 that are supported in ADF's for authentication because this will help you understand how applications 3 00:00:13,240 --> 00:00:14,770 interact with the service. 4 00:00:15,390 --> 00:00:21,300 In this clip, we'll talk about the two older protocols that are still supported, which are W's Federation 5 00:00:21,300 --> 00:00:23,130 and SAML 2.0. 6 00:00:23,770 --> 00:00:29,500 And in the next clip, we'll discuss the newer protocol used a lot on the web called OpenID Connect, 7 00:00:29,500 --> 00:00:33,310 which Microsoft often refers to as modern authentication. 8 00:00:33,940 --> 00:00:40,040 Double Federation and SAML 2.0 are often referred to in general as single sign on. 9 00:00:40,640 --> 00:00:44,240 That's because that was really the purpose for them when they were first developed. 10 00:00:44,270 --> 00:00:50,600 A user could sign into the identity provider, which in our case is ADF's, and if they visit another 11 00:00:50,600 --> 00:00:55,760 application that's protected by the same identity provider, they don't need to authenticate again. 12 00:00:56,360 --> 00:01:03,170 This works within your organisation and when organisations are federated together it allows users in 13 00:01:03,170 --> 00:01:08,690 one organisation to access the applications of another organisation using single sign on also. 14 00:01:09,320 --> 00:01:15,080 Let's look at these authentication flows in more detail, starting with the application within a user's 15 00:01:15,080 --> 00:01:16,160 organisation. 16 00:01:16,760 --> 00:01:22,100 You'll typically use open ID connect to protect modern applications, which we'll look at in the next 17 00:01:22,100 --> 00:01:22,640 clip. 18 00:01:23,230 --> 00:01:27,940 But this is still a valid use case and the process is the same at a high level. 19 00:01:28,690 --> 00:01:34,290 A user uses a browser to attempt to access a web resource that's protected by ADF's. 20 00:01:34,990 --> 00:01:40,930 The application has already been configured to use the ADF's server and the ADF's server knows about 21 00:01:40,930 --> 00:01:44,170 this application and has claims rules configured for it. 22 00:01:44,800 --> 00:01:50,470 The application picks up that the user isn't authenticated already, so the application redirects the 23 00:01:50,470 --> 00:01:54,430 user's browser to the ADF's endpoint to authenticate the user. 24 00:01:55,100 --> 00:02:01,010 The user authenticates with ad fs using whatever authentication method is configured as the primary 25 00:02:01,010 --> 00:02:07,040 may be windows authentication forms based authentication, or even using the Azure MFA authenticator 26 00:02:07,040 --> 00:02:08,420 on the user's device. 27 00:02:09,080 --> 00:02:15,380 If the relying party configuration for the application requires that the user perform multi-factor authentication, 28 00:02:15,380 --> 00:02:19,430 then the secondary authentication method is invoked for the user also. 29 00:02:20,060 --> 00:02:26,000 If the user authenticates successfully, then ADF sends a redirect response to the user's browser along 30 00:02:26,000 --> 00:02:31,490 with the security token containing the claims, and this causes the browser to redirect to the web resource 31 00:02:31,490 --> 00:02:32,870 they were trying to access. 32 00:02:32,870 --> 00:02:37,760 And that application can read the security token and extract the claims to have information about the 33 00:02:37,760 --> 00:02:44,280 user as well as other claims that can be used to make authorization decisions in a federation scenario. 34 00:02:44,300 --> 00:02:50,030 The process is similar, except when the user is redirected to the partner organization's identity server, 35 00:02:50,030 --> 00:02:54,380 which could be an ad FS server or any product that supports the protocols. 36 00:02:54,380 --> 00:02:59,750 The user enters their login information and the server picks up that their login relates to the user's 37 00:02:59,750 --> 00:03:00,800 organization. 38 00:03:01,430 --> 00:03:03,920 This is called Home Realm Discovery. 39 00:03:04,560 --> 00:03:11,490 So the partner organization ADF's server redirects the user to the ADF's server of the user's organisation 40 00:03:11,490 --> 00:03:13,410 where the user can authenticate. 41 00:03:14,040 --> 00:03:18,120 In this scenario, the ADF's servers have been federated. 42 00:03:18,720 --> 00:03:24,090 When the user authenticates successfully, they're redirected back to the first ADF's server with a 43 00:03:24,090 --> 00:03:29,010 security token where the claims issued can be transformed by the partner organisation. 44 00:03:29,640 --> 00:03:32,910 From here it's the same as the previous scenario. 45 00:03:33,540 --> 00:03:39,510 Then the user is redirected back to the original application with claims issued by the organisation. 46 00:03:40,110 --> 00:03:46,110 The flows you just saw are actually the same for both W's Federation and for SAML 2.0. 47 00:03:46,770 --> 00:03:51,180 They just differ in the protocols that are used for sign in and the token type. 48 00:03:51,830 --> 00:03:57,230 In order to understand where protocols fit, consider that there are three elements in an authentication 49 00:03:57,230 --> 00:04:02,150 flow the sign in protocol, the authentication protocol and the token type. 50 00:04:02,780 --> 00:04:09,260 The Signing Protocol for Federation and SAML 2.0 differ in the query string parameters that are sent 51 00:04:09,260 --> 00:04:15,230 to the ADF's server when the resource server or relying party redirects the browser to ADF's. 52 00:04:15,890 --> 00:04:18,020 We'll talk more about that shortly. 53 00:04:18,650 --> 00:04:23,810 The authentication protocol relates to the different authentication methods that will be configuring 54 00:04:23,810 --> 00:04:29,480 in the next module, like Windows Authentication Forms, based authentication or certificates. 55 00:04:30,080 --> 00:04:34,280 And the token types are the format of the token data that's returned. 56 00:04:34,880 --> 00:04:39,260 Both WC Federation and SAML 2.0 authentication flows. 57 00:04:39,260 --> 00:04:44,780 Both return the tokens in a SAML format, which stands for Security Assertion Markup Language. 58 00:04:45,380 --> 00:04:53,150 The difference is that US Federation uses the SAML 1.1 format and the SAML 2.0 authentication process 59 00:04:53,150 --> 00:04:56,510 flow uses SAML 2.0 token format. 60 00:04:57,110 --> 00:04:59,660 So as SAML is a token type. 61 00:05:00,300 --> 00:05:05,580 And in the case of SAML 2.0, it's also an authentication protocol. 62 00:05:06,200 --> 00:05:11,180 We'll look at these same three elements in the next clip when we examine OpenID Connect. 63 00:05:11,810 --> 00:05:14,750 Let's look at how the sign in protocols differ. 64 00:05:15,360 --> 00:05:21,300 When the user tries to access a protected resource, the middleware on that server, like ASP.NET Core, 65 00:05:21,300 --> 00:05:27,120 for example, detects that the user isn't authenticated because the user doesn't have a valid authentication 66 00:05:27,120 --> 00:05:27,780 cookie. 67 00:05:28,380 --> 00:05:34,800 So because the application has been configured to use PDFs, the middleware formats, the URI from those 68 00:05:34,800 --> 00:05:41,670 parameters in the configuration, the middleware knows to redirect the user's browser to the ad FS endpoint 69 00:05:41,670 --> 00:05:47,310 that's been configured for Federation and the query string parameter of why is required and is set the 70 00:05:47,310 --> 00:05:51,660 signal 1.0 to tell ADF's to invoke the login for the user. 71 00:05:52,290 --> 00:05:57,720 The trial parameter matches the identifier for the application that's been configured for the relying 72 00:05:57,720 --> 00:05:59,700 party trust in ADF's. 73 00:06:00,330 --> 00:06:05,220 So this is what tells ADF's which relying party the user is trying to authenticate to. 74 00:06:05,250 --> 00:06:08,370 So ADF FFS can prepare the right claims rules. 75 00:06:09,100 --> 00:06:16,000 Optionally you can include information in the WCT parameter that you want sent back after authentication. 76 00:06:16,600 --> 00:06:24,070 This essentially lets you pass around state information and another optional parameter WCT lets you 77 00:06:24,070 --> 00:06:27,190 send the exact time authentication was attempted. 78 00:06:27,790 --> 00:06:32,140 Now let's see an example of a SAML 2.0 sign in attempt. 79 00:06:32,770 --> 00:06:34,780 This one isn't so obvious. 80 00:06:35,410 --> 00:06:41,230 There's a parameter called SAML request that contains a base six four encoded XML document with the 81 00:06:41,230 --> 00:06:43,600 information needed to complete the request. 82 00:06:44,260 --> 00:06:49,900 And this is information similar to what was sent in the US Federation request, like the idea of the 83 00:06:49,900 --> 00:06:52,870 application that access is being requested for. 84 00:06:53,520 --> 00:06:59,190 There are also optional parameters like the ability to send data back after authentication similar to 85 00:06:59,190 --> 00:07:05,670 the WCT parameter in the US Federation in parameters related to the digital signature used to sign the 86 00:07:05,670 --> 00:07:06,510 request. 87 00:07:07,110 --> 00:07:08,520 So when would you want to use. 88 00:07:09,150 --> 00:07:12,150 Federation versus SAML 2.0. 89 00:07:12,850 --> 00:07:18,190 It just depends on the application you're trying to access or the system you're federating your ADF's 90 00:07:18,190 --> 00:07:19,060 server with. 91 00:07:19,720 --> 00:07:26,470 If you're in the Microsoft world, for example, federating with another ADF's server in a partner organisation 92 00:07:26,470 --> 00:07:28,540 you'd use was federation. 93 00:07:29,140 --> 00:07:35,860 But saying 2.0 is supported by many third party applications, so it has better interoperability across 94 00:07:35,860 --> 00:07:37,000 different vendors. 95 00:07:37,630 --> 00:07:43,420 When you configure a relying party trust in ADF's, you have the option to configure it manually or 96 00:07:43,420 --> 00:07:46,120 import data to do the configuration for you. 97 00:07:46,800 --> 00:07:52,470 You can enter the location of the Federation metadata document for the third party identity server or 98 00:07:52,470 --> 00:07:59,310 add FS server or in some cases the vendor will export that information to a file that you can import 99 00:07:59,310 --> 00:08:01,170 here to do your configuration. 100 00:08:01,770 --> 00:08:08,490 And all this is possible because products conform to the US Federation or SAML 2.0 standards. 101 00:08:09,120 --> 00:08:15,600 So protocols for single sign on have given organisations a way to unify authentication systems and federate 102 00:08:15,600 --> 00:08:17,700 across organizational boundaries. 103 00:08:18,330 --> 00:08:24,030 Service oriented architectures and social media have created new needs for applications to use a wide 104 00:08:24,030 --> 00:08:28,440 variety of APIs on the Internet and use them for many different platforms. 105 00:08:29,070 --> 00:08:35,370 The technology that's now widely used for authorization in modern applications is off 2.0, and Open 106 00:08:35,370 --> 00:08:40,020 ID Connect is an extension to off 2.0 that provides authentication. 107 00:08:40,620 --> 00:08:45,840 Let's talk about how those are supported in ADF's 2019 in the next clip.