1 1 00:00:00,360 --> 00:00:01,193 SAML, 2 2 00:00:01,193 --> 00:00:04,170 the security assertions markup language. 3 3 00:00:04,170 --> 00:00:07,440 Now, SAML is another XML-based data format 4 4 00:00:07,440 --> 00:00:09,300 and this one is one that's used to exchange 5 5 00:00:09,300 --> 00:00:13,110 authentication information between a client and a service. 6 6 00:00:13,110 --> 00:00:14,220 This is used to send things 7 7 00:00:14,220 --> 00:00:16,200 like our authentication for the user, 8 8 00:00:16,200 --> 00:00:19,020 the entitlement to the user, and the attributes of the user, 9 9 00:00:19,020 --> 00:00:21,930 and often we're going to pair this up with SOAP 10 10 00:00:21,930 --> 00:00:25,500 so we can use SAML and then send it over the SOAP protocol. 11 11 00:00:25,500 --> 00:00:29,370 Because SOAP is used for authorization, not authentication 12 12 00:00:29,370 --> 00:00:30,840 and so by pairing these two together 13 13 00:00:30,840 --> 00:00:33,810 we will get authorization and authentication. 14 14 00:00:33,810 --> 00:00:35,220 Now, when we're dealing with SAML 15 15 00:00:35,220 --> 00:00:39,128 this is often used to provide Single sign-on service or SSO 16 16 00:00:39,128 --> 00:00:42,030 a federated identity management system. 17 17 00:00:42,030 --> 00:00:44,220 This allows the service provider to establish 18 18 00:00:44,220 --> 00:00:46,830 a trust relationship with the identity provider. 19 19 00:00:46,830 --> 00:00:48,510 This way, the identity of the user 20 20 00:00:48,510 --> 00:00:50,610 which we call the principle, can be trusted 21 21 00:00:50,610 --> 00:00:52,500 by the service provider without the user 22 22 00:00:52,500 --> 00:00:53,730 ever having to authenticate 23 23 00:00:53,730 --> 00:00:55,800 directly with the service provider. 24 24 00:00:55,800 --> 00:00:57,210 Now, I'll explain how this works 25 25 00:00:57,210 --> 00:00:59,130 as we go through this lesson. 26 26 00:00:59,130 --> 00:01:00,510 Now, when you look at SAML 27 27 00:01:00,510 --> 00:01:02,880 it's header looks something like this. 28 28 00:01:02,880 --> 00:01:04,860 Essentially you have SAML information 29 29 00:01:04,860 --> 00:01:07,350 that's being communicated in the form of assertions, 30 30 00:01:07,350 --> 00:01:08,310 and this is why we call it 31 31 00:01:08,310 --> 00:01:11,820 the security assertions markup language, or SAML. 32 32 00:01:11,820 --> 00:01:14,880 As I said, these assertions are used for authentication 33 33 00:01:14,880 --> 00:01:16,110 and they're going to contain information 34 34 00:01:16,110 --> 00:01:18,810 about the user's identity, making sure it's valid, 35 35 00:01:18,810 --> 00:01:20,670 making sure you have information about the user 36 36 00:01:20,670 --> 00:01:23,790 and information about the level of access for each user. 37 37 00:01:23,790 --> 00:01:25,740 You take this SAML requester response 38 38 00:01:25,740 --> 00:01:28,320 you wrap that as part of the SOAP body 39 39 00:01:28,320 --> 00:01:31,110 then you use the SOAP header to get it where it needs to go. 40 40 00:01:31,110 --> 00:01:34,020 All of that is wrapped inside the HTTP body 41 41 00:01:34,020 --> 00:01:35,430 and then you have the header on top 42 42 00:01:35,430 --> 00:01:37,320 telling it where it needs to go. 43 43 00:01:37,320 --> 00:01:38,490 Now, as we look at this 44 44 00:01:38,490 --> 00:01:40,470 I want you to think about it like this. 45 45 00:01:40,470 --> 00:01:41,820 We have three roles here. 46 46 00:01:41,820 --> 00:01:44,100 We have the service provider, the user agent, 47 47 00:01:44,100 --> 00:01:45,720 which is usually your web browser 48 48 00:01:45,720 --> 00:01:47,730 and then the identity provider. 49 49 00:01:47,730 --> 00:01:49,680 Let's pretend that I'm the service provider 50 50 00:01:49,680 --> 00:01:51,720 and you want to log into my website 51 51 00:01:51,720 --> 00:01:54,000 but I don't do my own identities. 52 52 00:01:54,000 --> 00:01:55,710 Instead, I'm going to allow you to sign on 53 53 00:01:55,710 --> 00:01:57,990 using say your Google log on. 54 54 00:01:57,990 --> 00:01:59,610 That would be the identity provider. 55 55 00:01:59,610 --> 00:02:03,150 So, the first step is you as the user go to my website 56 56 00:02:03,150 --> 00:02:04,860 and you request the target resource. 57 57 00:02:04,860 --> 00:02:08,130 So you go to diontraining.com and you click on Login. 58 58 00:02:08,130 --> 00:02:09,270 When that happens, 59 59 00:02:09,270 --> 00:02:11,010 you and I are going to do this little handshake 60 60 00:02:11,010 --> 00:02:13,110 where we discover the identity provider. 61 61 00:02:13,110 --> 00:02:15,750 We're going to say, hey, I support Google Log on. 62 62 00:02:15,750 --> 00:02:17,130 Do you want to use Google Log on? 63 63 00:02:17,130 --> 00:02:18,810 I think you would say, sure. 64 64 00:02:18,810 --> 00:02:20,640 Well, when you click that login button 65 65 00:02:20,640 --> 00:02:23,310 I'm going to then redirect you to the SSO service, 66 66 00:02:23,310 --> 00:02:26,250 the Single sign-on service that goes back to your browser 67 67 00:02:26,250 --> 00:02:28,170 and your browser then makes a request 68 68 00:02:28,170 --> 00:02:30,630 to Google Service, the identity provider. 69 69 00:02:30,630 --> 00:02:32,340 They're going to do the identification with you 70 70 00:02:32,340 --> 00:02:34,560 making sure your username and password is right. 71 71 00:02:34,560 --> 00:02:36,480 Then they'll take all that information they know about you 72 72 00:02:36,480 --> 00:02:39,300 and respond within an XHTML form. 73 73 00:02:39,300 --> 00:02:41,040 That goes back to your browser. 74 74 00:02:41,040 --> 00:02:42,210 Your browser then takes that 75 75 00:02:42,210 --> 00:02:45,120 and then does a request assertion for consumer service. 76 76 00:02:45,120 --> 00:02:47,220 Essentially, you're going to send the information you got 77 77 00:02:47,220 --> 00:02:48,450 from the identity provider 78 78 00:02:48,450 --> 00:02:50,850 which tells me this person has been authorized 79 79 00:02:50,850 --> 00:02:52,920 and these are the permissions they should have. 80 80 00:02:52,920 --> 00:02:54,600 Then that goes over to me. 81 81 00:02:54,600 --> 00:02:55,950 Once I get that as a service provider, 82 82 00:02:55,950 --> 00:02:57,900 I say, ah, this is John. 83 83 00:02:57,900 --> 00:02:59,580 John is allowed to access my videos. 84 84 00:02:59,580 --> 00:03:02,190 Let me log in and give John access to those videos. 85 85 00:03:02,190 --> 00:03:04,050 So I then send the videos back to you. 86 86 00:03:04,050 --> 00:03:05,940 At that point, if you want more things 87 87 00:03:05,940 --> 00:03:08,430 you can request it again because you're already authorized. 88 88 00:03:08,430 --> 00:03:09,990 You can say, okay, I've finished watching this video, 89 89 00:03:09,990 --> 00:03:11,130 show me the next one, 90 90 00:03:11,130 --> 00:03:13,320 and then I would respond back with that requested resource. 91 91 00:03:13,320 --> 00:03:15,540 Okay, here's video number two and then video number three 92 92 00:03:15,540 --> 00:03:17,940 and video number four, and that's how this works. 93 93 00:03:17,940 --> 00:03:20,730 So steps one through five is essentially 94 94 00:03:20,730 --> 00:03:23,820 where we're doing this SAML thing and SOAP thing 95 95 00:03:23,820 --> 00:03:24,870 where we're getting the information 96 96 00:03:24,870 --> 00:03:28,140 and sending those assertions over using SAML. 97 97 00:03:28,140 --> 00:03:30,780 Then once you have that in six, seven, and eight 98 98 00:03:30,780 --> 00:03:32,250 we're just going to keep going back and forth 99 99 00:03:32,250 --> 00:03:33,900 with that authenticated session 100 100 00:03:33,900 --> 00:03:36,030 giving you the services you asked for. 101 101 00:03:36,030 --> 00:03:38,520 Now if you want to see what a SAML request string looks like 102 102 00:03:38,520 --> 00:03:40,140 it looks something like this. 103 103 00:03:40,140 --> 00:03:44,913 For instance, here I have idp.diontraining.com/login? 104 104 00:03:45,840 --> 00:03:49,260 SAML request equals and then this encoded string. 105 105 00:03:49,260 --> 00:03:51,960 Now notice this was idp.diontraining.com. 106 106 00:03:51,960 --> 00:03:54,210 Here I'm pretending I am the IdP provider 107 107 00:03:54,210 --> 00:03:57,450 so I would be Google Single sign-on service, for instance. 108 108 00:03:57,450 --> 00:03:59,940 Now, when you do this, it's going to be sent from the user 109 109 00:03:59,940 --> 00:04:03,840 to the identity provider as an HTTP 302 redirect 110 110 00:04:03,840 --> 00:04:05,310 which is what I'm showing here 111 111 00:04:05,310 --> 00:04:08,430 and this is done with the XML request, that part in blue, 112 112 00:04:08,430 --> 00:04:11,610 being encoded as a string as part of the URL, 113 113 00:04:11,610 --> 00:04:14,190 that information that D Z B B A 114 114 00:04:14,190 --> 00:04:16,950 that part, is part of this encoded string 115 115 00:04:16,950 --> 00:04:18,600 and we can actually take that and send that 116 116 00:04:18,600 --> 00:04:21,120 into the identity provider through this form 117 117 00:04:21,120 --> 00:04:23,880 and then they can go and get the assertions for you. 118 118 00:04:23,880 --> 00:04:24,840 Now, what does this look like 119 119 00:04:24,840 --> 00:04:26,940 when you start blowing it up and looking at it? 120 120 00:04:26,940 --> 00:04:29,130 Well, here's a decoded SAML request string 121 121 00:04:29,130 --> 00:04:31,290 and it contains a lot of information in fields 122 122 00:04:31,290 --> 00:04:32,970 as you can see here on the screen. 123 123 00:04:32,970 --> 00:04:34,890 Now, this is simplified for our explanation 124 124 00:04:34,890 --> 00:04:36,360 and the real SAML request string 125 125 00:04:36,360 --> 00:04:38,400 could have a lot of additional fields. 126 126 00:04:38,400 --> 00:04:40,140 The field grouping of data contains things 127 127 00:04:40,140 --> 00:04:41,790 like the protocol that's going to be used 128 128 00:04:41,790 --> 00:04:43,770 the identification to identify the user 129 129 00:04:43,770 --> 00:04:46,500 and a date timestamp when the request was made 130 130 00:04:46,500 --> 00:04:48,960 so we can know if it was expired or valid. 131 131 00:04:48,960 --> 00:04:50,670 You can also see the capability exists 132 132 00:04:50,670 --> 00:04:53,370 to include a digital signature notated by the grouping 133 133 00:04:53,370 --> 00:04:57,240 as DS colon signature in the request towards the bottom. 134 134 00:04:57,240 --> 00:05:00,000 This will be used for non-repudiation to validate the origin 135 135 00:05:00,000 --> 00:05:02,700 and integrity of the SAML request. 136 136 00:05:02,700 --> 00:05:04,080 Once the request is sent 137 137 00:05:04,080 --> 00:05:06,900 the reply is going to come back as an assertion. 138 138 00:05:06,900 --> 00:05:09,300 Now, the assertion is going to look something like this 139 139 00:05:09,300 --> 00:05:10,530 and it may be a little bit hard to read 140 140 00:05:10,530 --> 00:05:13,140 because there's so much data here, but even here 141 141 00:05:13,140 --> 00:05:15,420 I've simplified it down for our use. 142 142 00:05:15,420 --> 00:05:18,480 This is a response, and you can see here in the second line 143 143 00:05:18,480 --> 00:05:21,570 that it has an ID value, in this case, 200 144 144 00:05:21,570 --> 00:05:22,890 as well as a date and timestamp 145 145 00:05:22,890 --> 00:05:25,470 to prevent an expired one from being used. 146 146 00:05:25,470 --> 00:05:27,240 Notice at the end of the third line, 147 147 00:05:27,240 --> 00:05:30,840 it says it's in response to, and then an ID number. 148 148 00:05:30,840 --> 00:05:32,280 If you noticed in our request, 149 149 00:05:32,280 --> 00:05:34,680 it identified itself as request 100. 150 150 00:05:34,680 --> 00:05:39,150 Now we're replying back as an assertion for request 100. 151 151 00:05:39,150 --> 00:05:41,250 Now, towards the lower half of this assertion 152 152 00:05:41,250 --> 00:05:43,500 you'll start seeing where we have the subject, 153 153 00:05:43,500 --> 00:05:45,240 the conditions, the restrictions, 154 154 00:05:45,240 --> 00:05:47,760 and the attributes associated with that user 155 155 00:05:47,760 --> 00:05:49,680 that the reply is being sent on behalf of. 156 156 00:05:49,680 --> 00:05:52,110 These are the assertions that are being made. 157 157 00:05:52,110 --> 00:05:53,250 These are all the different things 158 158 00:05:53,250 --> 00:05:54,630 that we know about this user, 159 159 00:05:54,630 --> 00:05:56,970 and we as the identity provider can tell 160 160 00:05:56,970 --> 00:05:59,160 the service provider what they should know 161 161 00:05:59,160 --> 00:06:00,633 about this particular user. 162 162 00:06:01,470 --> 00:06:03,750 Now, the signature here is going to be verified 163 163 00:06:03,750 --> 00:06:05,310 and a session is going to be established 164 164 00:06:05,310 --> 00:06:07,830 once that response is received by the service provider. 165 165 00:06:07,830 --> 00:06:10,110 So as a service provider, I get those assertions 166 166 00:06:10,110 --> 00:06:12,870 I look at it, I verify that digital signature 167 167 00:06:12,870 --> 00:06:15,240 and I say, yep, that looks good to me. 168 168 00:06:15,240 --> 00:06:16,440 Now I'm going to create a session 169 169 00:06:16,440 --> 00:06:19,710 with the end user and start fulfilling those requests. 170 170 00:06:19,710 --> 00:06:21,900 Now for the exam, it is unlikely 171 171 00:06:21,900 --> 00:06:24,270 that you're going to get questions that dive deep into SAML 172 172 00:06:24,270 --> 00:06:26,670 and how it works, but in the real world 173 173 00:06:26,670 --> 00:06:29,100 this is a concept you should be familiar with. 174 174 00:06:29,100 --> 00:06:31,890 Now, many web services rely on identity providers 175 175 00:06:31,890 --> 00:06:34,680 as part of a federated identity management program 176 176 00:06:34,680 --> 00:06:37,680 and that all relies on SOAP and SAML. 177 177 00:06:37,680 --> 00:06:40,140 By understanding how it works, you can better understand 178 178 00:06:40,140 --> 00:06:42,870 if an attacker is trying to exploit the trust relationships 179 179 00:06:42,870 --> 00:06:45,450 between that service provider and the identity provider 180 180 00:06:45,450 --> 00:06:48,060 by spoofing or modifying these SAML requests 181 181 00:06:48,060 --> 00:06:49,350 and those response messages 182 182 00:06:49,350 --> 00:06:51,350 and assertions that come back from them.