>> Okay, welcome to another episode of the On.NET show.
Today we are going to be learning about PolicyServer,
from Michelle and Brock.
Can you folks quickly introduce yourselves?
>> I'm Michelle Riversamante and-.
>> My name is Brock Allen.
>> Okay. And yes,
so today we're going to talk about PolicyServer.
Maybe you guys can give just
a quick intro of what that is?
What the spaces that it inhabits?
If there's any other offerings
that are kind of close to it?
And how someone would get this.
>> Right. So, PolicyServer
is a product that we're putting together,
and the we is Michelle,
myself, and Dominick Baier.
We have all been working in
the security industry for many years,
and mainly focusing on identity,
and access control, things like
Single Sign-on and web API security.
We even built
an open-source framework called IdentityServer,
which is quite a popular thing
for helping people do their authentication.
Okay? And inevitably once
you've figured out your authentication,
you need to figure out then
after that, your authorization.
Okay? What can people do in your app?
So, with all these years of doing consulting,
we've helped people do their authentication story,
and then we've never had
a really good answer for the authorization bit.
So, for the last couple of years,
we've really put our heads together looking at
ways people are doing it and
the various customers that we help.
Looking at how people use our open-source project,
and you know try to figure out authorization.
And inevitably every reason kind of roll on their own.
So, the architecture that you typically get to,
when you do your identity correctly,
is you end up with a Centralized Token Server
that does your authentication,
and that's how you do Single Sign-on, right?
That's what IdentityServer does,
but Azure Active Directory
and there are other commercial products
out there like that.
>> Right. Sometimes, I hear
people talk about Bearer Tokens.
>> Yup, and Bearer Tokens are actually part of that.
>> The IdentityServer probably.
>> How you present the identity, right?
Like the result of authentication as
a token that you can present to your applications.
>> Right.
>> So, once you've gone to the effort of
centralizing the stuff and setting this up,
you know like I said,
you have to think about authorization.
And so, it sounds kind of good on paper,
that you have the centralized thing
that least put permissions in that as well,
but the problem is that,
that actually turns out on practice
to not really work out.
The Centralized Identity System
is really good for putting the stuff
about the user that's the
same across all your Apps and APIs.
The user ID is the same across everything,
their name, and their email.
>> Absolutely.
>> But now, you start putting permissions in there,
and it turns out permissions are context-specific, right?
Two different Apps or two different APIs,
have the different concept of or user's task in the app,
or what permissions they have.
So, overloading
the Centralized Identity System with permissions,
like I said, we've seen this in practice,
it actually doesn't work out so well.
>> And it also sometimes produces
too- even if you wanted to do that,
there's too many claims,
there too many bits of permissions and information,
that shouldn't really go in a
token because it's too much.
>> Right.
>> And because you'd have all of the Apps now,
you'd have to get into what they
used to do with claims transformation.
In this App, I'm going to send
these back, and the other App, the other.
But now you're conflicting doing
all that work in the Identity System when really,
why shouldn't that be managed as part of more of
an authorization management story, right?
Like across all of the Apps,
who can do what, and so forth.
>> Yeah. So, it's fundamentally,
our philosophy is that these are two separate concepts,
there should be separation concerns.
>> Understood. There are also cases where,
say within a company.
There are some applications
that in their totality that are only
available to say certain members of
the organization like the CEO and senior staff.
And you wouldn't want any part of
that application available
including the authorization piece,
available for just anyone.
So just being able to
code that off completely is a benefit. Yeah.
>> Yeah. And the other thing
is those roles that you know,
where you logged in,
is a piece of identity information,
did you come from the Central Domain,
all right, the Azure Active Directory or wherever.
Or did you get these roles assigned to you,
I'm in the marketing department,
and I'm in, I don't know, the finance department.
Those are all information
about your identity those are roles,
but those are roles related to identity that
need to get mapped ultimately
into what the App cares about.
Right? And so that's another part
of separation that we can leverage.
>> Yeah, and the abuse that we've seen in the past
is that people overload roles,
and treat them as permissions.
And so, there's a real subtle distinction, right?
>> Right.
>> So, you're a PM, or you're a dev,
well that's your identity.
But can you get to this Repo or do
this function that is more authorization-related.
>> Right. Now, so we talked
about PolicyServer and IdentityServer,
does PolicyServer only work with
IdentityServer or can it work with other options?
>> Now that's a great question.
So we've deliberately decoupled them,
they're really unrelated, okay?
>> Okay.
>> It's just you know we work in the space
so that it is the logical progression.
So now you can use any
Identity System you want to log in,
and you can use Asp.Net Identity,
just like right there in the App.
You can use Azure ID or
IdentityServer. Yeah. Anything you want.
>> Okay, makes sense.
>> Yeah.
>> And before we get too much deeper into this,
if people are really interested,
where would they go to find out more information?
>> You can go to PolicyServer.io.
>> Okay.
>> What we've done is,
we have the commercial product that is
an implementation of this design philosophy,
that we believe in,
but we did put out a
small open-source implementation as well.
So PolicyServer.io will give you a link off
to the open-source version
but will link to the commercial.
>> Is that a GitHub project?
>> Yeah. So, the open-source version is really more
about illustrating the separation of concerns,
giving you a way to in an application. That's simple.
Have a Jason-based policy that our client tools will load
and enforce in the application and it
integrates really nicely with say, Asp.
Net Calls, authorization policy implementation as well,
so that will be something you see.
And then, when we get into the product,
it's really more about a management UI,
where you can actually see
the application policies you've created,
and lay those out,
and assign users, and
integrate where the users come from to do so.
And then we also have like
various levels of that product, right?
>> Okay.
>> So, like basic entry points so that people
that just have a simple problem to solve but need the UI,
we have an entry point which is basic.
And then we have SingleHost kind of thing.
And then we have the Distributed sort of
Scalable Enterprise Model that has different APIs,
and an ability to distribute
those APIs across your server whether it's Docker-based,
or Container Platform-based or not.
And it gives you Multi-Tenant support.
It gives you audit trail so that you can
see who assigned what to who,
and when, and when they've
requested policy evaluation, who's the user, what?
So having that visibility
into your whole ecosystem of all of
the applications is really
important for compliance for some customers.
>> I can imagine.
>> Yeah.
>> So, you just talked about kind of the Web Portal UI.
We can take a look at that and see what that looks like.
>> Sure. So that's actually what
I have up here on my screen,
is our basic version of the Management Portal,
and it's in here that you model these things
called policies, hence the name.
>> Just went away.
>> So, yeah.
You model policies in here.
The policy is something that you can
think of as the manifestation of an application,
or an APIs authorization rules.
Okay? So you typically create a policy for each of
your apps that care about
utilizing the authorization feature.
So we created a little demo here for Channel Nine.
And so the idea is,
we model application-specific roles
and application-specific permissions.
So this is for where I said roles sometimes get abused,
and for identity or for authorization.
In a policy, this is purely for authorization purposes.
>> Right. So you did it correctly here?
>> Yes. We'd like to think so.
So an application, you know, we
could've used other paradigms
for manning or representing authorization,
people basically get the idea of roles and permissions.
>> Yeah. So, I've
heard this term "bandied about witches are
back" which I believe is role-based access authorization.
>> Yeah.
>> Okay.
>> Role-based access control, yeah.
>> Yeah. Is that what we're talking about here?
>> Yeah, I mean this is
very similar ideas and basically the same thing.
>> Okay.
>> But the idea too is that with roles obviously
that again we talked about the distinction
between identity role,
and an actual application role.
And then application roles can be a way to
aggregate more Granular Permissions.
And the reasoning behind that would be that
the permissions themselves. Think about it this way.
Roles can change, right?
You can have Multi-Tenancy where admin
means something different to customer A or B.
And they want to be able to say,
"I don't want to take my admin out of
this area of the app." How do you do that?
The App Area needs a permission.
So, Granular Permissions can be associated
with concrete artifacts in
your App that will never change.
That association is concrete.
And yet the role can be more vague and assign, right?
And this isn't a new concept, right?
We've done it before, over and over,
and other applications may have done that internally,
but it's just trying to make that
a utility that works for any scenario, right?
>> Right.
>> So that you can customize those roles across tenants,
and assign the different permissions,
and visualize how that applies to everybody so.
>> Makes sense.
>> And another piece is that again this is
scoped to the application.
You mentioned Access Tokens a little bit earlier?
The design of O-oath,
when you have an Access Token,
is that the Access Token can be used to call web API one,
or web API two, or web API three.
And if you start packing the Access Token full of roles,
which is kind of our belief as an anti-pattern,
then you might have admin,
and you use the token at web API one that might be legit.
You're an admin at API one,
but if you call a web API two,
maybe you shouldn't be in this admin.
So that's why these policies are per application.
>> Right.
>> Okay. Alright. So, yeah
pretty basic idea here. We have roles.
So we set up
an interview and have producer here for Channel Nine,
and we map users to these roles.
And we have various ways to map the identity,
who the user is to these application-specific roles.
User ID and based
on roles coming from your Identity System.
And we even load up Kestrel and can do
arbitrary evaluation of identity information
to indicate that you're in a particular role.
>> Right. So I was reading your website before this.
And it talked about the fact that this web UI,
which is what we were looking at,
but it also said you can do everything via
an API that the site exposes. And so you can try-
Yes. Drive the policies that way.
The thing I was wondering about is,
I can certainly imagine how I would
automate telling your server what my applications are.
And I guess, I could
imagine telling it what the roles are.
It's just wasn't quite clear to
me how someone would author I guess
a complete relationship between
roles and permissions in
absence of doing it through a system like this.
>> Oh! I see.
>> What's kind of
a scenario I guess where people would use
the API to like
completely replace what they can do with this.
That's not the scenario.
>> I think I know what you're trying to get at is that
if you don't have the UI,
how would you know what you're modeling?
>> Yes, exactly.
>> But it's interesting
because we actually do have customer's
already that we've been talking to who need to
automate building the permissions
and building the assignments of those permissions
dynamically based on resources in their application.
And our UI can't solve that problem because
it's very opinionated about their system.
So, either they want to integrate to our API
to build custom UI integrations,
or they want to integrate because at the backend,
they're going to use our scalable engine
that can evaluate policies and do decision-based.
Do I have access to this resource?
Do I have access to that resource?
But in order to do that, they'd have to
be able to when they create
the resource in their app generate
the permission and the assignment.
>> I guess it could also be the case that they
have some other database
that describes something for
another reason maybe it's their own employee database.
And it knows the difference between people
in HR versus Legal versus their Engineering team.
And then they kind of use
that information to drive what's in PolicyServer.
>> Right. And that's the distinct
between identity and permissions.
>> Yeah.
>> Right.
>> Make sense.
>> So we have
these role mappings and did I say Kestrel a second ago?
>> Yes.
>> Sorry, I meant Roslyn. I'm sorry.
Yeah, that didn't make sense.
So anyway yeah we have these roles.
The ability to map users onto the various techniques,
and then we defined permissions.
So these are the things that the app really cares about,
the actions that a user might be taking.
So again, you simply mapping
these application roles to permissions.
>> Right. So let's talk a little bit about
how you built this.
I think not only can you use it with.Net,
but I believe you built it with.Net.
>> Right. So we actually built this with ASP.NET.
ASP.NET Core, excuse me.
>> And that's where Kestrel comes in?
>> Yeah.
>> Kestrel's on the mind.
Absolutely, Kestrel's evolved.
So we have a runtime API,
so they're a client application
is needs to connect at runtime.
So we have a runtime API
where you take the authenticated user,
send it to the runtime API.
You pass the information about the user,
and you tell the runtime API, "Hey,
this is the Channel Nine App."
And based on that context we look up the right policy and
do our magic. So we produce those results.
So that's runtime API ASP.NET Core.
We have this management system.
The front end right now is built-in MVC Core.
ASP.NET Core MVC.
>> Yeah.
>> So I had to get that right,
and there's a backend API for
management as well which is again ASP.NET Core.
We're using Entity Framework on top of a database.
>> Yeah.
>> Yeah. Regular database
>> I mean the database is pluggable,
but we're starting out native right
with all the things that you would see
with most customers in the ASP.NET
Core-based application
with a single server in the back. Right?
>> Yeah.
>> So when this is hosted,
do customers kind of like buy your enterprise offering,
and then they deploy it to
the place that they want or do you have a host?
>> They host it. Yeah, we're not doing
a hosted offering at this time.
It's Docker-enabled.
So it can be distributed in a Container Platform.
Because we actually do a lot of
Container Platform work together
also with our other security projects.
So it's such a natural fit but
then also just standard paths or ions.
On-prem or Cloud doesn't really matter to us.
It's just a web app
and API with a lot of secret sauce inside. Right?
>>Yeah, totally. I'm glad we build
a product underneath you that's that flexible.
>> Yeah.
>> Actually since you mentioned Containers,
do you use the images
that we provide or you roll your own?
>> Obviously the base image,
but then, obviously, we have to get.
>> No, I meant the base image.
>> Of course.
>> Okay. Yeah.
>> Yeah. I would always go for a certified image first.
>> Yeah.
>> Absolutely.
>> That's important.
>> We spent a lot of effort.
>> It's important, and also you want to gather
the patches that come out with those as well, right?
>> Every month!
>> Exactly.
>> Yes, we're pretty serious with that.
>> Okay, either of you have
closing thoughts that you kind of
want people to be left with?
>> No, I mean I'm really excited about this.
I think we've given all of our experience.
Seeing customers dealing with this problem.
I feel like we've hit a sweet spot here.
>> Yeah.
>> So I'm pretty excited about that.
>> It's just it's such a common thing which most of
the security projects that we do with all of our team.
We run a security practice together. Its alliance, right?
It's always hitting permissions.
It's always hitting authorization.
They're always asking for help on that, design.
And permissions is actually
the way you would approach
designing your app and your solution.
It's as important that you look at the topology
of your app and your micro-services or whatever they are.
As it, as you look at
your identity story which the security protocols
we help people with is because we
have experience with that and that's hard,
but we can make it easy.
If you bring the knowledge, and
then add that permissions.
It still another design effort.
So we're providing a tool that
helps you implement the results of the design.
And then with the enterprise customers,
we're helping them with the design
too because it's just as
important that they do that properly.
So yes we're very
excited for getting a lot of good interest already so.
>> I believe it.
>> And we've barely launched you know,
so that's kind of cool. Yeah.
>> I know just before the show start,
we were joking that you'd think in 2018,
that all this would be solved and behind us,
but it's not at all.
It's extremely relevant and so many people
that want help in this space.
>> Yeah.
>> Okay. Well, thanks for dropping by.
>> Right. No. Thanks.
>> It's great to have you folks
and learned about PolicyServer.
And this was another episode of
the On.NET Show. Thanks for watching.