0:00

This is Software Engineering Radio,

0:02

the podcast for professional developers

0:05

on the web at S.E.

0:07

dash radio.net. S.E. Radio is

0:09

brought to you by the

0:11

I Tripoli Computer Society, by

0:13

I Tripoli software magazine, online

0:16

at computer.org slash software.

0:18

Hi everyone, this is

0:20

Prianka Raguen for Software

0:22

Engineering Radio. And today on

0:25

our show, we're going to be

0:27

discussing the topic, stateless, decoupled authorization

0:29

And for this we have two

0:32

guests Alex Olivier and Emma Rebarram.

0:34

Emma is an entrepreneur and a

0:36

software executive with more than 20

0:39

years of experience in B2B and

0:41

B2C product areas. He is currently

0:43

the co-founder and CEO of Serbos

0:46

and before that he co-founded

0:48

Turkey's largest social network in

0:50

the mid-2000s called yongea.com and

0:52

after that and been in a

0:54

variety of different organizations, one is

0:57

of course Google and Q-bit and

0:59

one of the podcasts he appeared

1:01

on, they called him a serial

1:03

entrepreneur. So I'm going to stick

1:05

with that. And Alex, he's the

1:07

CPO and co-founder at Serbos.

1:09

He has a wide variety

1:11

of roles and experiences, Peter,

1:13

engineer, consultant, tech lead, product

1:15

manager. And there's also this

1:17

one line which says always

1:19

an eye on developer experience.

1:21

So that's great for us

1:23

here at SC radio. He's

1:25

worked on different companies again

1:27

Microsoft Cupid and a myriad

1:29

of startups with focus on

1:31

areas such as authorization, data

1:33

management and security. So welcome

1:35

to the show Emma and Alex. Thank you

1:37

for having us. Yeah. Great. So in

1:39

SE Radio we have done a few

1:41

shows on authorization as well as

1:43

authentication. On episode 492 which I

1:46

just want to call out to

1:48

the listeners we had a show

1:50

on building consistent authorization authorization service.

1:53

mainly on the Google Sanzabar project

1:55

that we talked about and then episode

1:57

406 on the open policy agent. We've

1:59

done a few shows on oath to

2:01

an API authorization. However, since we are

2:03

exploring this topic, again, I think nearly

2:05

after a gap about four years, can

2:08

I pose this question to both of

2:10

you on what is authorization? So, Emma,

2:12

can I start with you? Sure. I

2:14

wouldn't start by saying what it is

2:16

not. Authorization usually comes with its twin

2:18

authentication. And authentication is a fact of

2:21

who you are. Are you who you

2:23

say you are and what roles and

2:25

what attributes you have? That's authentication and

2:27

your directory. And authorization is the fact

2:29

that now we know who you are,

2:31

are you allowed to do a certain

2:34

action or not? And you can think

2:36

about the application of this in many

2:38

things in life as well as in

2:40

software. No, but the fact that you

2:42

can log in doesn't really mean you

2:44

can do every action in any given

2:46

software. And the control mechanism of... What

2:49

are you allowed to do versus not

2:51

is authorization. Great. Yeah, I think there's

2:53

a great good analogy for anyone that's

2:55

taking a flight recently. You got your

2:57

passport, you fly to some exotic location

2:59

for your vacation, you get to their

3:02

passport, you get to their passport control,

3:04

they take your passport, they authenticate it

3:06

to you by comparing your photo and

3:08

your biometrics. It's like cool, Alex has

3:10

arrived, this is his document, but the

3:12

actual decision of whether you're allowed into

3:14

the country or not, is an authorization

3:17

decision, which is based upon. Have you

3:19

got the right visa? What's your immigration

3:21

status? Have you got the right funds?

3:23

Those sort of things. And that's a

3:25

check. Knows who you are, but should

3:27

you actually be allowed in, is the

3:30

difference between authentication and authorization. That's a

3:32

great example. And I think maybe Alex,

3:34

I'll ask you this question. Then a

3:36

lot of literature I see there's this

3:38

term called as an authorization model. Is

3:40

that something that you can describe for

3:43

us and maybe what are the key

3:45

components? Yeah. what decides access to a

3:47

particular system. And the term that I

3:49

imagine most of this audience would be

3:51

familiar with is our back or... role-based

3:53

access control, where your authorization, your access,

3:55

is controlled by whether you have a

3:58

particular role or not. So you must

4:00

be an admin to do certain actions,

4:02

you must be a user to do

4:04

other actions, you must be a subscriber

4:06

to do the download action, you must

4:08

be a subscriber to do the download

4:11

action, let's say. Outback is one that

4:13

probably most people are familiar with. Aback,

4:15

or attribute-based access control, is kind of

4:17

the either the evolution or the superses,

4:19

or the superset, depends on how you

4:21

look, based on attributes. And those could

4:23

be attributes about who you are. It

4:26

could be attributes based upon the resource

4:28

you're accessing. It could be attributes based

4:30

on the context. So where did this

4:32

request come from? Is it from a

4:34

known IP? Don't those kind of rules.

4:36

And there's lots of different components you

4:39

could bring in to decide your access.

4:41

There's other models, such as relationship-based access

4:43

control, where your access is based upon

4:45

what relations you have with a particular

4:47

entity or the resource you're trying to

4:49

access. So there's different ways for approaching

4:51

authorization. and there's use cases for all

4:54

of those and there's some cases where

4:56

doing an attribute base control check is

4:58

more sensible they're doing a relationship based

5:00

or vice versa and so it really

5:02

goes back to as always looking at

5:04

your requirements look at your use cases

5:07

and then picking the model that's best

5:09

for your system and best for your

5:11

requirements aside to your application. I think

5:13

I'm going to come back with a

5:15

question there on that but I think

5:17

it's a good point for me to

5:20

also... discuss a little bit on why

5:22

you think authorization is important for software

5:24

engineering teams. So am I just going

5:26

to give it to you because I

5:28

thought it would be good for you

5:30

to explain this and maybe is there

5:32

something that you can relate to an

5:35

example where things have gone bad because

5:37

authorization was implemented incorrectly. Yeah, you can

5:39

think of many different examples, but also

5:41

there are real life examples of when

5:43

authorization goes wrong or when authorization isn't

5:45

actually taken seriously. A simple one I

5:48

can give you an example of is

5:50

imagine these neo-banks, right? These neo-banks giving

5:52

you a bank account that you can

5:54

actually log in and suddenly you start

5:56

using that bank account for your company.

5:58

and multiple people need access to it

6:00

to be able to do certain things,

6:03

but suddenly because there is no rolls

6:05

and permissions or limitations that have been

6:07

in these user accounts, everybody is capable

6:09

of making as large transfers as they

6:11

want or everybody is capable of seeing

6:13

everything. And certainly as a software builder,

6:16

you don't want that. You want to

6:18

make sure everybody is limited to their

6:20

roles and limitations of what they should

6:22

be able to do. If we want

6:24

to look at a disaster case scenario,

6:26

we can actually take a look at

6:29

news in the early days of a

6:31

very popular rightshare application where people from

6:33

the customer service theme or people from

6:35

inside the company who had untettered access

6:37

to everything within their thing, they were

6:39

able to take a look at some

6:41

celebrities account and the trips that they

6:44

have actually taken. In a normal world

6:46

scenario, you only want to be able

6:48

to enable the right person at the

6:50

right time to be able to look

6:52

into that trip, but now everybody has

6:54

access. In the correct world implementation, a

6:57

person should only be able to take

6:59

a look at that account if there's

7:01

a complaint, if there's an issue with

7:03

a payment, or if there's a complaint

7:05

from a driver or from the rider.

7:07

Other than that, nobody should be able

7:09

to go in and take a look

7:12

at that account. and that is a

7:14

lack of proper authorization and requirements and

7:16

limitations and not actually implementing them. I

7:18

think that's the case where there's a

7:20

term also the granular control in a

7:22

permission management system so they don't have

7:25

good granular controls is what I'm hearing.

7:27

Exactly. Probably in that scenario they had

7:29

customer success employees can take a look

7:31

at the right information. That's as coarse

7:33

as it gets, but what does that

7:35

mean? They can look at any way

7:38

easy information, they can look at any

7:40

time frame, any country, and anything. So

7:42

that's coarse-grained, but a fine-grained one would

7:44

be only you can take a look

7:46

at a specific customer that there is

7:48

a support case open for. or you

7:50

can take a look at only a,

7:53

you know, customers, again, trip, if you

7:55

have been specifically given permission to look

7:57

at because of an upstream event that

7:59

has happened. Okay. I think Alex, based

8:01

on what Embra said, you talked about

8:03

the domain model, and you explained to

8:06

us, like, you know, the A-back and

8:08

R-back and relationship base access control. So

8:10

I was wondering, when you have a,

8:12

like an authorization model, can you have

8:14

an R-back A-back and... Also like a

8:16

reback in the same model? Yeah, so

8:18

the way to kind of think about

8:21

it is less to do with whether

8:23

it's a back or a back or

8:25

reback etc. It's more about is this

8:27

more of a policy-based model or is

8:29

it more of a data-driven model or

8:31

is it more of a data-driven model?

8:34

And what I mean by that is

8:36

policy-based model and what I mean by

8:38

that is policy-based model, which is where

8:40

you have this user- got this role.

8:42

Or it could be a more fine-range

8:44

attribute-based check where you're looking for individual

8:47

attributes about the user and the resource

8:49

that you're trying to access. And that's

8:51

defined as a static versioned, tested, audited

8:53

policy. But the key thing of that

8:55

model is there's no actual user or

8:57

resource data stored in it. It's purely

8:59

the rule set. And then at evaluation

9:02

time, the system of the architecture would

9:04

bring the data to that rule set.

9:06

That rule set would be evaluated, would

9:08

be evaluated, primary use case case. the

9:10

model and the other approach is kind

9:12

of where the permissions is embedded in

9:15

the data itself. You mentioned Zanzibar at

9:17

the start, the Zanzibar White Paper outlines

9:19

the architecture behind and sort of Google

9:21

Drive and Google Docs, and in that

9:23

world you're basically storing the data, you're

9:25

storing the relationships between resources inside of

9:27

this sort of authorization layer itself. So

9:30

in that world, you don't just store

9:32

the policies, you're actually maintaining the relationships

9:34

or the permissions between individual resources. and

9:36

so that requires you to kind of

9:38

replicate and duplicate and synchronize data into

9:40

your permission store. So the policy-based approach

9:43

end, that is the requirement. You bring

9:45

the data to the authorization of the

9:47

system when you need to go check.

9:49

That way it ensures it's always up

9:51

to date, correct, and you're always going

9:53

to get the answer based on the

9:56

most relevant data. And so it's kind

9:58

of a two-way approach. And again, it

10:00

goes back to what your architecture makes

10:02

sense. But being that policy-driven approach, I

10:04

personally think is kind of the one

10:06

that gives you the most clarity of

10:08

exactly what your one that gives you

10:11

the most clarity of what your rules

10:13

are. When we did the show four

10:15

years back on building a consistent global

10:17

authorization service We talked about the Zanzibar

10:19

project and then there was a big

10:21

question there on they had specific goals

10:24

on correctness Flexibility low latency high availability

10:26

and large scale obviously it's Google But

10:28

then I wanted to ask you and

10:30

I guess this is a question I've

10:32

seen in a lot of other podcast

10:34

that people have asked the two of

10:36

you where does it make sense to

10:39

you know build your own? service like

10:41

Zanzibar and where do you use an

10:43

off-the-shelf authorization service? But I'm sorry I

10:45

have to ask you the question again.

10:47

Can you give us some advice? It's

10:49

a great question. We get asked this

10:52

all the time ourselves and the whole

10:54

reason we started service nearly four years

10:56

ago now is we've had to build

10:58

this ourselves in previous companies. Myself both

11:00

as a developer and later as a

11:02

product manager, I've been both the guy

11:05

that had to write the code that

11:07

had to write the specification for the

11:09

specification for the business we were building

11:11

this in. I've had to build this

11:13

for supply chain systems, I had to

11:15

build this from our tech systems, I

11:17

had to build this for analytic system,

11:20

I had to build this for finance

11:22

systems. And the common thing is those

11:24

businesses were not authorization systems. We should

11:26

have been spending our engineering time on

11:28

delivering the features and the capabilities that

11:30

our customers actually wanted. And much like

11:33

you would never build a database today,

11:35

you would never build file stories today,

11:37

you would never go and build an

11:39

image processing pipeline today. Those are things

11:41

that you could just pull off the

11:43

shelf. Apart from edge cases where you

11:45

do need a very specific system, we're

11:48

in a world now where there's amazing

11:50

open source projects out there, where you

11:52

can just go and grab it, bring

11:54

it in and be off. races and

11:56

not have to spend time working at

11:58

all the edge cases, working at all

12:01

the carveouts, debugging what's going on inside

12:03

of some custom code. You know, there's

12:05

an ecosystem, a rich ecosystem out there

12:07

for around a lot of these projects,

12:09

including Serbos, that is making this offering

12:11

better without you having to dedicate time

12:14

effort in an engineering resource inside of

12:16

your own business to go and build

12:18

things. Edge cases excluded, I would take

12:20

a serious look at like, do we

12:22

really need to be spending our time

12:24

on this and we're past the zero

12:26

interest rate phenomena. of the early 2020s

12:29

and we're now in a world where

12:31

we need to be really looking at

12:33

are we delivering the right value to

12:35

our customers and are we delivering what

12:37

our customers need and are we putting

12:39

all of our effort focusing on that

12:42

rather than these other external things that

12:44

we just pick up off the shelf

12:46

and use. I don't know you want

12:48

to add anything to it. I mean

12:50

the question is Alex touched upon a

12:52

important point like you wouldn't build your

12:54

own database you wouldn't build your own

12:57

software infrastructure unless it's going to make

12:59

your software differentiated differentiated. than any other

13:01

competitors of yours. It has a specific

13:03

need in there. One other state of

13:05

software building that doesn't need authorization but

13:07

for that same reason doesn't need also

13:10

authentication or many other things. Many other

13:12

security features is when you are actually

13:14

building your POC. Not even POC, let's

13:16

call it POC and POT. You want

13:18

to make sure your technology can solve

13:20

a... problem in the world, right? And

13:23

at that point you're just very much

13:25

so focusing on making the machine work

13:27

to solve the problem. At the moment

13:29

you need to take that solution and

13:31

actually now make it available to your

13:33

end user to your customers, that's the

13:35

moment where authentication and authorization and everything

13:38

else is the time you need to

13:40

start thinking about it and put those

13:42

restrictions in place. Great. So I think

13:44

the next logical question I have is,

13:46

what are the challenges that one would

13:48

face if you had an external or

13:51

decoupled authorization? Maybe can you state like

13:53

three hard challenges? So I guess firstly

13:55

is worth cutting. what decoupled or externalised

13:57

authorization is. If you think of authorization

13:59

logic, if you were to just do

14:01

something quick, you would probably end up

14:03

in a situation where in your code

14:06

base you would have like an if

14:08

statement somewhere or a case switch statement

14:10

that says if user role equals admin,

14:12

let this request go through, if user

14:14

role equals manager, only allow this request

14:16

under XYZ. And for those small applications,

14:19

you know that's perfectly fine, get you

14:21

where you need to get you where

14:23

you need to get to, prove the

14:25

value, cool, move on. But as your

14:27

application grows, particularly if your application is

14:29

start made of lots of services, and

14:31

those services might be in different languages,

14:34

any time you need to evolve or

14:36

change or update their authorization logic, which,

14:38

spoilers, will happen, you're going to have

14:40

to go touch that code. And that

14:42

code is going to get more and

14:44

more fragile as you add more complexity

14:47

to it. And there's going to be

14:49

more places you need to update logic.

14:51

And whenever the business requirement changes, you're

14:53

going to have to take that written.

14:55

Girotica or whatever, and convert that into

14:57

application code. And that application code might

15:00

actually need to be in Go, might

15:02

be in Java, might be in dot

15:04

net, depending on what your services are,

15:06

and then you're going to have to

15:08

go in touch and redeploy all your

15:10

applications, etc. The other side of it

15:12

is from a business awareness, from a

15:15

business awareness perspective, you know, we as

15:17

developers are happy to write code all

15:19

day, but those that actually define the

15:21

requirements for authorization, logic was implemented, they

15:23

probably can't because they don't know Java,

15:25

they don't know go, they don't know

15:28

XYZ language. So the advantages of externalization

15:30

is your externalizing, funny enough, all that

15:32

logic out into a standalone service or

15:34

a standalone component in your application stack

15:36

and that component has in it the

15:38

authorization logic. And now because it's just

15:40

another service inside of your setup, your

15:43

authorization logic. can be defined in something

15:45

that's maybe a bit more easier for

15:47

someone that isn't a developer to understand.

15:49

So it could be policy files, we're

15:51

talking about policy-based access control, it could

15:53

be look-up tables or data stores if

15:56

using one of the other models. And

15:58

that's a central source of truth, that's

16:00

a central one place. but all that

16:02

logic is defined, it can be version

16:04

control, it can be tested, it can

16:06

be fully audited, etc. And then in

16:09

each part of your application architecture where

16:11

you want to actually then check permissions,

16:13

rather than having all that logic hard

16:15

coded in there, you're essentially just calling

16:17

out to that authorization service and will

16:19

you simply say, okay, here's your request,

16:21

here's the user, here's the resource, and

16:24

here's the action they're trying to do,

16:26

and then that gets sent over to

16:28

that authorization service, which then evaluates to

16:30

that authorization service, which then evaluates his

16:32

policies, which then evaluates his policies, so

16:34

that you no longer need that if-all

16:37

case switch style logic littered across your

16:39

code base, it's a now a simple

16:41

if statement. If the authorization service says

16:43

allow, do the action, if not return.

16:45

It's a sort of error. And that

16:47

really gives you two big benefits. One

16:49

is whenever you want to change your

16:52

authorization logic, there's a one place you

16:54

could do it. You update it once,

16:56

you make sure tests all work, etc,

16:58

etc, etc. push out that policy change

17:00

and then all your different parts of

17:02

your application code. And secondly, and for

17:05

regulated businesses or high compliance environments, this

17:07

is a really key one, because there

17:09

is a single component in your stack

17:11

that is doing all the authorization checks,

17:13

there's a single point where you can

17:15

capture an audit block of every decision

17:18

and every action that was made inside

17:20

of your application. That comes from a

17:22

single point and that's going to be

17:24

consistent, it's going to be well structured,

17:26

you're not having to couple together logs

17:28

from different application services, etc. And that

17:30

gets you to a world where... This

17:33

externalised or decoupled authorisation model gives you

17:35

kind of the advantages around that audibility,

17:37

visibility, and scalability ultimately to get authorisation

17:39

logic across your application. And on the

17:41

back of that, if we want to

17:43

focus on the hard parts of migrating

17:46

onto this, would be one for existing

17:48

pieces of software, you need to now

17:50

figure out where you're doing all these

17:52

checks and actually replace them rather than

17:54

a business logic in there, replace them

17:56

with an API call or like, look,

17:58

library call to Serbos or to your

18:01

authorization check system. And the bigger, I

18:03

wouldn't call it a challenge. but it's

18:05

the effort that's required from this is

18:07

also looking at your software and trying

18:09

to centralize or trying to define the

18:11

authorization requirements of your system. How many

18:14

roles do you have? And what does

18:16

that mean? When you have that role,

18:18

which components can that role access? Which

18:20

actions can they do under what circumstances?

18:22

Coming up with that meta understanding of

18:24

your authorization and turning that. And then

18:27

once you understand it, writing that into

18:29

a policy. takes minutes to maybe a

18:31

couple of hours, but it's actually the

18:33

understanding your system and being able to

18:35

nail down your authorization requirements is the

18:37

harder part of the process. So what

18:39

about the challenges now that the authorization

18:42

is kind of moved out to another

18:44

place? Then almost feels like you're losing

18:46

a bit of control, right? If you're

18:48

used to having it in your code.

18:50

I mean of course it's great because

18:52

it's one less check to do but

18:55

the thing is what are the challenges

18:57

if you were outside would there be

18:59

like a latency challenge or other things

19:01

if you have to go to some

19:03

other place to pick up the decision

19:05

to allow something. As with kind of

19:07

everything with do software architecture there's a

19:10

compromise you need to make and one

19:12

of the things that you do run

19:14

into once you start externalizing authorization is

19:16

you are going to put another blocking

19:18

call essentially into a request pipeline. Now,

19:20

depending on what authorization solutions you are

19:23

using, and whether it's a stateful or

19:25

a stateless system, will very much depend

19:27

on what that deployment looks like. What

19:29

we always say to service users is,

19:31

make sure you run serveros as close

19:33

to your application as possible. So I'm

19:36

sure many are familiar with like communities,

19:38

the way we recommend deploying service in

19:40

that environment, is you run a server-side

19:42

car. in everyone of your application pods

19:44

that needs to do authorization checks. So

19:46

you basically bypassing as much as the

19:48

network as possible. It's just a local

19:51

core at that point. And then your

19:53

authorization layer itself should be smart enough

19:55

to figure out how to distribute policies

19:57

in a sensible, scalable, consistent way across

19:59

your architecture. And so actual, the runtime

20:01

checks, the lookups and the. motion checks

20:04

I mean done are literally just talking

20:06

locally inside of its own pod to

20:08

get a decision. And there's lots of

20:10

things you could do around like choice

20:12

of APIs, whether you use GRPC or

20:14

ACCP or these sort of decisions you

20:16

can make and options that you should

20:19

be considering when you're doing a deployment

20:21

of something like this. But the biggest

20:23

one that does need some thought is

20:25

your deployment to reduce. things like latency

20:27

and number of hops involved, you know,

20:29

do you start doing things at the

20:32

gateway level? Do you start doing down

20:34

at the service level? Do you use

20:36

authorization just to populate your claims in

20:38

your token? There's other approaches you could

20:40

do still using an authorization service that

20:42

is managed centrally to get to where

20:45

you need from a security faster point

20:47

of view, but also a performance in

20:49

an SLO perspective as side of your

20:51

system. Okay, so brings us then to

20:53

like Serbos, which is a... policy-based access

20:55

control. So what inspired the creation of

20:57

Serbos and what's the gap in the

21:00

market that you were trying to fill?

21:02

What inspired the creation was the fact

21:04

that earlier Alex was talking about this.

21:06

Our previous lives we had to I

21:08

think collectively within our funding team we

21:10

had to build this authorization and build

21:13

or rebuild or improve 10 times and

21:15

every single time we've done it we've

21:17

been always complaining about why are we

21:19

still building this this contributes zero differentiating

21:21

features to our product yet it was

21:23

something that we had to actually go

21:25

and build and at the time looking

21:28

at the solutions in the market none

21:30

of those things actually really addressed the

21:32

challenges that we had. So the gap

21:34

in the market that we've seen was

21:36

there wasn't a good decoupled or let's

21:38

say I call it decoupled necessarily so

21:41

authorization solution that we could have easily

21:43

implemented and moved on with our lives

21:45

and funny enough as we were starting

21:47

service that was a pretty much the

21:49

same time where many other authorization decoupled

21:51

authorization or externalized authorization providers also started

21:54

the same thing which kind of told

21:56

us okay the market is now ready

21:58

for this is the right time to

22:00

do it and our goal was always

22:02

making life easier for software developers so

22:04

they can actually just purely focus on

22:06

what they want to build what they

22:09

need to build rather than having to

22:11

reinvent the wheel when it comes to

22:13

security and as we all know nobody

22:15

really likes to remit the security wheel

22:17

because it's hard it has a lot

22:19

of loopholes it has a lot of

22:22

gotchas and we wanted to provide developers

22:24

something robust and safe secure and fast

22:26

enough so that they could have one

22:28

less worry as they were building the

22:30

product they were building. You talked

22:33

about Serboss, the primary users being

22:35

developers, but are you focused on

22:37

startups or enterprises or what are

22:40

the primary users of Serboss? So

22:42

the users we see kind of

22:44

will vary based upon this type

22:46

of organization. Serboceta's core is an

22:48

open source policy decision point, as

22:50

an open source project, really go

22:52

grab of get help, go enjoy

22:55

it, patchity license, but... the

22:57

requirements for authorization will very much

22:59

depend on what your business is doing. What

23:01

we see is startups earlier on, as I

23:03

said earlier, you kind of get going in

23:05

pretty the value with something quite simple,

23:07

and then you might mature in

23:09

terms of using something that's like

23:12

externalised authorization later on. But if

23:14

you're working in a regulated industry,

23:16

finance, medical technology, insurance, those kind

23:18

of industries, even as a startup,

23:20

you're going to have those much

23:22

stricter requirements around authorization earlier on.

23:25

and in those type of businesses

23:27

the requirement isn't coming from a

23:29

developer who's just trying to get something

23:31

implemented quickly in May 5th, Serbos, the

23:33

requirements are now actually literally coming from

23:35

the whole value of the business being say

23:37

a FinTech you have strict access control

23:40

requirements you have to implement if you're

23:42

going to be a regulated business. So you're

23:44

now getting those requirements from the scruity team,

23:46

the product team, the compliance team side

23:48

of the company, and you'll end up.

23:50

implementing a standardized externalized state this hopefully

23:53

authorization system much earlier on in the

23:55

life cycle of your business. In terms

23:57

of who's actually involved authorization, you know,

23:59

would be talking about developers a lot and

24:01

Osme, they're the ones that are going to have

24:03

to write the code. But there are the stakeholders

24:05

here. You have a Devops or a platform team

24:07

who will actually go and deploy the authorization

24:09

system inside of your environments and some

24:12

of your clusters. You'll have maybe a

24:14

security compliance team that are doing the regular order

24:16

reviews of your policies and running audit checks, etc.

24:18

If you're as a business, you're getting subject data

24:20

access requests from users. I mean, you need to

24:22

be able to pull out what they did inside

24:24

of the system that be coming from a different

24:26

part of the team. But there's also teams you

24:28

may not necessarily think of. You know, your customer

24:31

support team who might be handling support tickets about

24:33

why can't access the system might need some insight

24:35

into the authorization logic behind it. Even on like

24:37

the sales team, if you're trying to sell software

24:39

to the world. and they'll come to you saying,

24:41

like, we've got this customer, they really want to

24:43

use our system, but they have very fine-grained

24:45

authorization requirements or permission requirements just due to

24:47

the nature of their business or their organizational

24:50

structure. So there's actually a lot of different

24:52

parts of a company and roles of a

24:54

company that will have some input on authorization,

24:56

and as Emory said earlier, the hardest part

24:58

is actually getting on to agree on what

25:01

the requirements are, and then going off doing

25:03

the implementation. Now one more thing to add

25:05

into there is, you know, you might

25:07

have your standard software, you might have

25:10

just four rolls and that might actually

25:12

work, but then you might go sign

25:14

up a very large customer where they

25:16

have 5,000 internal users and those four

25:19

rolls aren't enough, right? For that customer,

25:21

you need 10 different rolls with regions,

25:23

etc. and various other things are 2050.

25:26

Now you might go sign up another

25:28

enterprise customer, which has a... different internal

25:30

structure than the previous one so they

25:32

want their roles to be structured differently

25:35

so service actually in the internet world

25:37

allows you to be able to customize

25:39

your roles and permissions on a pertinent

25:42

basis so suddenly we go away from

25:44

one size fits all model where you

25:46

know the Product manager of the original

25:49

product has to think very hard, how

25:51

to get common roles working for all

25:53

their customers, suddenly we give them a

25:56

world where every customer can have their

25:58

own structure within their software. Whether

26:02

your building software, leading teams, or shaping

26:04

product strategy, legal elements matter. Penn Kerry

26:06

Law's Software Design, Risk Regulation and Innovation

26:09

Institute is a four-day in-person program for

26:11

tech professionals. Learn to spot issues like

26:13

privacy, AI liability, and compliance early, so

26:15

you can build smarter and reduce risk.

26:17

No law degree required. Just practical insight.

26:19

Visit law. That's law.upen.adieu slash software. Use

26:21

promo code software for $50 off. So

26:24

one of the things when I looked

26:26

at the open source gate report, and

26:28

I was also looking at the open

26:30

policy agent because we had a show

26:32

on that as well, how does Sir

26:34

Boss differ from OPA? is a great

26:36

CNCF project, is heavily adopted on infrastructure

26:39

components, so Kuberneti for example, uses Oprah

26:41

inside of it as well. And when

26:43

we started burning it out Serbos, we

26:45

looked at kind of what Oprah was

26:47

doing, we looked at Rigo, its language

26:49

as well, and we kind of saw

26:51

like, this is the right idea in

26:54

terms of externalizing and taking a policy-based

26:56

approach of things. But where we saw

26:58

there was a bit of a gap

27:00

is really focusing. on this application layer

27:02

permissions. So there's a whole set of

27:04

things you kind of disregard at that

27:07

level. There's a whole set of capabilities

27:09

you need on top. And so when

27:11

we kind of looked at it, we

27:13

sort of went, okay, policy-based, having a

27:15

way of declaring your logic in a

27:17

version control tested way of doing things

27:19

is the right idea. But we really

27:22

wanted to simplify things down for that

27:24

application. permission use case, that kind of

27:26

multi-tenancy application use case, and making sure

27:28

in that level you do have much

27:30

more involvement from security, from product, from

27:32

customer support. So how can we bring

27:34

that kind of safe experience but in

27:37

a way that those team and those

27:39

different parts of organization can actually... be

27:41

a lot more involved with authorization and

27:43

the key thing we did there was

27:45

the actual policy language itself. The service

27:47

uses Yabble. There's no extra language to

27:49

learn. It's very passable and guacable. You

27:52

can kind of scan through it, understand

27:54

exactly what's going on. The way we

27:56

can kind of scan through it, really

27:58

understand exactly what's going on. The way

28:00

we structure things around here are your

28:02

resource policies, type in your application, and

28:04

the way you can say, okay, here's

28:07

a variant for a particular customer. Looked

28:09

at Oprah as a great project. We

28:11

kind of took our interpretation of that

28:13

and applied our application level permission lens

28:15

on top and that's kind of got

28:17

to where we are today four years

28:19

later, nearly. Services being used by the

28:22

GitHub stats, tens of thousands of deployments

28:24

and GitHub stars and such of our

28:26

solution out there in the world and

28:28

it's meeting this requirement of this application

28:30

level permissions. One thing to add on

28:32

top of it is, you know, OPA

28:34

is great, OPA is built for everything.

28:37

or via a very general purpose one.

28:39

When we built service for just the

28:41

application layer, we were able to reduce

28:43

the footprint a lot and we were

28:45

also able to reduce the response time

28:47

a lot because, you know, we don't

28:50

have to handle a lot of those

28:52

things. So as a result, service is

28:54

a very minimal deployment when you look

28:56

at the CPU requirements and memory. of

28:58

the application that it needs from an

29:00

application which makes it a great companion

29:02

because it almost exerts zero extra load

29:05

on your systems and it gives you

29:07

this super flexibility in a much faster

29:09

response time. That's a very good distinction

29:11

that you made of infrastructure, OPA and

29:13

then also maybe general pubs for a

29:15

lot of things that OPA uses and

29:17

this is more for the application level

29:20

authorization that we have. Can you give

29:22

us a little bit of how it

29:24

works under the hood? So I've got

29:26

a yamel file and I can fill

29:28

that in with all my permissions for

29:30

a particular project. Then what happens? Yeah,

29:32

so you go through that policy definition

29:35

process, so working with the different stakeholders

29:37

inside of your business and on your

29:39

application, define... your different resources, the different

29:41

actions, the conditions under which they should

29:43

be allowed or not. We always recommend

29:45

users then go through the additional step

29:47

of writing tests against those. So as

29:50

well as writing your policies with Serbos

29:52

you can give example fixtures, here's some

29:54

example users, here's some example resources, here's

29:56

some example resources, and then define you

29:58

under which condition or which actually should

30:00

be allowed or denied for each of

30:02

those. And so you have a test

30:05

suite. And then we take a very

30:07

Gitops style approach style approach to actually

30:09

deployment. So we recommend you go and

30:11

check those into a GitHub repo and

30:13

you go and wire up CI, be

30:15

it something you run yourself, or you

30:18

use Serbos Hub, which is one of

30:20

our offerings, and now you have policies

30:22

that you know are good and valid

30:24

and ready to go. For the deployment

30:26

side of things, you then need to

30:28

go and run Serbos, the policy decision

30:30

point that the container inside of your

30:33

infrastructure somewhere. And like I was saying

30:35

earlier, our recommended approach is... Serbos itself

30:37

doesn't require a database or a data

30:39

store or anything like that to hold

30:41

users or resources etc. Serbos is purely

30:43

evaluating requests based upon the context of

30:45

pasts of it from the application layer

30:48

and that status architecture means you can

30:50

put Serbos everywhere, you can put it

30:52

inside of every part on every cluster

30:54

in every deployment and you can have

30:56

Serbos spread out and running everywhere to

30:58

ensure that every service has a local

31:00

version of the policies to evaluating it.

31:03

So you go and deploy your server

31:05

sentences, it's now running inside of your

31:07

environment. And then the final step is

31:09

updating your application code to actually cool

31:11

that service instance. So we have SDK

31:13

and APIs available, pretty much every language

31:15

and framework now. And you do that

31:18

one type process to update the application

31:20

code and call that service instance. So

31:22

that's that service instance when you deploy

31:24

you, you tell it where to get

31:26

its policy files from. And we support

31:28

a get repo, we support a cloud

31:30

storage bracket. We support just files on

31:33

disk, and we also support servers hub,

31:35

which is our managed control plane, so

31:37

that is a synchronization layer in CI

31:39

pipeline that pulls their policies down as

31:41

well. But ultimately, those Yammer files end

31:43

up compiled, tested, and distributed out to

31:45

your environments, and that local policy decision

31:48

point running alongside your application. simply say,

31:50

here's a user trying to do this

31:52

action on this resource, it evaluates the

31:54

current policies, comes up with the decision,

31:56

creates an audit log of that decision,

31:58

and then returns it back to your

32:01

application. So it's actually a very, very

32:03

simple interface by design. There's essentially one

32:05

API one API and service with a

32:07

secondary one for a data filtering use

32:09

case, where you say user action resource,

32:11

it goes yes or no. That's all

32:13

you have to kind of worry about

32:16

implementation. You also have like an audit

32:18

log, is that what you say, for

32:20

every option. So it'll be running sort

32:22

of locally and then it gets sink

32:24

to some master. Yeah, so every instance

32:26

of your policy decision points of your

32:28

service container generates this order log and

32:31

then you have a configurable option way

32:33

you want to send it. If you

32:35

just want to use the episodes project,

32:37

you can have it just log to

32:39

standard out once and then have your

32:41

existing logging infrastructure pick it up and

32:43

you can tell it to go right

32:46

off to a Kafka topic either if

32:48

you want to. we have very common

32:50

setup we see is users are running

32:52

you know the typical low-key graffiti type

32:54

setup so that will go pick up

32:56

the logs and send them off. We

32:58

use some like fluent D and those

33:01

kind of tools. We also have a

33:03

managed log collection system part of Service

33:05

Hub which gives you a nice UI

33:07

for delving into your authorization logs and

33:09

the one thing I will say is

33:11

Audit logs are kind of one of

33:13

the superpowers and almost like a bit

33:16

of a side benefit of externalizing authorization,

33:18

not just with servers, but generally. Your

33:20

application logs are going to be spitting

33:22

out all sorts. You'll have, you know,

33:24

stack traces and memory dumps and all

33:26

sorts going on there and you're going

33:28

to have a very large volume of

33:31

data, but authorization logs, these audit decision

33:33

logs, are a kind of a different

33:35

type of log that you do need

33:37

to keep and you want to have

33:39

more data through one for attention on,

33:41

you might want to have a... three-year

33:44

retention on because of compliance reasons. So

33:46

being able to send those specifically to

33:48

a destination that is a goes to

33:50

an environment that gives tools to your

33:52

security team, to your compliance team, to

33:54

your application developers to debug or access

33:56

control logic is a real advantage. And

33:59

one of the things you just kind

34:01

of get for. free for using externalised

34:03

authorization approach. And that order log will

34:05

tell you at this time, this user

34:07

tried to do this action and this

34:09

resource, and it was allowed or denied

34:11

by this particular version of this particular

34:14

policy. And so you get that very

34:16

granular insight, what's going on side of

34:18

your system, without having to this three,

34:20

dig through your actual application level logs.

34:22

Absolutely, I can see a use case

34:24

for that. Yeah, that's a lot of

34:26

digging that you need to do. Oh

34:29

yeah. How so thinking about like where

34:31

I work at sometimes we also have

34:33

this case where like if you were

34:35

auditing a database there's always you know

34:37

you have to decide on what to

34:39

audit right every action what should you

34:41

order because again the logs can be

34:44

huge do you have to have a

34:46

similar consideration with your authorization logs or

34:48

is that a bit more leaner? Yeah

34:50

so the logs themselves are a bit

34:52

leaner because you're purely just capturing the

34:54

decision and actually For authorization logs, particularly

34:56

for regulated industries, where you must maintain

34:59

a log of X number of years,

35:01

you do need every single decision captured

35:03

because now you're dealing with the actual

35:05

actions of individual customers or users or

35:07

subscribers inside of your system and you

35:09

need to be able to pull that

35:11

out and essentially replay. exactly what that

35:14

person did, particularly if you go to

35:16

a kind of a subject access request

35:18

type environment or you got a suspected

35:20

breach identity, you need to be able

35:22

to go and fetch that. So your

35:24

security logs are a different type of

35:27

log concern than kind of the application

35:29

side of things. In the regulated industries,

35:31

it's not only enough to know who

35:33

did what and whether they were allowed

35:35

to do or so, but why were

35:37

they allowed to do that and why

35:39

they weren't. So ultimately, there's that custody

35:42

chain of not only what they did.

35:44

But what that had in the policies

35:46

are who changed the policy that allowed

35:48

that person to be able to do

35:50

something. So they need to be able

35:52

to also trace it all the way

35:54

to the policy and who updated that

35:57

policy at the end of the day.

35:59

Let's not call it finger pointing, but

36:01

they want to understand if there's an...

36:03

incident, you want to understand the full

36:05

reason behind it and service allows you

36:07

to do that as well because it's

36:09

not only all the decisions are logged,

36:12

all the policies and all the different

36:14

versions of the policies are logged and

36:16

with their entire commit logs so you

36:18

can actually figure out, you know, what

36:20

in your organization actually caused this incident

36:22

to happen so that you can actually

36:24

prevent it next time properly. Thanks for

36:27

that. I think that was a very

36:29

good discussion we had and I had

36:31

a question on the stateless authorization. How

36:33

does that work like, so do you

36:35

work with standards like say JWT tokens

36:37

or or open ID? How does it

36:39

get the context? Yeah, so again, stateless

36:42

authorization versus stateful authorization in the stateless

36:44

model, the authorization layer doesn't retain any

36:46

data store of users or resources versus

36:48

the state full model which would have

36:50

like a rapt care for your data.

36:52

So. The onus is on the, I

36:55

was referred to as the policy enforcement

36:57

point, the component which is going to

36:59

do the check to see whether an

37:01

authorization should be, an action should be

37:03

allowed or not, the onus is on

37:05

that component to send the state, so

37:07

who the user is, what the resource

37:10

is, not a context in the request

37:12

as it happens in order for the

37:14

policy engine to evaluate and come back

37:16

with a decision. So how you transfer

37:18

that data, typically it's just a big

37:20

Jason object of his details you need,

37:22

but using standards like DWT's or two

37:25

tokens, those sort of things, kind of

37:27

smooth that journey out. So in the

37:29

case of Serbos you can, you know,

37:31

fill in the data yourself or your

37:33

application can or you can just go

37:35

and full or pass on the GWT

37:37

directly to Serbos and the Serbos itself

37:40

can actually go and verify that token

37:42

if you can provide the key set

37:44

and then the contents that token is

37:46

made available inside of the policy and

37:48

for the What we refer to is

37:50

the principle of the user components of

37:52

that, there are defined standards for it.

37:55

The oath to work and JBT tokens

37:57

being the obvious one there. For the

37:59

actual resources it is a bit more

38:01

free form because it's down to what

38:03

your application model is. So there isn't

38:05

a standard to point to for that.

38:07

But where there is a relevant standard,

38:10

those are adopted and can they be

38:12

used inside of Serbos as well. And

38:14

just on the topic of standards, and

38:16

more generally, there is an ongoing effort

38:18

of which Serbos is part of under

38:20

the OpenID Foundation, called the OrthZEN Working

38:22

Group, which we're active contributors of, around

38:25

standardizing the API interface between applications and

38:27

policy decision points or authorization services like

38:29

Serbos. The first specification has been now

38:31

adopted and we're. I'm particularly interested in

38:33

more application implementers to kind of come

38:35

on board and work through getting the

38:38

all-thin standard implemented inside of their application

38:40

layers of which then you can then

38:42

go and plug in any policy decision

38:44

point like surplus interchangeably into your different

38:46

systems in your applications. Just to kind

38:48

of build up on that, for the

38:50

decisions to happen where you rely on

38:53

an external source, what are they like

38:55

for like when you're doing a enforcement

38:57

of a policy, then you would you

38:59

go to a database or API? Is

39:01

that what you're saying is configurable? So

39:03

we have a pretty strict line on

39:05

what Serbos itself or policy decision points

39:08

should do inside of the system. And

39:10

one of the things we really design

39:12

for is predictability inside of how your

39:14

policy decision point will behave. So Serbos

39:16

is fully stateless in the sense that

39:18

it doesn't store state, but it also

39:20

won't call out and go and fetch

39:23

state from other parts of your systems.

39:25

Yeah, my background as well as MRA

39:27

is from building very high throughput low-latercy

39:29

data processing systems. billions of billions of

39:31

requests a day is the kind of

39:33

typical day for us in previous lives.

39:35

And so we've made kind of every

39:38

mistake possible when it comes to eventual

39:40

consistency and scalability and thundering herd problems

39:42

and all that sort of stuff. And

39:44

one of the things we decided very

39:46

early on when defining servos and specifying

39:48

servos is servos when it's running. Once

39:50

it's got policies in there, it would

39:53

not do anything else on your system.

39:55

It is down to the calling application

39:57

to parcel and stay through that. And

39:59

the primary driver to that is... many

40:01

orders of layers of management and process.

40:03

this involved, etc. behind, someone may make

40:05

a very small change to a policy

40:08

and if that policy decision point had

40:10

the ability to go and fetch state

40:12

from across your architecture, one small change

40:14

in a policy somewhere upstream, once it

40:16

hits your production environment, that small change

40:18

could actually result in some massively unexpected

40:21

load to some other parts of your

40:23

architecture. Because if that policy now is

40:25

to go and fetch some new data

40:27

point about you from some... other system

40:29

which doesn't normally get any traffic, you're

40:31

now going to push this change out

40:33

and now suddenly that system is not

40:36

scaled, it's not ready, you're now going

40:38

to add this massive latency or even

40:40

just request failures because they can't handle

40:42

the load to your system. So we

40:44

made that cool early on from, like,

40:46

being burnt in previous lives because they

40:48

can't handle the load to your system.

40:51

So we made that cool early on,

40:53

performance characteristics that will have across your

40:55

architecture. So where do you store policies

40:57

in a stateless decoupled framework? And if

40:59

something changes, how do you do this

41:01

policy reloading without disrupting a service in

41:03

a distributed environment? Yeah, hot reloading and

41:06

such. Yeah, absolutely. So in the distributed

41:08

environments, there's obviously a challenge of how

41:10

do you get those policy files down

41:12

to those different instances that deployed potentially

41:14

hundreds, if not thousands, thousands in some

41:16

cases across your architecture. The way this

41:18

works is you store your policy centrally,

41:21

as I mentioned earlier, it could be

41:23

a get-out repo, it could be in

41:25

a storage bucket, it could be an

41:27

asset stored, someone inside it over the

41:29

stack. And then each of those server

41:31

instances in the other source project, you

41:33

configure it, you configure it, you configure

41:36

it, you configure it, it, you configure

41:38

it, it, you configure it, it, you

41:40

configure it, to say, go, you can

41:42

figure it, or it, you can source

41:44

project, you can, you can figure it,

41:46

you, you, you, you, you, you, you,

41:49

you can figure it, you, you, you,

41:51

you, you, you, you, you, you, you,

41:53

you can, you, you, you, you, you,

41:55

you, you, you, you, you, you, you,

41:57

you, you, you, you, you, you, you,

41:59

you, you, you, you, you, you, you,

42:01

you, you, you, you, you, evaluated based

42:04

on it. Now, for those of you

42:06

that have dealt with these kind of

42:08

problems before, you kind of immediately run

42:10

into the problem of, well, if I've

42:12

got 100 services running and each of

42:14

them is taking 10 seconds. to check

42:16

for updates is going to take up

42:19

to 10 seconds, let's say, for a

42:21

policy change to apply. You know, that

42:23

may be okay for your scenario or

42:25

it may actually be a problem, depending

42:27

on how fast moving your policies are.

42:29

So it's part of surplus hub, which

42:31

is our management control plan that sits

42:34

on top of the open source project.

42:36

We flip that model around and it

42:38

becomes much of a push model. And

42:40

so we can actually coordinate and synchronize

42:42

the rollout of policy updates across the

42:44

entire fleet. and without you having to

42:46

kind of worry about anything like that.

42:49

So the policies are still stored in

42:51

a central location, you get repo, a

42:53

storage bucket, etc. But the compilation and

42:55

distribution on those policy updates is now

42:57

coordinated via the control plane, and that

42:59

is Certus Hub. I guess the next

43:01

question I have is, are you talking

43:04

a little bit about testing that's offered

43:06

as a part of the worst? Like,

43:08

so how do you test and validate

43:10

policies? Do you have like some examples

43:12

that you can talk about, like, like

43:14

a new policy? There's a validation step

43:16

and there's a testing step. So first

43:19

off, because Serbos we used, you know,

43:21

mentioned in the previous earlier, YAMEL as

43:23

our format for our surrounding policies, there's

43:25

a strict schema for that. We published

43:27

those schemes publicly. So your, you know,

43:29

your VS code, your editor of choice,

43:32

and whatever you may be using these

43:34

days, will light up and give you

43:36

validation of the actual structure of the

43:38

policies themselves, or to complete all that

43:40

sort of fun stuff, as the kind

43:42

of the kind of fun stuff. Your

43:44

policy file structure may be valid, but

43:47

then you want to make sure it's

43:49

logically valid as well. So you define

43:51

those test cases. Example users, example resources,

43:53

expected actions. And then as part of

43:55

the open source CLI tool, it goes

43:57

through that, firstly validate the structure, and

43:59

then also run all the tests, make

44:02

sure that the expected outcomes are as

44:04

they should be similar with any sort

44:06

of test driven type development. And those

44:08

same tests can then be running in

44:10

your CI pipeline. be it when you

44:12

set up yourself, say get hub actions,

44:14

we publish a get hub action for

44:17

that, or as part as a more

44:19

of a managed control plane offering like

44:21

Service Hub. I also wanted to ask

44:23

you one more question. Everybody is now

44:25

at the time where they're trying to

44:27

build their own. chatpots or LLLMs and

44:29

you know those models. So when you

44:32

do this authorization I feel like a

44:34

lot of the good practices that we

44:36

got on say these you know web

44:38

application based projects for us and all

44:40

of that we had a lot of

44:42

checks that were there and it's important

44:44

to do but with the AI and

44:47

ML chat ports some of them are

44:49

lost but do you think is it

44:51

a different type of framework that has

44:53

to be applied to those kind of

44:55

applications or do we use the same

44:57

principles? Yes and no is the answer

44:59

when it comes to software engineering. It's

45:02

never a pure yes or a pure

45:04

no. So if you look back at

45:06

software development, we've spent the last 40

45:08

years in trying to secure the back

45:10

end on the front end and the

45:12

communication in between them. And now with

45:15

the AI being so advanced and chat

45:17

board technology has been around and when

45:19

those two merits, suddenly we have now

45:21

a third interface. where the AI can

45:23

actually have access to your data and

45:25

it's actually even potentially bypassing your backend

45:27

and it's having, you know, unrestricted access

45:30

to your data to be able to

45:32

train the models and then it can

45:34

actually get also the same models, LLM

45:36

models and same, you know, rag architecture

45:38

and AI can give you the answer

45:40

straight out, right? And it does bypassing

45:42

your entire backend and front-end security that

45:45

you've actually... built in there. A classic

45:47

example of this is that you can

45:49

think about any analytic system or like

45:51

any HR system where there's an AI

45:53

chatbot on top, right? It's leaking data

45:55

because, you know, if a CEO asks

45:57

for, you know, what's the current payroll,

46:00

he should get an answer off inclusive

46:02

of the entire company's information. But if

46:04

a regional VP asks, hey, what's the

46:06

payroll, it shouldn't actually give the same

46:08

answer for that given region, etc. So

46:10

we need to now start securing these

46:12

AI chatboards, AI agents with the limitations

46:15

of the user. And in order to

46:17

be able to do that, we need

46:19

to be able to actually filter the

46:21

data that comes into these AI models.

46:23

and filter the data that actually comes

46:25

out of it. And Serbo's, you know,

46:27

data filtering, authorization aware, data filtering capability,

46:30

something that Alex talked about earlier, which

46:32

is the query planning and being able

46:34

to actually filter the data based on

46:36

what you should have access on, gives

46:38

possibility to the AI agents to be

46:40

able to only return a subset of

46:42

data rather than entirety of it. So

46:45

there is a use case for the

46:47

AI agents to be able to... use

46:49

this authorization logic as the data is

46:51

passing through it. Great, because I was

46:53

just thinking when you're talking that even

46:55

about this that Chevy chat pot, right?

46:58

I think they had this case where

47:00

it was just opened without any controls.

47:02

And I think finally, I think the

47:04

chat pot, they could, they had to

47:06

like give them a Chevy for a

47:08

$1 or something like that because the

47:10

person had like a policy decision. There

47:13

are lots of examples of this right

47:15

in terms of there are you know

47:17

some in airlines there are some cheap

47:19

tickets and refunds being given at the

47:21

end of the day we need to

47:23

actually inspect each one of these things

47:25

that the LLM models as a returning

47:28

as a response and turning them into

47:30

potential API calls and be able to

47:32

check if the user is actually allowed

47:34

to do certain things. So then in

47:36

that case also like a policy decision.

47:38

point should be built on top of

47:40

those chatpots is what I'm saying. So

47:43

that's lots of things. Absolutely. So service

47:45

policy decision point has actually two major

47:47

API. One API is very specific question.

47:49

Can this user do this action to

47:51

this or can this subject or principle

47:53

or user, whatever we want to call

47:55

it, do this action to this resource?

47:58

It's a very deterministic question. Yes or

48:00

no. And then the second question is

48:02

what resources can this user do this

48:04

action on? and being able to actually

48:06

filter that being able to give that

48:08

gives you the end's ability to be

48:10

able to filter your data as it's

48:13

coming out of a database to those

48:15

only those records. that the user has

48:17

access to. Great, so the last question

48:19

I want to ask you both is,

48:21

do you see opportunities for say AI

48:23

or ML to complement stateless frameworks? I

48:26

was reading this paper a few days

48:28

back on adaptive authorization and anomaly detection.

48:30

Is that something that you think will

48:32

be the future or is it already

48:34

being done at Serbia or other places?

48:36

Yeah, so there's lots of places that

48:38

I think makes sense to use this

48:41

kind of a new world. There's also

48:43

a couple places where I think you

48:45

definitely do not want some AI model

48:47

meddling it. And the places where I

48:49

think it makes sense is at the

48:51

start of the process when you try

48:53

to take those business requirements and convert

48:56

them to policy. I think that's a

48:58

really interesting area for innovation and you

49:00

can ask Chad's EBT or Claude at

49:02

the moment, here are my requirements, give

49:04

you a service policy and they actually

49:06

mostly will and they'll come up with

49:08

a pretty. good policy these days, which

49:11

is kind of nice, so it's clearly

49:13

made all our documentation etc. And at

49:15

the other end of it, which is

49:17

once you've got that audit log of

49:19

all the decisions being made, you've got

49:21

that log stream, that's another area where

49:23

you can start doing things like anomaly

49:26

detection and understanding what's going on and

49:28

use these new tools to help you

49:30

find the signal from the noise. So

49:32

I think those are two ripe areas

49:34

for opportunity where I have I'm strongly

49:36

think today today at least, is rules,

49:38

it is business requirements, it is compliance

49:41

needs, it is regulatory hurdles that must

49:43

be met, and that needs to be

49:45

certain to behave in a certain way.

49:47

You don't worry about what the temperature

49:49

of the model that deciding your authorization

49:51

logic should be. You need to make

49:53

sure that that middle point, the actual

49:56

component, the rules engine, the evaluation engine,

49:58

is always going to give you the

50:00

right answer every single time, and that

50:02

is where good code, efficient code, you

50:04

know, call it. Handwritten artisanal code if

50:06

you want in the middle should be

50:09

the one driving the system, but certainly

50:11

this new world of tools can really

50:13

help us with both the authoring and

50:15

the understanding side of things. enforcement needs

50:17

to be deterministic and you cannot afford

50:19

to hallucinate even once because that one

50:21

instance may cause a disaster. That's a

50:24

nice way to end the show. It

50:26

has to be deterministic, the policy enforcement.

50:28

Great. So what's a good place to

50:30

reach you if somebody wanted to in

50:32

cyberspace like our listeners? Alex and Emma

50:34

would it be LinkedIn, Twitter or X

50:36

or anywhere else? Absolutely, so our website

50:39

is service. Dev, all of our resources,

50:41

all of our product and all of

50:43

our documentation can be found there. If

50:45

you want to reach us or our

50:47

teams, we have a slack community that

50:49

we are pretty responsive on and you

50:51

know we want to help our developers

50:54

adopt externalised authorization as much as they

50:56

can. And then if you want to

50:58

reach out to me individually and Rebaran

51:00

on LinkedIn and at Mray on Twitter

51:02

X. Yeah, and I'm Alex Livie on

51:04

LinkedIn and Alex Livie on Twitter. Great,

51:06

I'll make sure to add that to

51:09

the show notes. This has been a

51:11

great show. Thanks for coming. This is

51:13

Prianka Raguen for Software Engineering Radio. Thanks

51:15

for listening. Thanks for listening to S.E.

51:17

Radio, an educational program brought to you

51:19

by I tripply software magazine. For more

51:21

about the podcast including other episodes, visit

51:24

our website at S.E.com. To provide feedback

51:26

you can comment on each episode on

51:28

the website or reach us on LinkedIn,

51:30

Facebook, Twitter or through our slack channel

51:32

at s.c.com. You can also email us

51:34

at team at s. radio.net. This and

51:36

all other episodes of s.c. radio is

51:39

licensed under Creative Commons License 2.5. Thanks

51:41

for listening.