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