From 9a18c54302dae4dd68fc45bf5cc751084e501576 Mon Sep 17 00:00:00 2001 From: eyedia <32912067+eyedia@users.noreply.github.com> Date: Mon, 20 Nov 2017 20:11:46 -0500 Subject: [PATCH 1/6] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1aa6543..1ac8521 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ ![Aarbac logo](https://github.com/eyedia/aarbac/blob/master/Eyedia.Aarbac.Framework/Graphics/rbac_128.png) # Background & Thoughts -Technology solution is vast these days, and there is always solution to every technical problem, well..almost! Still there are major number of applications are being written using RDBMS databases with a data access layer which performs various CRUD operations on the database. Abosultely the applications are developed for specific requirements and there will be lot of code to handle those business logics. Abosolutely we need authentication & authorization layers - may be an active directory or various other kinds of authentication and authorizations mechanisms. +Technology solution is vast these days, and there is always a solution for every technical problem if not many. Typical applications use RDBMS database with data access layer to perform various CRUD operations on the database. Applications are developed for specific requirements as developers we call those business logics, we also need authentication & authorization layers, e.g. Active Directory. However you authenticate & authorize users, ultimately it's app owner's responsibility to provide necessary rights on the user interface(i.e. entitlements), which will define what all From e69eb2afcea45db2a7a1263e3f3122c57d4c3faa Mon Sep 17 00:00:00 2001 From: eyedia <32912067+eyedia@users.noreply.github.com> Date: Mon, 20 Nov 2017 20:40:59 -0500 Subject: [PATCH 2/6] Update README.md --- README.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 1ac8521..a461ee1 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,18 @@ ![Aarbac logo](https://github.com/eyedia/aarbac/blob/master/Eyedia.Aarbac.Framework/Graphics/rbac_128.png) # Background & Thoughts -Technology solution is vast these days, and there is always a solution for every technical problem if not many. Typical applications use RDBMS database with data access layer to perform various CRUD operations on the database. Applications are developed for specific requirements as developers we call those business logics, we also need authentication & authorization layers, e.g. Active Directory. +Technology solution is vast these days, and there is always at least one solution for every technical problem. A typical application has following layers: +1. Security Layer (Authentication & Authorization) +2. User Interface Layer +3. Business Logic Layer +4. Data Access Layer +5. And a RDBMS database -However you authenticate & authorize users, ultimately it's app owner's responsibility to provide necessary rights on the user interface(i.e. entitlements), which will define what all +Security layer generally just perform authentication and authorization and developers injects various code in these layers 2,3 & 4 to satisfy the business needs. You will various roles, permissions, entitlement data structure and various "HasPermissions()", ifs, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. + +In mid level application during initial days, everything looks good, but started messed up when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in these layers, code quality decreases, code volume increases and makes production support & enhancements difficult. + +Solution, or just a thought - "Can we separate out our permission related code into a complete new layer? and let these layers (2, 3 & 4) do their regular job and not worried about the permission at all?" --- # What is aarbac? From 001c04e02de5f46486f610beb1dd3e0816ccd8a0 Mon Sep 17 00:00:00 2001 From: eyedia <32912067+eyedia@users.noreply.github.com> Date: Mon, 20 Nov 2017 20:45:14 -0500 Subject: [PATCH 3/6] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a461ee1..23c68e6 100644 --- a/README.md +++ b/README.md @@ -8,9 +8,9 @@ Technology solution is vast these days, and there is always at least one solutio 4. Data Access Layer 5. And a RDBMS database -Security layer generally just perform authentication and authorization and developers injects various code in these layers 2,3 & 4 to satisfy the business needs. You will various roles, permissions, entitlement data structure and various "HasPermissions()", ifs, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. +Security layer generally just perform authentication and authorization and developers injects various code in these layers(2, 3 & 4) to satisfy the business needs. Generally they implement various roles, permissions, entitlement various ```HasPermission(), IsInGroup(), etc.``` type methods with many ifs elses, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. -In mid level application during initial days, everything looks good, but started messed up when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in these layers, code quality decreases, code volume increases and makes production support & enhancements difficult. +In mid size applications during initial days, everything looks good, but started messed up when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in those layers, code quality decreases and code volume increases and makes production support & enhancements difficult. Solution, or just a thought - "Can we separate out our permission related code into a complete new layer? and let these layers (2, 3 & 4) do their regular job and not worried about the permission at all?" From 57bddd3cbab1ca49c98906a5c6f37a572a86efc8 Mon Sep 17 00:00:00 2001 From: eyedia <32912067+eyedia@users.noreply.github.com> Date: Mon, 20 Nov 2017 20:54:01 -0500 Subject: [PATCH 4/6] Update README.md --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 23c68e6..2315daa 100644 --- a/README.md +++ b/README.md @@ -8,11 +8,11 @@ Technology solution is vast these days, and there is always at least one solutio 4. Data Access Layer 5. And a RDBMS database -Security layer generally just perform authentication and authorization and developers injects various code in these layers(2, 3 & 4) to satisfy the business needs. Generally they implement various roles, permissions, entitlement various ```HasPermission(), IsInGroup(), etc.``` type methods with many ifs elses, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. +Security layer generally just perform authentication and authorization and developers injects various code in these layers(2, 3 & 4) to satisfy the business needs. To facilitate these roles, permissions, entitlements, generally they implement various ```HasPermission(), IsInGroup(), etc.``` type methods with many ifs elses, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. -In mid size applications during initial days, everything looks good, but started messed up when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in those layers, code quality decreases and code volume increases and makes production support & enhancements difficult. +During initial days (e.g. 1st release), everything looks good, but messed up soon when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in those layers, code quality decreases and code volume increases and makes production support & enhancements difficult. Nightmare for new team members! -Solution, or just a thought - "Can we separate out our permission related code into a complete new layer? and let these layers (2, 3 & 4) do their regular job and not worried about the permission at all?" +Solution (or just a try) - "Can we separate out permission related code into a complete new layer? and let these layers (2, 3 & 4) do their regular job and not worried about the permission at all?" --- # What is aarbac? From efff191b29924540fd7e6c9fdd8f1a840d473aca Mon Sep 17 00:00:00 2001 From: eyedia <32912067+eyedia@users.noreply.github.com> Date: Mon, 20 Nov 2017 21:11:00 -0500 Subject: [PATCH 5/6] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 2315daa..f4f23c5 100644 --- a/README.md +++ b/README.md @@ -8,9 +8,9 @@ Technology solution is vast these days, and there is always at least one solutio 4. Data Access Layer 5. And a RDBMS database -Security layer generally just perform authentication and authorization and developers injects various code in these layers(2, 3 & 4) to satisfy the business needs. To facilitate these roles, permissions, entitlements, generally they implement various ```HasPermission(), IsInGroup(), etc.``` type methods with many ifs elses, switches, and other conditions to make sure that user with appropriate rights are performing appropriate operations. +Security layer generally just perform authentication and authorization and developers inject various code in these layers(2, 3 & 4) to satisfy the business needs. To facilitate these roles, permissions, entitlements, generally they implement various ```HasPermission(), IsInGroup(), etc.``` type methods with many ```ifs elses, switches, ``` and other conditions to make sure that user with appropriate rights are performing appropriate operations. -During initial days (e.g. 1st release), everything looks good, but messed up soon when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in those layers, code quality decreases and code volume increases and makes production support & enhancements difficult. Nightmare for new team members! +During initial days, everything looks good, but messed up soon when complex business scenarios, exceptions are introduced, more ifs, switches are introduced in those layers, code quality decreases and code volume increases and makes production support & enhancements difficult. Nightmare for new team members! Solution (or just a try) - "Can we separate out permission related code into a complete new layer? and let these layers (2, 3 & 4) do their regular job and not worried about the permission at all?" From 6ee73eb69f7939089a0762019d3448a9bbe95e87 Mon Sep 17 00:00:00 2001 From: Eyedia <32912067+eyedia@users.noreply.github.com> Date: Thu, 23 Nov 2017 10:28:46 -0500 Subject: [PATCH 6/6] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f4f23c5..dc51c68 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ Solution (or just a try) - "Can we separate out permission related code into a c # What is aarbac? An Automated Role Based Access Control .NET framework which can handle... -## 1. Automated Data Filters & Permissions +## 1. Automated Data Filters & Permissions (Schema Based) Apply row & column level permissions on your SELECT,INSERT,UPDATE & DELETE queries. For example, a read (or select) operation like the following … ```sql