Search
Red Dot Ruby Conference 2016
Lightning Talk: Flexible Authorization - Storing and Managing Rules in DB
Edit
Summarized using AI

Lightning Talk: Flexible Authorization - Storing and Managing Rules in DB

Giovanni Sakti • June 23, 2016 • Singapore • Lightning Talk

In his lightning talk at the Red Dot Ruby Conference 2016, Giovanni Sakti discusses the implementation of a flexible authorization system, emphasizing the importance of storing authorization rules in a database. This allows end users to manage their own authorization configurations instead of relying on developers for changes. Sakti outlines four subsystems related to authorization: regulating, collecting, evaluating, and enforcing. He uses his experience with a client requirement to illustrate the need for flexibility in authorization mechanisms, particularly in using gems like CanCan and Pundit.

Key Points Discussed:
- Need for Flexibility: Sakti shares a scenario where he modified source code to meet client needs, highlighting how existing authorization systems lack robust frameworks for database storage of authorization rules.
- Subsystems of Authorization: There are four key components:
- Regulating: Establishing rules and policies within a database.
- Collecting: Gathering necessary data regarding user permissions.
- Evaluating: Assessing whether particular conditions allow a user to perform an action.
- Enforcing: Implementing rules to determine access rights.
- Rule Storage: He discusses his current method of using JSONB for storing rules and the need for a user-friendly interface for clients to manage their authorization setups without developer intervention.
- Implementation & Tools: The talk illustrates how to create rules involving actions and conditions, and how to utilize domain-specific language (DSL) to allow users to customize their authorization controls.
- Challenges: He notes ongoing challenges such as performance optimization and conflict resolution between rules, and introduces the idea of centralized authorization for enterprise applications to manage rules more effectively.

In conclusion, Sakti stresses the necessity of developing authorization systems that empower users, allowing them to manage the rules and configurations without developer code modifications, pointing to the increasing relevance of flexible and user-friendly authorization frameworks in enterprise environments.

Lightning Talk: Flexible Authorization - Storing and Managing Rules in DB
Giovanni Sakti • Singapore • Lightning Talk

Date: June 23, 2016
Published: unknown
Announced: unknown

Speaker: Giovanni Sakti, CEO and Software Developer, Starqle

Many excellent authorization system already exist as gems, however most of them left the implementation detail of storing authorization rules in database up for grabs. Storing them in database is important because it enables end user to configure it by themselves rather than depending on the developers to manage them. Learn how you can effectively store and manage authorization rules on database, effectively utilize policy-based authorization system such as Pundit for this purpose and learn about database design that can handle authorization better.

Speaker's Bio
Gio is software developer from Jakarta, Indonesia whom currently works for two startups; Starqle and Virkea that mostly do enterprise software developments. He also co-organizes local Ruby and Javascript developers community. When not coding, he loves doing sports, such as watching live football and tennis on TV, playing football games on PC and obviously reading fans banter on twitter.

Event Page: http://www.reddotrubyconf.com/

Produced by Engineers.SG

Red Dot Ruby Conference 2016

00:00:16.440 hello
00:00:17.279 everyone uh today I will talk about uh a
00:00:20.640 case that I have with my client
00:00:22.800 previously uh it's about flexible
00:00:25.080 authorization before that uh my name is
00:00:28.039 Giovani uh this is my Twitter handle and
00:00:30.119 my GitHub account currently I'm
00:00:32.160 associated with two uh different company
00:00:35.640 but we're doing uh mostly Enterprise
00:00:37.680 development for uh our client in
00:00:40.559 Indonesia so I'm from Jakarta Indonesia
00:00:43.879 uh it's about an hour and 30 minutes
00:00:46.520 from Jakarta to
00:00:48.320 Singapore and we also have a local Ruby
00:00:51.480 Community called ID Ruby here uh in
00:00:55.320 Jakarta and I also help organize
00:00:58.920 there uh okay let's back to the topic
00:01:01.879 about flexible authorization uh I want
00:01:04.799 to point point out about the flexible
00:01:06.880 part first uh why is flexibility
00:01:10.600 necessary I think uh it's because for
00:01:13.720 future Improvement and because my blood
00:01:15.400 type is O
00:01:19.119 Okay uh actually it's because uh several
00:01:22.520 years ago uh I I have a a requirement
00:01:25.960 from my client uh the conversation goes
00:01:28.400 like this uh so at that time I used can
00:01:31.240 can and or Pandit and he said that can
00:01:34.680 you make something like this and then I
00:01:36.720 I need to hack the source code a bit and
00:01:38.520 then I have to hand it over back to them
00:01:42.119 it goes like this but after several uh
00:01:45.680 go going back and forth he he has
00:01:47.920 something like this can you just give me
00:01:49.719 a nice interface to work with at that
00:01:52.200 point I realized that the current imp uh
00:01:54.840 the current authorization game like
00:01:56.119 Kanan and Pandit it doesn't really give
00:01:58.719 an framework for as to storing the regul
00:02:01.960 the rules and authorization in database
00:02:04.320 uh we have to modify the our source code
00:02:07.079 before we can uh give it back to
00:02:10.480 them so this is actually a work in
00:02:12.959 progress uh I'm still improving my uh
00:02:15.080 system in our
00:02:16.840 application uh but before I talking
00:02:19.160 about the step let me first talk about
00:02:21.800 the the subsystem of authorization so if
00:02:26.760 we're talking about Au authorization
00:02:29.000 there is actually four parts sub of
00:02:31.319 subsystem regulating collecting
00:02:34.040 evaluating and enforcing or
00:02:36.680 scoping uh I will use a diagram to help
00:02:39.959 you understand this for first time if we
00:02:42.800 have a application we have to regulate
00:02:44.920 all all of our rules or policies into
00:02:47.319 into database or other data store or
00:02:49.480 maybe on your source code you have to uh
00:02:52.239 create rules like user a May access uh X
00:02:55.480 or user B may access Z something like
00:02:57.519 that and then after you regulate all
00:03:00.040 your rules into the data
00:03:01.879 store uh you will encounter something
00:03:04.519 like this you have an application where
00:03:06.519 your application uh try to ask to the
00:03:09.560 system can I can I read this document so
00:03:12.560 your user accessing your application
00:03:14.000 then he he wants to know whether he can
00:03:17.599 read this document or not and this is
00:03:19.400 called the enforcing or scoping so the
00:03:21.640 enforcer will will go to the evaluating
00:03:25.400 part and the evaluating will collecting
00:03:28.720 all the necessary rules and a policies
00:03:31.159 from the database or data store after
00:03:33.760 that it will be returned and the
00:03:36.879 evaluating will go to the enforcing part
00:03:39.480 and the enforcing will tell the user
00:03:41.319 that okay you may read this document or
00:03:43.640 you may not read this document so it
00:03:45.840 goes like this and we also have to
00:03:49.760 understand the elements of authorization
00:03:51.799 subject action object resource and
00:03:54.040 environment so if you go if you go here
00:03:56.760 can I read this document I the I is the
00:03:59.200 subject read this document is the uh
00:04:02.519 resource or the object uh this document
00:04:04.480 is the object and read is the action so
00:04:08.239 like that the the
00:04:10.280 elements so I will focus first on the
00:04:12.480 regulating
00:04:14.120 part uh this is what I use for my uh
00:04:17.479 system right now so actually it's not
00:04:19.359 really different but if you notice that
00:04:21.519 there is more columns on the activities
00:04:23.919 part or you you may call it privilege or
00:04:27.360 uh permission something like that I add
00:04:29.479 three three more object which is uh
00:04:31.240 actions objects and condition currently
00:04:34.320 we we use Json B for action and
00:04:37.240 condition uh we will put our regulation
00:04:40.400 inside the activities and in the
00:04:43.560 roles you may wonder what what we will
00:04:46.639 uh put in the condition and activities
00:04:49.639 uh we we put something like this so
00:04:51.479 actions for example read and the object
00:04:54.160 is document and then the condition is
00:04:56.800 object state approved so if you notice
00:04:59.479 the the previous case where my client
00:05:01.360 asked me for I can only see the approved
00:05:03.840 document the rules are like this and
00:05:07.520 bottom is the same so it's just a
00:05:10.400 different
00:05:11.320 variant you can also doing something
00:05:13.840 like this this is actually a Polish
00:05:15.759 notation it's similar to lisp the lp
00:05:19.280 that we uh see at the previous talk like
00:05:23.360 this and this one is the operator we can
00:05:27.919 also do something like this so it's a
00:05:30.199 nested condition you can do n and R and
00:05:33.720 after we stall all of our
00:05:35.319 regulation we we can give a nice
00:05:37.759 interface for user for them to create
00:05:40.440 the rules by themselves so we we may not
00:05:42.720 uh modify the source code anymore um our
00:05:45.560 implementation is something like this so
00:05:47.000 you have a like a query DSL generator
00:05:49.560 and then you have a live preview on the
00:05:51.600 bottom of the on on the bottom of the
00:05:53.720 query
00:05:54.919 generator and after that uh comes the
00:05:57.400 more easier part the collecting part so
00:06:00.280 this is actually not the collecting part
00:06:02.039 this is the enforcing part but you
00:06:04.319 notice something like this this one if
00:06:07.000 in Pandit it will go to an application
00:06:10.560 policy and I put something like this so
00:06:12.919 it can collect all the activities about
00:06:15.880 the document and I want to see whether
00:06:18.400 the user have activities related to
00:06:20.360 destroying the
00:06:22.039 document after we cre collect all the
00:06:24.440 activities comes the evaluating part
00:06:27.080 it's uh actually just we pass the
00:06:29.720 conditions three that we already created
00:06:31.840 uh in the DSL like this and after we
00:06:34.680 evaluate the condition uh three we can
00:06:37.720 then use the Pandit or cankan to enforce
00:06:41.720 for example if comes request like this
00:06:44.479 may I read or update or approve this
00:06:46.800 document okay you can use Cote like this
00:06:50.800 authorize and then uh if uh you may not
00:06:54.080 then it will be uh rejected returns for
00:06:58.280 403 and how about something like this
00:07:01.000 scoping scoping is give me all the
00:07:04.039 documents that I can read this is a bit
00:07:05.879 harder actually I have to create a parer
00:07:07.720 for this so after uh activities like
00:07:10.680 this I have a parser like this uh maybe
00:07:13.879 I will give uh the source code later and
00:07:16.599 then it will return something like this
00:07:18.319 what to select what to join and what to
00:07:19.879 filter so uh your controller is have
00:07:23.639 have a easier time to select all the
00:07:26.199 necessary document for the particular
00:07:28.080 user so for for Challenge and
00:07:30.039 Improvement uh I think it's about
00:07:32.400 performance I still haven't touched this
00:07:34.639 yet and also about the conflict
00:07:37.080 resolution what if there are two or more
00:07:39.160 rules with different
00:07:41.080 outcome and actually if you come from
00:07:44.680 Enterprise background you may heard
00:07:46.000 something like xacml which is the
00:07:48.080 standard for fine ground authorization
00:07:50.479 this is actually nice but it's very very
00:07:52.840 big and Bloated so that's why I think we
00:07:55.599 need a something like what's Json is for
00:07:58.639 XML something that is easier to
00:08:00.639 implement in our
00:08:03.000 solution and also we can also do
00:08:05.680 something like Central centralized
00:08:07.080 authorization for big Enterprise so you
00:08:08.919 have a one Central server for storing
00:08:10.680 all the rules and you can use oout for
00:08:14.560 helping the other application uh
00:08:16.840 requests whether this document can be
00:08:18.800 read or not so for the conclusion uh we
00:08:22.520 have four subsystem to
00:08:24.199 consider and
00:08:25.960 then uh the for format is very important
00:08:29.520 that's why there's even a standard in
00:08:30.919 the Enterprise but I'm I'm not using
00:08:32.599 that for for
00:08:33.959 now and my current focus is now how to
00:08:37.159 make authorization authorization system
00:08:39.159 is less dependent on developer and we
00:08:41.680 want to give more power for user so that
00:08:43.719 they may uh enhance it themselves like
00:08:46.640 that okay thank you very much this is
00:08:48.800 the
00:08:53.120 slides
Giovanni Sakti
@giosakti
Explore all talks recorded at Red Dot Ruby Conference 2016
+17