1
00:00:17,080 --> 00:00:21,390
ALAN COHEN: OK. Can everyone hear me? Raise
your hand if,

2
00:00:21,390 --> 00:00:25,160
yeah? Cool. This is my first talk, so I'm
a little bit

3
00:00:25,160 --> 00:00:31,220
nervous. I'm gonna, actually, take a picture
for my mom.

4
00:00:31,220 --> 00:00:38,220
So, if everyone can, like, wave. Awesome.
Yes. All right.

5
00:00:42,070 --> 00:00:49,070
All right. Cool. So, my talk is about authorization.

6
00:00:49,360 --> 00:00:55,089
Service-oriented authorization. My name is
Alan, by the way.

7
00:00:55,089 --> 00:00:59,440
You can find me on Twitter and GitHub.

8
00:00:59,440 --> 00:01:04,119
I work at a company called The Climate Corporation.

9
00:01:04,119 --> 00:01:07,010
I'm a Ruby developer there. I've been there
for

10
00:01:07,010 --> 00:01:10,080
about a year and a half working on, we

11
00:01:10,080 --> 00:01:12,400
have an insurance product, I work on the backend

12
00:01:12,400 --> 00:01:16,939
as well as other parts of our web infrastructure.

13
00:01:16,939 --> 00:01:22,720
We have products that help protect farmers
from weather

14
00:01:22,720 --> 00:01:27,550
disasters and improve their farming operations
during the planting

15
00:01:27,550 --> 00:01:31,610
and, before and after the planting season.
It's sort

16
00:01:31,610 --> 00:01:34,220
of like, if I'm gonna make it, like, buzz-word

17
00:01:34,220 --> 00:01:37,580
compliant, it's big data farming.

18
00:01:37,580 --> 00:01:40,780
So, a little bit of background before I get

19
00:01:40,780 --> 00:01:46,710
into my talk. What is authorization? So, if
you

20
00:01:46,710 --> 00:01:50,730
were in this room before, you probably learned
about

21
00:01:50,730 --> 00:01:55,500
authentication in a service, service-oriented
environment. Today I'm talking

22
00:01:55,500 --> 00:02:02,500
authorization. So, authentication is concerned
with identity. Authorization is

23
00:02:03,920 --> 00:02:07,740
concerned with access.

24
00:02:07,740 --> 00:02:10,280
There are different types of authorization.
If you've ever

25
00:02:10,280 --> 00:02:15,450
implemented it. You can think about role-based
access control,

26
00:02:15,450 --> 00:02:20,260
attribute-based access control, access control
lists, rule-based access control.

27
00:02:20,260 --> 00:02:22,810
It can go on and on. I'm not talking

28
00:02:22,810 --> 00:02:27,720
about a specific implementation of authorization,
but just, in

29
00:02:27,720 --> 00:02:30,490
general, right.

30
00:02:30,490 --> 00:02:34,150
What is service oriented architecture? Right.
There's been many,

31
00:02:34,150 --> 00:02:36,100
many talks. I think this entire track is on

32
00:02:36,100 --> 00:02:40,200
service oriented architecture. And, you know,
there's been talks

33
00:02:40,200 --> 00:02:43,280
yesterday. I've gone to a few of these talks.

34
00:02:43,280 --> 00:02:48,750
I, they, service oriented architecture is
many different solutions

35
00:02:48,750 --> 00:02:51,090
to different problems. But, you know, it's
around the

36
00:02:51,090 --> 00:02:53,380
same theme, I guess.

37
00:02:53,380 --> 00:02:55,780
This, where I'm not talking about a specific
implementation

38
00:02:55,780 --> 00:02:59,890
of SOA, so I want to find a really

39
00:02:59,890 --> 00:03:03,120
basic definition of it, and I found this.
A

40
00:03:03,120 --> 00:03:07,240
loosely-coupled architecture designed to meet
the business needs of

41
00:03:07,240 --> 00:03:10,510
an organization. I found this on the Microsoft
Developer

42
00:03:10,510 --> 00:03:13,349
Network site. And it also had this, like,
really

43
00:03:13,349 --> 00:03:17,459
interesting quote. And it started with, SOAs
are like

44
00:03:17,459 --> 00:03:22,400
snowflakes. No two are alike.

45
00:03:22,400 --> 00:03:23,590
But I wanted to find like a, a better

46
00:03:23,590 --> 00:03:27,099
definition. And actually, when I was watching
Brian Morton's

47
00:03:27,099 --> 00:03:32,610
talk from Big Rails, Big Ruby last year, Rails,

48
00:03:32,610 --> 00:03:34,819
Services and Rails, The Shit They Don't Tell
You.

49
00:03:34,819 --> 00:03:38,150
He says, Components that scale individually.
That's sort of

50
00:03:38,150 --> 00:03:41,840
how he defines service oriented architecture.

51
00:03:41,840 --> 00:03:44,069
And I, I recommend that talk, if you want

52
00:03:44,069 --> 00:03:48,410
to learn about implementing service oriented
architecture. Some services

53
00:03:48,410 --> 00:03:51,349
oriented architecture, from someone who has
the battle scars

54
00:03:51,349 --> 00:03:55,030
moving over to something like that. But today,
I'm

55
00:03:55,030 --> 00:04:01,400
not, I'm not, like, focusing on what it is.

56
00:04:01,400 --> 00:04:08,400
So, why talk about it? Right. Why, why services

57
00:04:08,540 --> 00:04:12,069
oriented architecture? We have to und- you
know, before

58
00:04:12,069 --> 00:04:14,200
we get into authorization, I want to talk
a

59
00:04:14,200 --> 00:04:18,099
little bit about why we would use SOA. SOA

60
00:04:18,099 --> 00:04:21,798
gives us a lot of things, right. Reusability,
we

61
00:04:21,798 --> 00:04:25,080
can allocate resources as we need them, loose
coupling,

62
00:04:25,080 --> 00:04:28,190
we can change out libraries, a codebase that
scales

63
00:04:28,190 --> 00:04:30,800
across teams and so, we get, we get things

64
00:04:30,800 --> 00:04:33,210
that are good for both our software and for

65
00:04:33,210 --> 00:04:36,129
our software development process.

66
00:04:36,129 --> 00:04:37,400
There are a lot of problems, also, right,
that

67
00:04:37,400 --> 00:04:39,180
you have to solve when you have a service

68
00:04:39,180 --> 00:04:42,339
oriented architecture. Right, services speaking
to one another. Like,

69
00:04:42,339 --> 00:04:46,229
a lot of things become difficult. But hopefully
you're

70
00:04:46,229 --> 00:04:50,860
here because the, the benefits of SOA outweigh
the

71
00:04:50,860 --> 00:04:53,960
problems that you might have. And you've already
sort

72
00:04:53,960 --> 00:04:55,759
of made that decision. I'm not gonna try to

73
00:04:55,759 --> 00:04:57,550
sell you on it.

74
00:04:57,550 --> 00:05:02,050
So, what is service oriented authorization?
Well, if we

75
00:05:02,050 --> 00:05:06,180
think about the benefits of services oriented
architecture, it

76
00:05:06,180 --> 00:05:11,169
should be sort of parallel to that. Reusability,
I

77
00:05:11,169 --> 00:05:13,620
want to be able to use the, the same

78
00:05:13,620 --> 00:05:20,620
authorization tools, libraries, code, across
multiple services. Loose coupling.

79
00:05:21,360 --> 00:05:25,499
My application code is not coupled to my authorization

80
00:05:25,499 --> 00:05:31,930
implementation. And then, lastly, scalability.
So, this is like

81
00:05:31,930 --> 00:05:35,830
a requirement when you have multiple services.
And this

82
00:05:35,830 --> 00:05:37,749
is just gonna be like a general requirement
when

83
00:05:37,749 --> 00:05:39,779
we talk about, like, the framework that I
want

84
00:05:39,779 --> 00:05:41,879
to use.

85
00:05:41,879 --> 00:05:45,710
So, let's imagine a typical Rails application,
ignoring things

86
00:05:45,710 --> 00:05:50,569
like the database and other third-party services.
You have

87
00:05:50,569 --> 00:05:53,259
your, you have Rails, you have your business
logic,

88
00:05:53,259 --> 00:05:55,680
and then you have some third-party gems that
you

89
00:05:55,680 --> 00:05:58,779
might use.

90
00:05:58,779 --> 00:06:01,639
The important part is your business logic,
right. That's,

91
00:06:01,639 --> 00:06:04,729
like, if you have an online product, like
BaseCamp,

92
00:06:04,729 --> 00:06:08,110
right, that's the interesting stuff. That's
the part that's

93
00:06:08,110 --> 00:06:10,430
gonna make you money. It's what, why your
cosumer's

94
00:06:10,430 --> 00:06:12,819
pay you money. Everything else is just there
to

95
00:06:12,819 --> 00:06:16,539
help you deliver that product.

96
00:06:16,539 --> 00:06:18,909
I think authorization can be thought of as
part

97
00:06:18,909 --> 00:06:21,779
of your business. Whether it's part of the
security

98
00:06:21,779 --> 00:06:25,349
of your application, for example, like, you
have employees

99
00:06:25,349 --> 00:06:28,360
that, only your employees are allowed to administer
customer

100
00:06:28,360 --> 00:06:31,379
data, like, for customer support. Or, whether
it's part

101
00:06:31,379 --> 00:06:33,759
of the feature of your application. Like,
in BaseCamp,

102
00:06:33,759 --> 00:06:38,839
you have, like admin users in different groups.

103
00:06:38,839 --> 00:06:42,599
So, what does authorization look like today?
I think,

104
00:06:42,599 --> 00:06:47,330
you know, the most popular authorization library
is -

105
00:06:47,330 --> 00:06:49,699
I don't know if you can see this -

106
00:06:49,699 --> 00:06:51,639
but, this is like a snapshot of CanCan's GitHub's

107
00:06:51,639 --> 00:06:57,649
page. I think it's probably the most popular
authorization

108
00:06:57,649 --> 00:07:01,159
gem. We use it in production. It works. It's

109
00:07:01,159 --> 00:07:04,240
historically been well-supported. I think
it's still pretty good.

110
00:07:04,240 --> 00:07:07,949
But, you know, it gives you, like, a really

111
00:07:07,949 --> 00:07:13,300
nice declarative DSL for specifying rules,
like, so then,

112
00:07:13,300 --> 00:07:15,610
you specify your rules, like, within your
application, and

113
00:07:15,610 --> 00:07:19,069
it's, like, nice Ruby DSL. And then you can

114
00:07:19,069 --> 00:07:21,849
ask questions like, can a user manage this
other

115
00:07:21,849 --> 00:07:25,219
user's data. Can a user purchase a policy,
if

116
00:07:25,219 --> 00:07:26,779
you're selling insurance.

117
00:07:26,779 --> 00:07:30,619
But the question is, does this approach align
with

118
00:07:30,619 --> 00:07:37,339
what we've defined as service oriented authorization?
Right. CanCan

119
00:07:37,339 --> 00:07:40,020
is reusable, right, because it's a library.
So, you

120
00:07:40,020 --> 00:07:43,409
know, the authorization implementation is
decoupled from our app.

121
00:07:43,409 --> 00:07:47,469
We don't, like, bake authorization into our
app.

122
00:07:47,469 --> 00:07:50,889
But it's, it's not really loosely coupled,
right. If

123
00:07:50,889 --> 00:07:53,619
you think about it, your authorization rules
are, are

124
00:07:53,619 --> 00:07:57,889
embedded in your application code, right.
So like, the,

125
00:07:57,889 --> 00:08:03,959
the. What is it? Yeah. The, your rules are

126
00:08:03,959 --> 00:08:06,770
in your application. And there's some limitations
to this

127
00:08:06,770 --> 00:08:11,059
approach, which aren't apparent at first,
right.

128
00:08:11,059 --> 00:08:13,879
And, so what? Like, what are those limitations?
Or,

129
00:08:13,879 --> 00:08:17,639
why does that matter? Well, I think that if

130
00:08:17,639 --> 00:08:20,089
we want to keep the core of our application

131
00:08:20,089 --> 00:08:23,289
small and understandable as possible, we want
to, we

132
00:08:23,289 --> 00:08:24,419
want to do that because that's the part that

133
00:08:24,419 --> 00:08:27,149
makes us money. The business logic is what's
important.

134
00:08:27,149 --> 00:08:28,159
And it's the part we want to keep free

135
00:08:28,159 --> 00:08:30,949
of bugs. If we, if we do that, we

136
00:08:30,949 --> 00:08:34,880
can develop with confidence, like we know
we won't

137
00:08:34,880 --> 00:08:40,149
develop and create bugs. Our business logic
is concerned

138
00:08:40,149 --> 00:08:43,320
with authorization only as far as we need
to

139
00:08:43,320 --> 00:08:45,560
make sure to enforce it. But we shouldn't
care

140
00:08:45,560 --> 00:08:48,950
about how it's implemented, but just that
it works.

141
00:08:48,950 --> 00:08:51,940
So, this is your business logic. This is you

142
00:08:51,940 --> 00:08:57,650
enforcing authorization in your code. But
the rest is,

143
00:08:57,650 --> 00:09:00,680
I think, can, should be thought of as implementation

144
00:09:00,680 --> 00:09:04,410
details, right. Where you define those rules.
It doesn't

145
00:09:04,410 --> 00:09:06,810
necessarily need to be part of your system.
It

146
00:09:06,810 --> 00:09:08,280
needs to exist somewhere.

147
00:09:08,280 --> 00:09:13,820
And I'll explain why, why that matters, right.
So,

148
00:09:13,820 --> 00:09:16,430
in a services oriented architecture, right,
you usually start

149
00:09:16,430 --> 00:09:21,530
with a monolithic application. And if we've
coupled our

150
00:09:21,530 --> 00:09:23,680
rules to our application, then it's gonna
be very

151
00:09:23,680 --> 00:09:28,990
difficult to split things into services, right.
Especially if

152
00:09:28,990 --> 00:09:33,820
there, all these services are concerned with
a user.

153
00:09:33,820 --> 00:09:37,240
You have all these user rules in your, in

154
00:09:37,240 --> 00:09:40,110
your monoRails app, but now they sort of have

155
00:09:40,110 --> 00:09:42,070
to be broken out. And that's fine if you're

156
00:09:42,070 --> 00:09:46,260
gonna use, right, CanCan across these different
Ruby or

157
00:09:46,260 --> 00:09:51,570
Rails applications. But a services oriented
architecture usually, by

158
00:09:51,570 --> 00:09:56,700
default, means you're gonna have, like, a
heterogenous environment.

159
00:09:56,700 --> 00:09:58,620
And this is actually very similar to what
we

160
00:09:58,620 --> 00:10:01,210
have in production today, where we don't just
have

161
00:10:01,210 --> 00:10:03,880
the Rails stack. We have other, other things,
either

162
00:10:03,880 --> 00:10:06,030
in Java or Clojure or whatever it might be

163
00:10:06,030 --> 00:10:09,660
in the future. And, there really isn't an
easy

164
00:10:09,660 --> 00:10:14,350
way to go from CanCan to Clojure, right.

165
00:10:14,350 --> 00:10:20,040
So, we want to, we want to think about

166
00:10:20,040 --> 00:10:22,960
a different framework to, to basically do
this. So,

167
00:10:22,960 --> 00:10:25,740
what are the goals of whatever approach we
take?

168
00:10:25,740 --> 00:10:29,620
Well, the goal, goals, you know, restating
them. Reusability,

169
00:10:29,620 --> 00:10:32,110
scalability, and loose coupling.

170
00:10:32,110 --> 00:10:36,400
So, let's go back to our app, right. We

171
00:10:36,400 --> 00:10:39,880
have the same Rails app, but it's, it's very

172
00:10:39,880 --> 00:10:43,900
simplified. Your app, when you move it onto
different

173
00:10:43,900 --> 00:10:47,530
services, might look like this, where you
have different

174
00:10:47,530 --> 00:10:50,690
JavaScript frontends that are, you know, we
deploy them

175
00:10:50,690 --> 00:10:53,260
as different modules. Our users like see a
single

176
00:10:53,260 --> 00:10:57,890
interface, but really it's several different,
several different applications

177
00:10:57,890 --> 00:11:01,720
that are speaking to several different backends.

178
00:11:01,720 --> 00:11:06,320
And the business logic that used to reside
in

179
00:11:06,320 --> 00:11:10,520
a single application now is residing across
multiple applications,

180
00:11:10,520 --> 00:11:17,520
and those, yeah. So, the, the key take away

181
00:11:17,730 --> 00:11:21,750
is that this is a heterogenous environment,
and so

182
00:11:21,750 --> 00:11:26,060
we shouldn't constrain ourselves, right, by
language or run

183
00:11:26,060 --> 00:11:27,820
time. We want to use the best possible tools

184
00:11:27,820 --> 00:11:31,610
to, to grow our services, to build them.

185
00:11:31,610 --> 00:11:35,010
So, reusability means we want code that doesn't
require

186
00:11:35,010 --> 00:11:40,010
us to predict the future. And, if I'm gonna

187
00:11:40,010 --> 00:11:45,350
extract my authorization into another service
or, part of

188
00:11:45,350 --> 00:11:47,570
my authorization into a separate service,
like, I need,

189
00:11:47,570 --> 00:11:50,430
I need to be able to do that without,

190
00:11:50,430 --> 00:11:52,470
without having to rewrite it. I don't want
to

191
00:11:52,470 --> 00:11:57,200
have to rewrite everything.

192
00:11:57,200 --> 00:12:00,800
And that's, loose coupling means, like, that,
we, we're

193
00:12:00,800 --> 00:12:04,970
gonna decouple the access decision from the
access policy.

194
00:12:04,970 --> 00:12:11,590
So, just, restating, restating that, we can't
use this,

195
00:12:11,590 --> 00:12:16,100
right, outside of a, outside of our Rails
application.

196
00:12:16,100 --> 00:12:20,700
We also need whatever framework to be scalable.
So,

197
00:12:20,700 --> 00:12:23,450
there's, you know, when I was researching
this and

198
00:12:23,450 --> 00:12:25,560
I was like, what are, what are the available

199
00:12:25,560 --> 00:12:29,420
tools to be able to do something like this?

200
00:12:29,420 --> 00:12:33,470
And I didn't really find anything. I did find,

201
00:12:33,470 --> 00:12:36,730
of this, of this thing called XACML. I mean,

202
00:12:36,730 --> 00:12:38,090
raise your hand if you've heard of XACML.

203
00:12:38,090 --> 00:12:41,780
Yeah. So I see, like, maybe ten people have

204
00:12:41,780 --> 00:12:46,230
raised your hand. So XACML is, it's XML, and

205
00:12:46,230 --> 00:12:50,440
it stands for extensible access control markup
language. And

206
00:12:50,440 --> 00:12:54,310
it's a declarative policy language implemented
in XML. And

207
00:12:54,310 --> 00:12:57,690
it defines a processing model that describes
how to

208
00:12:57,690 --> 00:13:02,210
evaluate access requests according to rules
defined and policies.

209
00:13:02,210 --> 00:13:03,930
So it actually, if you read the spec it's,

210
00:13:03,930 --> 00:13:05,750
I think like hundreds of pages long, and it

211
00:13:05,750 --> 00:13:10,320
actually defines an entire architecture using
XML to define

212
00:13:10,320 --> 00:13:12,960
authorization rules and sort of like, all
these different

213
00:13:12,960 --> 00:13:16,110
services to implement authorization. And that,
in fact, it

214
00:13:16,110 --> 00:13:19,670
uses a centralized authorization service,
and it's pretty, it's

215
00:13:19,670 --> 00:13:21,670
pretty complex, I think.

216
00:13:21,670 --> 00:13:24,030
But, I found this from a spec, and I

217
00:13:24,030 --> 00:13:28,590
thought this was actually really poignant.
The XACML model

218
00:13:28,590 --> 00:13:32,430
supports and encourages the separation of
the access decision

219
00:13:32,430 --> 00:13:34,920
from the point of use.

220
00:13:34,920 --> 00:13:38,400
When access decisions are baked into client
applications, it

221
00:13:38,400 --> 00:13:41,180
is very difficult to update the decision criteria
when

222
00:13:41,180 --> 00:13:44,760
the governing policy changes. When the client
is decoupled

223
00:13:44,760 --> 00:13:49,790
from the access decision, authorization policies
can be updated

224
00:13:49,790 --> 00:13:53,240
on the fly and affect all clients immediately.

225
00:13:53,240 --> 00:13:59,150
So, this is what an XACML policy would look

226
00:13:59,150 --> 00:14:02,670
like. I got the indenting wrong, but, I mean,

227
00:14:02,670 --> 00:14:06,070
you get the idea. It's, it's pretty complex,
but

228
00:14:06,070 --> 00:14:08,480
it gives us this advantage of being able to

229
00:14:08,480 --> 00:14:10,840
update and modify the rules without touching
our application

230
00:14:10,840 --> 00:14:14,870
code, and so it should, we should be able

231
00:14:14,870 --> 00:14:18,230
to use this in sort of a hit, in

232
00:14:18,230 --> 00:14:20,870
a heterogenous environment. As long as we
have some

233
00:14:20,870 --> 00:14:24,490
authorization library that we can use within
our application.

234
00:14:24,490 --> 00:14:28,570
But, I thought that this is, this is, like,

235
00:14:28,570 --> 00:14:30,940
way too much for, for what we needed, right.

236
00:14:30,940 --> 00:14:33,930
Like, we, like, we don't have thousands and
thousands

237
00:14:33,930 --> 00:14:36,779
of rules. Our application is actually fairly
simple compared

238
00:14:36,779 --> 00:14:41,070
to the implementations I've seen for this.
So, I

239
00:14:41,070 --> 00:14:44,240
wanted to, to, you know, try something a little

240
00:14:44,240 --> 00:14:47,800
bit simpler, right.

241
00:14:47,800 --> 00:14:54,800
Thing is, I didn't, I didn't really find anything

242
00:14:55,090 --> 00:15:00,190
simpler. So, when, when we were discussing
this authorization

243
00:15:00,190 --> 00:15:03,710
framework that I'm gonna go over, we, we thought,

244
00:15:03,710 --> 00:15:05,240
like, all right, let's, let's come up with
a

245
00:15:05,240 --> 00:15:07,560
very simple language that we can use and,
you

246
00:15:07,560 --> 00:15:08,850
know, as we, as we build this out, as

247
00:15:08,850 --> 00:15:11,400
we test it, we can, we can experiment with

248
00:15:11,400 --> 00:15:14,150
it, and if we need to bake more features

249
00:15:14,150 --> 00:15:17,620
into it, let's do that. But let's, let's,
let's

250
00:15:17,620 --> 00:15:20,210
implement as few features as we need as possible.

251
00:15:20,210 --> 00:15:22,870
And, so that's where we started.

252
00:15:22,870 --> 00:15:26,230
So, just a recap: we talked a little bit

253
00:15:26,230 --> 00:15:31,350
about why would we choose SOA architecture.
What SOA

254
00:15:31,350 --> 00:15:33,910
might be. And we set our goals to be

255
00:15:33,910 --> 00:15:37,460
scalability, flexibility, and loose coupling.
And we talked about

256
00:15:37,460 --> 00:15:39,090
why we chose these three goals. Like, what
are

257
00:15:39,090 --> 00:15:40,610
their benefits.

258
00:15:40,610 --> 00:15:45,150
So, what, like, what did we come up with?

259
00:15:45,150 --> 00:15:47,550
And, I guess, I didn't, I didn't really talk

260
00:15:47,550 --> 00:15:50,580
about, like, what this is. What this framework
is.

261
00:15:50,580 --> 00:15:52,850
But, you know, I worked, I worked with a

262
00:15:52,850 --> 00:15:54,450
few guys in my company. We said all right.

263
00:15:54,450 --> 00:15:57,529
Let's, let's build this, it's, it's not really
a

264
00:15:57,529 --> 00:16:00,160
framework. It's more like let's, let's define
a language

265
00:16:00,160 --> 00:16:04,320
where we can, we can define authorization
policies, and

266
00:16:04,320 --> 00:16:07,930
it's really, it's agnostic to, to Rails, whatever
it

267
00:16:07,930 --> 00:16:11,580
is, and let's, let's try to create, like,
a

268
00:16:11,580 --> 00:16:15,100
reference implementation and experiment with
it. And then see

269
00:16:15,100 --> 00:16:17,310
if it's, if this is a rich enough language

270
00:16:17,310 --> 00:16:19,760
to be able to use and replace whatever we

271
00:16:19,760 --> 00:16:21,250
have today.

272
00:16:21,250 --> 00:16:25,170
So, this is, this is sort of, like, this

273
00:16:25,170 --> 00:16:27,589
is the like, the v zero dot one alpha

274
00:16:27,589 --> 00:16:29,880
of the language, right. We don't, there's
not like

275
00:16:29,880 --> 00:16:31,990
an official spec that we, you know, we have

276
00:16:31,990 --> 00:16:35,460
a very, like, early spec for this, and this

277
00:16:35,460 --> 00:16:40,210
is sort of like what we came up with.

278
00:16:40,210 --> 00:16:42,920
And I'll go through, like, each, each object
in

279
00:16:42,920 --> 00:16:47,130
this, in this, in this JSON. So, we have

280
00:16:47,130 --> 00:16:52,230
a resource. A resource could be defined within
a

281
00:16:52,230 --> 00:16:54,360
namespace, and so it could also be like, just

282
00:16:54,360 --> 00:16:56,410
the name of a class. So like, if it's

283
00:16:56,410 --> 00:16:58,500
a Rails application, it could be like an ActiveRecord

284
00:16:58,500 --> 00:17:03,650
model. An action, or a set of actions. So,

285
00:17:03,650 --> 00:17:05,859
a rule will apply to a set of actions,

286
00:17:05,859 --> 00:17:08,439
just like in CanCan, you sort of do the

287
00:17:08,439 --> 00:17:11,630
same thing.

288
00:17:11,630 --> 00:17:14,809
You have a set of conditions that define the

289
00:17:14,809 --> 00:17:19,359
evaluation context of a rule. So, whether
a rule

290
00:17:19,359 --> 00:17:24,279
applies or not. So, in this case, this is

291
00:17:24,279 --> 00:17:27,490
like, how we would say, like, the, the role

292
00:17:27,490 --> 00:17:34,110
of a user must equal admin. So, if we're,

293
00:17:34,110 --> 00:17:35,090
right.

294
00:17:35,090 --> 00:17:37,850
And then every rule will have an effect. So

295
00:17:37,850 --> 00:17:41,320
it'll be either allow or deny. So we have

296
00:17:41,320 --> 00:17:46,919
this language. But, something is missing.
And that's, what's

297
00:17:46,919 --> 00:17:49,659
sort of bridging that gap, right. We have
an

298
00:17:49,659 --> 00:17:52,389
application. Now we have a set of rules. Like,

299
00:17:52,389 --> 00:17:54,049
what's, what's connecting the two?

300
00:17:54,049 --> 00:17:57,129
And so, right, I wrote this really small gem,

301
00:17:57,129 --> 00:18:01,710
and it's called IronHide. And, we just have
this

302
00:18:01,710 --> 00:18:05,029
practice of naming all of our gems at work

303
00:18:05,029 --> 00:18:11,070
after Transformer characters. So, IronHide
is this, is sort

304
00:18:11,070 --> 00:18:13,639
of this bridge. We define a set of rules,

305
00:18:13,639 --> 00:18:16,190
and we have our application, and then we include

306
00:18:16,190 --> 00:18:20,360
IronHide into our application, and IronHide
exposes the same

307
00:18:20,360 --> 00:18:23,389
API that CanCan would, and so it's sort of

308
00:18:23,389 --> 00:18:24,289
like a drop-in.

309
00:18:24,289 --> 00:18:29,159
And, so like, what is it? It's not a

310
00:18:29,159 --> 00:18:32,600
service. It doesn't provide an authorization
service for us.

311
00:18:32,600 --> 00:18:35,320
It's actually just a library. So, that, that's
an

312
00:18:35,320 --> 00:18:41,570
important distinction, because we're, you
know, where are the

313
00:18:41,570 --> 00:18:44,389
rules, right? If it's not a service, then
it's

314
00:18:44,389 --> 00:18:45,990
gonna have to call out and get the rules

315
00:18:45,990 --> 00:18:46,850
from somewhere.

316
00:18:46,850 --> 00:18:49,499
And that's, that's actually pretty cool, because
we can

317
00:18:49,499 --> 00:18:51,169
store the rules anywhere we want, right. They're
just,

318
00:18:51,169 --> 00:18:54,539
it's just JSON. So, JSON can really be stored

319
00:18:54,539 --> 00:18:55,990
anywhere. It can be stored, like, on, on disc.

320
00:18:55,990 --> 00:19:00,299
It can be stored in the document store. And

321
00:19:00,299 --> 00:19:05,999
having this, like, plugability to different
backend stores gives

322
00:19:05,999 --> 00:19:07,029
us scalability.

323
00:19:07,029 --> 00:19:13,869
So, does it meet our goals? Right. Reusability,
scalability,

324
00:19:13,869 --> 00:19:19,529
loose coupling. The authorization rules are
not part of

325
00:19:19,529 --> 00:19:25,679
the application code. The, the language in
which we

326
00:19:25,679 --> 00:19:29,259
define the rules is language agnostic. So
it should

327
00:19:29,259 --> 00:19:35,840
be reusable across, across environments. And,
if we've decoupled

328
00:19:35,840 --> 00:19:39,100
the backing store from the authorization implementation,
then it

329
00:19:39,100 --> 00:19:40,480
should be as scalable as we want it to

330
00:19:40,480 --> 00:19:41,889
be.

331
00:19:41,889 --> 00:19:45,909
So, today, it's still a work in progress.
It's

332
00:19:45,909 --> 00:19:50,009
still something that we're experimenting with,
right. You know.

333
00:19:50,009 --> 00:19:53,090
XACML is like, it's a very well-defined spec.
I

334
00:19:53,090 --> 00:19:55,100
think it's like version three point 0 of the

335
00:19:55,100 --> 00:20:00,179
spec. It's, it's sort of like an enterprise-level
design.

336
00:20:00,179 --> 00:20:03,749
This is like, you know, we're experimenting
with it.

337
00:20:03,749 --> 00:20:06,499
You know. Could it scale to thousands and
thousands

338
00:20:06,499 --> 00:20:08,419
of rules and to like, many, many services?
I

339
00:20:08,419 --> 00:20:09,990
don't know yet. Right.

340
00:20:09,990 --> 00:20:13,769
It's not yet in production. But, and it's
also

341
00:20:13,769 --> 00:20:16,749
something that, you know, we need to standardize
and

342
00:20:16,749 --> 00:20:19,489
name the policy language. Right. There's no
name for

343
00:20:19,489 --> 00:20:26,489
it. Like, so. I'd like to actually do a

344
00:20:26,840 --> 00:20:33,840
demo. So. Let's see if this works.

345
00:20:38,999 --> 00:20:45,999
Where is this? Can everyone see that? No.
If

346
00:20:54,639 --> 00:20:56,549
I make the. Too small?

347
00:20:56,549 --> 00:20:58,639
AUDIENCE: We can't see the font.

348
00:20:58,639 --> 00:21:05,639
A.C.: Can't see-? Oh, yeah. Would it, would
it

349
00:21:09,720 --> 00:21:11,820
be better if I made the background light and

350
00:21:11,820 --> 00:21:12,749
the foreground dark?

351
00:21:12,749 --> 00:21:13,460
AUDIENCE: No.

352
00:21:13,460 --> 00:21:17,440
A.C.: No. OK. Right. So, so this is, like,

353
00:21:17,440 --> 00:21:19,389
this is a rule, right. It's, and it's, and

354
00:21:19,389 --> 00:21:22,730
this is, and I've written this just directly
into

355
00:21:22,730 --> 00:21:26,029
a flat file on my disc. So there's some

356
00:21:26,029 --> 00:21:31,129
resource under this app namespace, a set of
actions.

357
00:21:31,129 --> 00:21:36,779
An effect and a set of conditions.

358
00:21:36,779 --> 00:21:42,710
And then, I actually made, like, a really
simple

359
00:21:42,710 --> 00:21:45,239
-it's not an app. It's just. I created a

360
00:21:45,239 --> 00:21:50,769
user class. It has a manager id and an

361
00:21:50,769 --> 00:21:55,889
id. And if you look at the, right, if

362
00:21:55,889 --> 00:21:59,179
you look at the rule, I'm saying that a

363
00:21:59,179 --> 00:22:04,179
user, it's allowed to read or manage another
user.

364
00:22:04,179 --> 00:22:06,889
In this case, the resource is also a user.

365
00:22:06,889 --> 00:22:10,169
So, we're always authorizing against the
user. So, the

366
00:22:10,169 --> 00:22:12,549
user is allowed to do something to another
thing.

367
00:22:12,549 --> 00:22:15,179
And in this case it's another user.

368
00:22:15,179 --> 00:22:16,919
As long as the user's id is equal to

369
00:22:16,919 --> 00:22:23,919
the other thing's manager id. So, here, we
have

370
00:22:24,210 --> 00:22:27,590
a user with a manager. I'm gonna run this

371
00:22:27,590 --> 00:22:31,019
and then jump directly into the console, so
I

372
00:22:31,019 --> 00:22:34,539
can, like, start writing code.

373
00:22:34,539 --> 00:22:41,539
Oh. OK. So, right. I can, I can. Let's

374
00:22:56,529 --> 00:23:03,529
see. User. Right. So, this. This user has
a

375
00:23:10,820 --> 00:23:17,820
manager id now that's equal to the manager's
id.

376
00:23:19,090 --> 00:23:22,960
And then. I didn't, I didn't really go into

377
00:23:22,960 --> 00:23:25,529
depth, into the IronHide, like, library, but
I'm gonna

378
00:23:25,529 --> 00:23:28,889
post a link to the source. I've tried to

379
00:23:28,889 --> 00:23:31,769
write a pretty well-documented README.

380
00:23:31,769 --> 00:23:38,009
So, it should be fairly self-explanatory.
Basically, there's a,

381
00:23:38,009 --> 00:23:45,009
a configuration. Oh. Crap.

382
00:23:58,320 --> 00:24:05,320
OK. And then. So. It's like. It works.

383
00:24:19,940 --> 00:24:26,940
AUDIENCE: [laughter - applause]

384
00:24:27,350 --> 00:24:33,149
A.C.: Yeah. It's actually kind of funny, cause
I

385
00:24:33,149 --> 00:24:35,879
tried recording this, and it was probably
easier doing

386
00:24:35,879 --> 00:24:42,700
it live. I'm gonna try to jump back.

387
00:24:42,700 --> 00:24:49,700
So. So yeah. These, these are links to the

388
00:24:50,139 --> 00:24:52,169
source, so that's like. I tried getting a
short

389
00:24:52,169 --> 00:24:55,539
link for the GitHub page. And there's actually
a

390
00:24:55,539 --> 00:24:59,499
sample app with, sort of like, what, it was

391
00:24:59,499 --> 00:25:01,359
sort of like that, maybe with a few, a

392
00:25:01,359 --> 00:25:05,470
few additional things. And I also wrote, like,
an

393
00:25:05,470 --> 00:25:08,879
adapter that would let you use, like, CouchDB
as

394
00:25:08,879 --> 00:25:10,850
the backing store for the rules.

395
00:25:10,850 --> 00:25:13,250
CouchDB's pretty cool. So. It was the first
time

396
00:25:13,250 --> 00:25:14,330
I used it.

397
00:25:17,060 --> 00:25:17,621
OK.

398
00:25:19,200 --> 00:25:20,310
AUDIENCE: [applause]