User authentication related notes

[deltasquare4]

A few things to note and fix accordingly:

• Logging in using different methods will create a new user unless Facebook and Google email ids are same.

  Possible solution?: Create a user profile page, where user can attach their account to multiple supported oAuth providers.

• No built-in roles support. Will possibly need it to separate users and admins of different organizations.

  Possible Solution?: Specify super admin in config, like @velniukas has already done. Provide this super admin with a page for user/role management.

[velniukas]

agreed - we need a user profile page and role support. Will need to add to the to do list

[katat]

User Profiler page: what are the info needs to be recorded down at this stage?
-- a field allowing the user to link the account to facebook/google
-- organization name

User/Role management page:

1. List users with their roles
2. A droplist to selecte whether the user is a normal user or a admin

Question:
What an admin's privilege rights?

[velniukas]

Well it gets complicated because we have to add the concept of roles and
organizations in:
(Need to trim down and prioritize this list)

1. The site admins
   • Manage organizations / users / payments / courses / registrations etc
     at all levels
   • Actions need to be undoable
2. Organizations (with org admins) or Individual (as a special kind of org
   :p)
   • Have private users / courses / payment plans (allowances) / (optional)
     private storage
   • Manage users / courses (private & public)
   • Have a workflow to approve course content for private or public
   • Have a workflow to approve registrations that are private to them
   • Have a dashboard / report of activity filtered by different ways for
     their users / courses / payments (allowances)
3. Course owners (with course admins)
   • Manage a single course or a track of courses
   • Can publish a course / withdraw it / open/close it for registration
   • Edit a course
   • Delete a course
   • Create a new course (within their org - or public if org
     rules/workflow allow)
4. Users
   • Can register for a course
   • Purchase allowance (or draw down from allocated allowance in org)
   • Can do the course and get results
   • Get certified at the end of courses or end of course tracks (depending
     on score, and maybe peer voting)

Thoughts?
Steve

On Fri, Apr 13, 2012 at 6:57 PM, katat <
[email protected]

wrote:

User Profiler page: what are the info needs to be recorded down at this
stage?
-- a field allowing the user to link the account to facebook/google
-- organization name

User/Role management page:

1. List users with their roles
2. A droplist to selecte whether the user is a normal user or a admin

Question:
What an admin's privilege rights?

---

Reply to this email directly or view it on GitHub:
https://github.com/velniukas/10xEngineer.me/issues/47#issuecomment-5112440

[deltasquare4]

Thanks @velniukas, that really sums it up. A couple of ambiguities though:

• What do you mean when you categorize Individual as a special kind of organization? How is an individual different from Course owner/admin?
• There needs to be a certain hierarchy to specify ownership of the course. Either an individual owns it, or an organization does. In latter case, all the org admins have equal power over the course. If an individual is part of an organization, s/he can select where to create the course. Github has a great role system to accommodate this. Check out how github users and github organizations are different while being at the same level.

[katat]

I am thinking this with the metaphor of how the university works.
The organization sounds more like an university which manages the lectures and the students, while the lectures are the course owners and the students are the users. Seeing the structure this way would be easier to consume the structure info, and how it works.
The site admin would be more like a technical management for the website.

[velniukas]

actually we don't need a hierarchy, just a "rights" document which states
which actions each role type can perform against which objects
(sub-org/individual/course etc)
[8:12:37 PM] Katat: that would be easier to manage
[8:12:59 PM] Katat: so actually whether the course is private or public
[8:13:01 PM] Steve Messina: I prefer the gmail system of tags instead of
hierarchies such as in outlook
[8:13:10 PM] Katat: depends on the course's right
[8:13:13 PM] Steve Messina: it allows you to slice and dice
multidimensionally
[8:13:15 PM] Katat: not the organization's type
[8:13:37 PM] Steve Messina: e.g. each object has an owner, with certain
rights e.g. publish, public, edit etc
[8:15:39 PM] Katat: slice and dice, a typical bi concept :)
[8:16:09 PM] Steve Messina: I've been burnt by the hierarchical approach
too many times
[8:16:10 PM] Katat: can organization be seen as object?
[8:16:14 PM] Steve Messina: esp in security
[8:16:21 PM] Steve Messina: yeah - everything could be an object
[8:16:26 PM] Steve Messina: with site admins at the top

On Fri, Apr 13, 2012 at 8:06 PM, katat <
[email protected]

wrote:

I am thinking this with the metaphor of how the university works.
The organization sounds more like an university which manages the lectures
and the students, while the lectures are the course owners and the students
are the users. Seeing the structure this way would be easier to consume the
structure info, and how it works.
The site admin would be more like a technical management for the website.

---

Reply to this email directly or view it on GitHub:
https://github.com/velniukas/10xEngineer.me/issues/47#issuecomment-5113267

[deltasquare4]

The role-permission model is pretty foolproof, but it also makes authorization unnecessarily complicated. This is the stuff where "convention over configuration" makes things much easier. I still think hierarchy is better solution.

@velniukas You mentioned having security concerns with hierarchy approach. May I ask what exactly worries you?

[velniukas]

Lack of flexibility mainly.
I am concerned about being caught in a Enterprise requirement of having to
have department/team/arbitrary level control.
With this model - it allows for nesting of entities/objects without
refactoring code - only data changes.

For security the best model I have come across is: Attribute based
Security
http://en.wikipedia.org/wiki/Access_control#Attribute-based_access_control
The only difficulty with this is needing to do something like a map-reduce
to report on all effective rights for all users.

However, it is the only one we've found where we haven't bumped into an
artificial barrier of our own creation.

• Steve

On Fri, Apr 13, 2012 at 8:34 PM, Rakshit Menpara <
[email protected]

wrote:

The role-permission model is pretty foolproof, but it also makes
authorization unnecessarily complicated. This is the stuff where
"convention over configuration" makes things much easier. I still think
hierarchy is better solution.

@velniukas You mentioned having security concerns with hierarchy approach.
May I ask what exactly worries you?

---

Reply to this email directly or view it on GitHub:
https://github.com/velniukas/10xEngineer.me/issues/47#issuecomment-5113663

[katat]

Found a existing acl module, which has a quite similar model to what we are going to build -- https://github.com/scottkf/ability-js

The interesting part is its model:
abilities = {
editor: {
index: ['read'],
protected: ['read'],
}
},
default: {
index: ['read'],
}
}
var ability = require('ability');
ability.add(abilities);

The editor and the default are the roles. Index and protected are the actions. Our model may need to have deeper requirement. Not only restrictions on actions to which targets, but also with a deeper target's specification. Such as
for the user with role in editor are able to access to which courses by specifying the course id:
{
course:
{
1(course id):[read, modify, delete]
2:[...]
}
}

Another nice part of the ability.js is its mapping idea, which maps the actions, read/add/delete/change, to the route.method(put,get, post...);

I think this module is a good one to get inspired how to extend it to fit our needs or building one from scratch.