11# SuperAuth  
22
3- TODO: Delete this and the text below, and describe your gem 
3+ Super auth is turn-key authorization gem that makes unauthorized access unrepresentable.  ** Stop writing tests for authorization with confidence ** 
44
5- Welcome to your new gem! In this directory, you'll find the files you need to be able to package up your Ruby library into a gem. Put your Ruby code in the file  ` lib/super_auth ` . To experiment with that code, run  ` bin/console `   for an interactive prompt .
5+ The intent is to use with ruby applications, as well as centralize authorization  for multiple applications .
66
7- ## Installation  
8- 
9- TODO: Replace ` UPDATE_WITH_YOUR_GEM_NAME_PRIOR_TO_RELEASE_TO_RUBYGEMS_ORG `  with your gem name right after releasing it to RubyGems.org. Please do not do it earlier due to security reasons. Alternatively, replace this section with instructions to install your gem from git if you don't plan to release to RubyGems.org.
10- 
11- Install the gem and add to the application's Gemfile by executing:
127
13-     $ bundle add UPDATE_WITH_YOUR_GEM_NAME_PRIOR_TO_RELEASE_TO_RUBYGEMS_ORG 
14- 
15- If bundler is not being used to manage dependencies, install the gem by executing:
8+ ## Installation  
169
17-     $  gem install UPDATE_WITH_YOUR_GEM_NAME_PRIOR_TO_RELEASE_TO_RUBYGEMS_ORG 
10+     gem "super_auth"  
1811
1912## Usage  
2013
14+ SuperAuth is a rules engine engine that works on 5 different authorization concepts:
15+ 
16+ -  Users
17+ -  Groups
18+ -  Roles
19+ -  Permissions
20+ -  Resources
21+ 
22+ The basis for how this works is that the rules engine is trying to match a user with a resource to determine access.
23+ It is easier to see visually:
24+ 
25+     +------+               +------------+ 
26+     | User |<------?------>| Resource   | 
27+     +------+               +------------+ 
28+ 
29+ The engine determines if it can find an authorization route betewen a user and a resource. It does so by looking at users, groups, roles, permissions.
30+ 
31+                          +-------+       +------+ 
32+                          | Group |<----->| Role | 
33+                          +-------+\    / +------+ 
34+                              ^     \  /     ^ 
35+                              |      \/      | 
36+                              |      /\      | 
37+                              |     /  \     | 
38+                              V    /    \    V 
39+     +---------------+    +------+/      \+------------+    +----------+      +-------------------+ 
40+     | YourApp::User |<-->| User |<------>| Permission |<-->| Resource | <--> | YourApp::Resource | 
41+     +---------------+    +------+        +------------+    +----------+      +-------------------+ 
42+                              ^                                  ^ 
43+                              |                                  | 
44+                              +----------------------------------+ 
45+ 
46+ 
47+ The lines between the boxes are called [ edges] ( https://en.wikipedia.org/wiki/Glossary_of_graph_theory#edge ) .
48+ Note that ` Group `  and ` Role `  trees.
49+ 
50+ The code to run the following example is located in ` spec/readme_spec.rb ` .
51+ 
52+ We're going to need some users:
53+ 
54+     Users: 
55+       - Peter 
56+       - Michael 
57+       - Bethany 
58+       - Eloise 
59+       - Anna 
60+       - Dillon 
61+       - Guest (Unknown User) 
62+ 
63+ Let's see an example company structure:
64+ 
65+     Groups: 
66+       - Company 
67+         - Engineering_dept 
68+           - Backend 
69+           - Frontend 
70+         - Sales Department 
71+         - Marketing Department 
72+       - Customers 
73+         - CustomerA 
74+         - CustomerB 
75+       - Vendors 
76+         - VendorA 
77+         - VendorB 
78+ 
79+ We're going to define a roles:
80+ 
81+     Roles: 
82+       - Employee 
83+         - Engineering 
84+           - Señor Software Developer 
85+           - Señor Designer 
86+           - Software Developer 
87+           - Production Support 
88+         - Sales and Marketing 
89+           - Marketing Manager 
90+           - Marketing Associate 
91+       - CustomerRole 
92+ 
93+ We're going to define some permissions:
94+ 
95+     Permissions: 
96+       - create 
97+       - read 
98+       - update 
99+       - delete 
100+       - invoice 
101+       - login 
102+       - reboot 
103+       - deploy 
104+       - sign_contract 
105+       - subscribe 
106+       - unsubscribe 
107+       - publish_design 
108+ 
109+ Finally, we need some resources:
110+ 
111+     Resources: 
112+       - app1 
113+       - app2 
114+       - staging 
115+       - db1 
116+       - db2 
117+       - core_design_template 
118+       - customer_profile 
119+       - marketing_website 
120+       - customer_post1 
121+       - customer_post2 
122+       - customer_post3 
123+ 
124+ So we have sufficient prerequisite data to do some interesting authorizations. Let's draw some edges:
125+ 
126+     Peter <-> Frontend # Peter is on the Frontend team. (via Company->Engineering_dept->Frontend) 
127+     Engineering_dept <-> Engineering # Group "Engineering_dept" has the Role "Engineering" 
128+     Engineering <-> create # Engineering role can do basic CRUD operations 
129+     Engineering <-> read   # Peter can CRUD too 
130+     Engineering <-> update 
131+     Engineering <-> delete 
132+     core_design_template <-> create # Now, those CRUD permissions apply to core_design_template resource 
133+     core_design_template <-> read 
134+     core_design_template <-> update 
135+     core_design_template <-> delete 
136+ 
137+ With this, the following paths are created from Peter to the core_design_template:
138+ 
139+     Peter <-> Frontend <-> Engineering_dept <-> Engineering <-> create <-> core_design_template 
140+     Peter <-> Frontend <-> Engineering_dept <-> Engineering <-> read   <-> core_design_template 
141+     Peter <-> Frontend <-> Engineering_dept <-> Engineering <-> update <-> core_design_template 
142+     Peter <-> Frontend <-> Engineering_dept <-> Engineering <-> delete <-> core_design_template 
143+ 
144+     Which completes the circuit using the path 
145+     user <-> group <-> group <-> role <-> permission <-> resource 
146+ 
147+ In general the super_auth has 5 different pathing strategies to search for access.
148+ 
149+     1. users <-> group[s] <-> role[s] <-> permission <-> resource 
150+     2. users <->              role[s] <-> permission <-> resource 
151+     3. users <-> group[s] <->             permission <-> resource 
152+     4. users <->                          permission <-> resource 
153+     5. users <->                                         resource 
154+ 
155+ When ` Group `  and ` Role `  are used, the rules will apply to all descedants. Since Edges can be drawn
156+ between any 2 objects, super_auth can seamlessly scale in complexity with you. For example this is valid:
157+ 
158+     Peter <-> core_design_template 
159+ 
160+ With this, you can completely bypass ` Group ` s and ` Role ` s and ` Permission ` s if they are not needed.
161+ So access is always allowed to a resource
162+ 
163+ When you create/delete an edge new authorizations are generated and stored in the ` super_auth `  database table.
164+ Since the path is stored with the record, it trivial to audit access permissions using basic SQL.
165+ 
21166TODO: Write usage instructions here
22167
23168## Development  
@@ -28,8 +173,8 @@ To install this gem onto your local machine, run `bundle exec rake install`. To
28173
29174## Contributing  
30175
31- Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME  ] /super_auth.
176+ Bug reports and pull requests are welcome on GitHub at https://github.com/JonathanFrias /super_auth .
32177
33178## License  
34179
35- The gem is available as open source under the terms of the [ MIT License ] ( https://opensource. org/licenses/MIT  ) .
180+ The gem is available as open source under the terms of the [ GPL ] ( https://www.gnu. org/licenses/quick-guide-gplv3.html  ) .
0 commit comments