التخطي إلى المحتوى الرئيسي

Casbin in 2025: Authorization for the AI Agent Era

· قراءة لمدة 5 دقيقة
Yang Luo
Yang Luo

2024 was the year AI agents went from demos to production. With the Model Context Protocol (MCP) gaining adoption from Google, OpenAI, Microsoft, and countless others, we're seeing a fundamental shift in how applications interact with external services. And with that shift comes a whole new set of authorization challenges that we at Casbin have been thinking about.

Understanding How Casbin Matching Works in Detail

· قراءة لمدة 8 دقيقة
Aravinda Kumar
Aravinda Kumar

In this post, I will explain the design and implementation of RBAC using the Casbin library. For a SaaS platform dealing with multiple resource hierarchies and roles that inherit permissions from higher levels, Casbin provides a performant alternative to consider.

Introduction to RBAC​

RBAC is a method of restricting access to resources based on the roles that individuals hold. To better understand how hierarchical RBAC works, let's take a look at Azure's RBAC system in the next section and then attempt to implement a similar system.

Understanding Azure's Hierarchical RBAC​

Azure Hierarchy

There is a role called Owner for all resources in Azure. Suppose if I have the Owner role assigned to me at the subscription level, that means I am the Owner of all the resource groups and resources under that subscription. If I have Owner at the resource group level, then I am the Owner of all the resources under that resource group.

This image shows that I have Owner access at the subscription level. Subscription Owner

When I check the IAM of a Resource Group under this Subscription, you can see that I have inherited Owner access from the subscription. RG Owner

So, this is how Azure's RBAC is hierarchical. Most enterprise software uses hierarchical RBAC because of the hierarchical nature of the resource levels. In this tutorial, we'll try to implement a similar system using Casbin.

How Does Casbin Work?​

Before diving into the implementation, it is important to understand what Casbin is and how it functions at a high level. This understanding is necessary because each Role-Based Access Control (RBAC) system may vary based on specific requirements. By grasping the workings of Casbin, we can effectively fine-tune the model.

What is ACL?​

ACL stands for Access Control List. It is a method in which users are mapped to actions and actions to resources.

The model definition​

Let's consider a simple example of an ACL model.

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

  1. The request_definition is the query template of the system. For example, a request alice, write, data1 can be interpreted as "Can subject Alice perform the action 'write' on object 'data1'?".

  2. The policy_definition is the assignment template of the system. For example, by creating a policy alice, write, data1, you are assigning permission to subject Alice to perform the action 'write' on object 'data1'.

  3. The policy_effect defines the effect of the policy.

  4. In the matchers section, the request is matched with the policy using the conditions r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

p, alice, read, data1
p, bob, write, data2

and the following in the Request editor:

alice, read, data1

The result will be:

true

Visual representation of the ACL model, policy, and request matching​

acl

What is RBAC?​

RBAC stands for Role-Based Access Control. In RBAC, a user is assigned a role for a resource, and a role can contain arbitrary actions. The request then checks if the user has the permission to perform the action on the resource.

The model definition​

Let's consider a simple example RBAC model:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
  1. The role_definition is a graph relation builder that uses a Graph to compare the request object with the policy object.

Now let's test the model on Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

and the following in the Request editor:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

The result will be:

true
false
true
true
false

Visual representation of the RBAC model, policy, and request matching​

rbac

The g - Role to action mapping table has a Graph mapping the role to action. This Graph can be coded as a list of edges, as shown in the policy which is a common way of representing a Graph:

g, reader, read
g, owner, read
g, owner, write
معلومات

p indicates a normal policy that can be compared using the == operator. g is a Graph-based comparison function. You can define multiple Graph comparators by adding a numerical suffix like g, g2, g3, ... and so on.

What is Hierarchical RBAC?​

In Hierarchical RBAC, there are more than one type of resources and there is an inheritance relationship between the resource types. For example, "subscription" is one type and "resourceGroup" is another type. A sub1 of type Subscription can contain multiple resourceGroups (rg1, rg2) of type ResourceGroup.

Similar to the resource hierarchy, there will be two types of roles and actions: Subscription roles and actions, and ResourceGroup roles and actions. There is an arbitrary relationship between the Subscription role and ResourceGroup role. For example, consider a Subscription Role sub-owner. This role is inherited by a ResourceGroup Role rg-owner, which means that if I am assigned the sub-owner role on Subscription sub1, then I automatically also get the rg-owner role on rg1 and rg2.

The model definition​

Let's take a simple example of the Hierarchical RBAC model:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)
  1. The role_definition is a graph relation builder which uses a Graph to compare the request object with the policy object.

Now let's test the model on the Casbin editor​

Open the editor and paste the above model in the Model editor.

Paste the following in the Policy editor:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

And paste the following in the Request editor:

alice, rg-read, rg1

The result will be:

true

Visual representation of the RBAC model, policy, and request matching​

hrbac

The g - Role to (Action, Role) Mapping table has a graph mapping the role to the action, role mapping. This graph can be coded as a list of edges, as shown in the policy, which is a common way of representing a graph:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

The g2 - Sub to RG Mapping table has a graph mapping subscription to resourceGroup:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Subject Matching Visual representation​

hrbac-sub-match

Action Matching Visual representation​

hrbac-act-match

Object Matching Visual representation​

hrbac-obj-match

معلومات

When a request is submitted to Casbin, this matching happens for all the policies. If at least one policy matches, then the result of the request is true. If no policy matches the request, then the result is false.

Conclusion​

In this tutorial, we learned about how different authorization models work and how they can be modeled using Casbin. In the second part of this tutorial, we will implement this in a demo Spring Boot Application and secure the APIs using Casbin.

التفويض في APISIX باستخدام Casbin

· قراءة لمدة 5 دقيقة
Rushikesh Tote
Rushikesh Tote
عضو في Casbin

مقدمة​

APISIX هو بوابة API سحابية عالية الأداء وقابلة للتوسعة تعتمد على Nginx و etcd. إنه مشروع مفتوح المصدر من قبل مؤسسة Apache للبرمجيات. بالإضافة إلى ذلك، ما يجعل APISIX جيدًا جدًا هو دعم العديد من الإضافات الرائعة المدمجة التي يمكن استخدامها لتنفيذ ميزات مثل المصادقة، والمراقبة، والتوجيه، وما إلى ذلك. وحقيقة أن الإضافات في APISIX يتم إعادة تحميلها بشكل ساخن (دون إعادة التشغيل) تجعلها ديناميكية للغاية.

ولكن أثناء استخدام APISIX، قد تكون هناك سيناريوهات ترغب فيها بإضافة منطق تفويض معقد في تطبيقك. هنا يمكن أن يساعدك authz-casbin، authz-casbin هو إضافة APISIX تعتمد على Lua Casbin والتي تمكن التفويض القوي بناءً على نماذج مختلفة للتحكم في الوصول. Casbin هو مكتبة تفويض تدعم نماذج التحكم في الوصول مثل ACL، RBAC، ABAC. كتبت أصلاً بلغة Go، وتم نقلها إلى العديد من اللغات و Lua Casbin هي تنفيذ Lua لـ Casbin. بدأ تطوير authz-casbin عندما اقترحنا إضافة جديدة للتفويض في مستودع APISIX (#4674) وافق عليها الأعضاء الأساسيون. وبعد المراجعات المفيدة التي أدت إلى بعض التغييرات الكبيرة والتحسينات، تم دمج الطلب (#4710) أخيرًا.

في هذه المدونة، سنستخدم إضافة authz-casbin لإظهار كيف يمكنك تنفيذ نموذج تفويض يعتمد على نموذج التحكم في الوصول بناءً على الأدوار (RBAC) في APISIX.

ملاحظة: ستحتاج إلى استخدام إضافة أخرى أو سير عمل مخصص لمصادقة المستخدم لأن Casbin سيقوم فقط بالتفويض وليس المصادقة.

إنشاء نموذج​

تستخدم الإضافة ثلاث معاملات لتفويض أي طلب - الفاعل، والموضوع، والفعل. هنا، الفاعل هو قيمة رأس الاسم المستخدم، والتي يمكن أن تكون شيئًا مثل [username: alice]. ثم، الموضوع هو مسار URL الذي يتم الوصول إليه والفعل هو طريقة الطلب المستخدمة.

لنقل نريد إنشاء نموذج بثلاث موارد على المسارات - /، /res1 و /res2. ونريد أن يكون لدينا نموذج مثل هذا:

صورة

هذا يعني أن جميع المستخدمين (*) مثل jack يمكنهم الوصول إلى الصفحة الرئيسية (/). والمستخدمون الذين لديهم صلاحيات admin مثل alice و bob يمكنهم الوصول إلى جميع الصفحات والموارد (مثل res1 و res2). أيضًا، دعونا نقيد المستخدمين بدون أي صلاحيات إدارية على استخدام طريقة الطلب GET فقط. لهذا السيناريو، يمكننا تعريف النموذج على النحو التالي:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)

إنشاء سياسة​

من السيناريو أعلاه، ستكون السياسة:

p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin

المطابقة من النموذج تعني:

  1. (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)): إما أن يكون لفاعل الطلب دور كفاعل السياسة أو يطابق فاعل الطلب فاعل السياسة في keyMatch. keyMatch هي وظيفة مدمجة في Lua Casbin، يمكنك الاطلاع على وصف الوظيفة والمزيد من الوظائف المفيدة هنا.
  2. keyMatch(r.obj, p.obj): يطابق موضوع الطلب موضوع السياسة (مسار URL هنا).
  3. keyMatch(r.act, p.act): يطابق فعل الطلب فعل السياسة (طريقة الطلب HTTP هنا).

تمكين الإضافة على المسار​

بمجرد إنشاء النموذج والسياسة، يمكنك تمكينها على مسار باستخدام واجهة برمجة تطبيقات APISIX الإدارية. لتمكينها باستخدام مسارات ملفات النموذج والسياسة:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model_path": "/path/to/model.conf",
            "policy_path": "/path/to/policy.csv",
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

هنا، حقل الاسم المستخدم هو اسم الرأس الذي ستستخدمه لتمرير الفاعل. على سبيل المثال، إذا كنت ستمرر رأس الاسم المستخدم كـ user: alice، فستستخدم "username": "user".

للاستخدام نص النموذج/السياسة بدلاً من الملفات، يمكنك استخدام حقول model و policy بدلاً من ذلك:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model": "[request_definition]
            r = sub, obj, act

            [policy_definition]
            p = sub, obj, act

            [role_definition]
            g = _, _

            [policy_effect]
            e = some(where (p.eft == allow))

            [matchers]
            m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)",

            "policy": "p, *, /, GET
            p, admin, *, *
            g, alice, admin
            g, bob, admin",

            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

تمكين الإضافة باستخدام نموذج/سياسة عالمية​

قد تكون هناك حالات ترغب فيها باستخدام نموذج وسياسة تكوين واحدة عبر مسارات متعددة. يمكنك القيام بذلك أولاً بإرسال طلب PUT لإضافة تكوين النموذج والسياسة إلى بيانات الإضافة الوصفية بواسطة:

curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/authz-casbin -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
"model": "[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)",

"policy": "p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin"
}'

ثم لتمكين نفس التكوين على بعض المسار، أرسل طلبًا باستخدام واجهة برمجة التطبيقات الإدارية:

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/route1/*"
}'

سيضيف هذا تكوين بيانات الإضافة الوصفية إلى المسار. يمكنك أيضًا تحديث تكوين بيانات الإضافة الوصفية بسهولة عن طريق إعادة إرسال الطلب إلى بيانات الإضافة الوصفية مع تحديث تكوين النموذج والسياسة، وستقوم الإضافة تلقائيًا بتحديث جميع المسارات التي تستخدم تكوين بيانات الإضافة الوصفية.

حالات الاستخدام​

  • الحالة الأساسية لاستخدام هذه الإضافة ستكون في تنفيذ التفويض في واجهات برمجة التطبيقات الخاصة بك. يمكنك بسهولة إضافة هذه الإضافة على أي مسار واجهة برمجة تطبيقات تستخدمه مع نموذج التفويض وتكوين السياسة الخاص بك.
  • إذا كنت ترغب في امتلاك نموذج تفويض واحد لجميع واجهات برمجة التطبيقات الخاصة بك، يمكنك استخدام طريقة النموذج/السياسة العالمية. هذا يجعل تحديث السياسة سهلًا لجميع المسارات، حيث أنك تحتاج فقط إلى تحديث البيانات الوصفية في etcd.
  • بينما إذا كنت ترغب في استخدام نموذج مختلف لكل مسار مختلف، يمكنك استخدام طريقة المسار. هذا مفيد عندما تحتوي مسارات واجهة برمجة التطبيقات المختلفة على مجموعات مختلفة من أذونات المستخدم. يمكنك أيضًا استخدام هذا عند التعامل مع سياسات أكبر، حيث سيجعل عملية التفويض أسرع عند تصفيتها إلى مسارات متعددة.

يانغ لو - الفائز بجائزة Google Open Source Peer Bonus

· قراءة لمدة 2 دقيقة
Casbin
Casbin
الحساب الرسمي

اليوم، يسرنا أن نعلن أن مؤسس كاسبين، يانغ لو، قد حصل على جائزة "الفائزين بجائزة Google Open Source Peer Bonus" لعمله على كاسبين، Npcap و Nmap في الربع الثالث من عام 2019.

ospb

يمكن الوصول إلى خطاب الجائزة الأصلي هنا.

يوصف برنامج Google Open Source Peer Bonus بأنه:

بنفس الطريقة التي يُستخدم فيها Google Peer Bonus للاعتراف بزميل في Google قد قام بعمل استثنائي، يُستخدم Open Source Peer Bonus للاعتراف بالأشخاص الخارجيين الذين قدموا مساهمات استثنائية في مجال المصادر المفتوحة.

الإعلان عن الفائزين لعام 2019 متاح في: announcement for the 2019 winners

https://opensource.googleblog.com/2020/01/announcing-2019-second-cycle-google.html

يتم ذكر يانغ وكاسبين بين مطوري ومشاريع المصادر المفتوحة التي لها تأثير ذو صلة في الخارج، مثل Git، TensorFlow، V8، CPython، LLVM، مشاريع Apache، Angular أو Jenkins.

نحن سعداء لرؤية كاسبين يتم التعرف عليه بهذه الطريقة لمساهمته في المصادر المفتوحة وأمان السحابة!

شكرًا لاستخدامكم كاسبين!

إعادة العمل على توثيقنا

· قراءة لمدة 1 دقيقة
Yang Luo
Yang Luo
مبتكر Casbin

اليوم، قمنا بترحيل توثيق Casbin من ويكي GitHub إلى Docs على هذا الموقع، والذي يعمل بواسطة Docusaurus. Docusaurus يوفر العديد من الميزات الرائعة مثل أنماط Markdown المحسنة، البحث النصي الكامل، التحكم بالإصدارات، الترجمة.

التوثيق ليس مثاليًا بعد ولا يزال بحاجة إلى تعديل. يتم استضافة الكود المصدري على GitHub: https://github.com/casbin/casbin-website-v2 .

أي مساهمة أو اقتراح مرحب به!

node-Casbin: عضو جديد في عائلة Casbin

· قراءة لمدة 1 دقيقة
Zixuan Liu
Zixuan Liu
مُحافظ Casbin

اليوم، نجحنا في نقل Casbin إلى Node.js، والذي يُسمى:

node-Casbin. node-Casbin يشارك في الاستخدام المشابه وواجهة برمجة التطبيقات مع التنفيذات الأخرى لـ Casbin. البرمجيات الوسيطة لـ Express و Koa2 و Egg.js جاهزة للاستخدام.

تم أيضًا تجهيز محول التخزين لـ Sequelize.

GitHub: https://github.com/casbin/node-casbin

تم إطلاق خادم Casbin!

· قراءة لمدة 1 دقيقة
Helong Zhang
Helong Zhang
صيانة Casbin

بعض عملائنا يسألون إذا كان يمكن استخدام Casbin كخدمة بدلاً من مكتبة. الإجابة هي نعم. اليوم، أطلقنا مشروع خادم Casbin كحل ملموس لـالتحكم في الوصول كخدمة.

خادم Casbin قيد التطوير النشط من قبل فريقنا الأساسي. لديه عدة ميزات:

  • مطور بالكامل بلغة Golang.
  • يمكنه إدارة الآلاف من نماذج Casbin، حتى تتمكن من نقل منطق تطبيق السياسات من خدمات متعددة إلى خادم Casbin واحد.
  • gRPC يستخدم للتواصل مع خادم Casbin. نحن نفكر أيضًا في إضافة الدعم RESTful في المستقبل القريب.
  • يتم توفير بوابة إدارية ودية للمدراء غير المطورين لإدارة جميع التفاصيل مثل نماذج Casbin والنماذج وتخزين السياسات وتوازن الحمل.

يتم استضافة الشفرة المصدرية على GitHub: https://github.com/casbin/casbin-server

أي مشاكل أو طلبات سحب مرحب بها :)