LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   [general] An authorization scheme proposal (https://www.linuxquestions.org/questions/linux-security-4/%5Bgeneral%5D-an-authorization-scheme-proposal-602301/)

cbonar 11-25-2007 04:47 PM

[general] An authorization scheme proposal
 
Hi

I'm sorry for the length of this message, I post it not only to have my question answered, but also because I think others could be interested.

I'm trying to define a concrete, centralized authorization scheme that can be used with most of the existing applications with a minimum of work and using only free tools.

I've been trying for a few weeks now to build such a system to manage the access to my web applications but I've encountered a lot of difficulties.


Let's start with a few assertions :
  • The system is composed with 'applications', (e.g. : a web music player, a web photo album, ...)
  • Each application has its own set of 'features', which are different for each application (e.g. : listen to music, upload new songs, view photos, download photos as zip, add comment to a photo, ...)
  • Rules to access features are not predictable, but can be split in as many permissions as necessary, that can be given to 'users' to achieve access to the requested feature (e.g. : listen to music, upload music, view photo, downzip photos, comment photo)
  • Each user is unique through the system and independent of any application/feature (so that they can be un/assigned access to any feature)
  • Permissions can be assembled into 'profiles', describing common usage schemes to the features (e.g. listener = listen to music, uploader = listen to music + upload music)

Therefore you can already figure out the procedure to integrate a new application as :
  1. Define applications (obvious most of the time)
  2. Define permissions for each application (not obvious and a complicated task, it has to be done inside each application)
  3. Define profiles for each application
  4. Assign each user a profile (or directly permissions) to give them the right access to the right features

And the database scheme :

Code:

+ users
+ applications
  + profiles
    + permissions

Here some remarks :

I'm using a LDAP server to store all the data ; this inclined me to think the hierarchical way.
However, applications on the current market rarely implement 100% of the LDAP authentication and authorization mecanisms
and I was not able up to now to make a consistent authorization system.

In order to have a consistent database, informations about users (password, name, email, ...) are carried by their entry in the system.
That means each user entry must be present at only one place in the database, in order to avoid duplicate and inaccurate informations.

Rules to access features are not predictable : that means one cannot construct a database with generic permissions.
Each application has its own set of features : this also means it doesn't make sense to separate permissions from their respective applications, and therefore to have a common permissions store for all applications.

Permissions can be assembled into profiles : even if this introduces some cost, this is very important to differentiate profiles from raw permissions.
For instance, let's say one day you add webdav access to upload photos to a web album. You don't want to add this new permission to each user one by one.
Instead you'll want to add the 'webdav upload' permission to the 'photo uploader' profile so all users with this profile will benefit from this new feature.

I think it could be more correct to include one more level : global profiles, that would include application profiles. This would make easier the replacement of an application with another one.
I haven't yet really thought about it so it doesn't appear in the following scheme.

Here's the *symbolic* hierarchical scheme the previous statements lead to :

Code:

+ users
  + me { password:jhdfkj; name:Myself; }
  + afriend { password:jhdfkj; name:Zogo; }
+ applications
  + music { name:Music jukebox; }
    + anonymous { jinzoraPermissions:readOthers; }
    + listener  { jinzoraPermissions:readOwn,readOthers,uploadOwn; }
    + uploader  { jinzoraPermissions:readOwn,readOthers,uploadOwn; }
    + admin    { jinzoraPermissions:readOwn,readOthers,uploadOwn,uploadOthers; }
  + aproject { name:A Java project; }
    + anonymous { tracPermissions:readAll; svnPermissions:read; }
    + developer { tracPermissions:readAll,writeAll; svnPermissions:read,write; }


Since I couldn't achieve yet to make it fit with my LDAP implementation, I started to doubt about this conception of authorization.

Take the example of a project supported by trac and subversion.
Trac is a software that brings to developers a shared space to work on the project.
It includes a wiki, a ticket system, svn access, reports, ...
The sources of the project are put under a subversion repository, to which access is made through the Apache's web server.

Subversion access can be controlled directly from within the web server configuration using mod_authnz_ldap.

Trac also provides a plugin to use LDAP as an authentication and authorization backend.
I was able to use LDAP for the authentication phase (via the web server), but not (yet) for the authorization.

Trac is exactly conforming to the scheme I explained before : it defines a set of permissions like TRAC_ADMIN, WIKI_VIEW, WIKI_CREATE, ...
and allows the creation of profiles (e.g., to create the 'developer' profile : 'trac-admin myrepo permission add myuser developer')


So my question is : what do you think of my authorization scheme ? Is it correct ? Realistic ?
Do you have any other ideas ? Pointers ?

I'd be happy to have your feedback :-)

drokmed 11-26-2007 01:29 PM

Quote:

Originally Posted by cbonar (Post 2970450)
So my question is : what do you think of my authorization scheme ? Is it correct ? Realistic ?
Do you have any other ideas ? Pointers ?

You just described (quite nicely) the very challenge of integrating all these different applications to work together in a similar fashion. If all the apps were written by the same company, it wouldn't be such an issue.

I've been struggling with this too for years. LDAP is definitely the best solution right now, for the authentication part anyways. The best tool I've been able to find, which is written specifically for integrating all these apps into LDAP is the GOsa project, which is GPL. It's by far the most rebust LDAP system management tool I've found.

https://oss.gonicus.de/labs/gosa/

It can already do most everything you are talking about. It's far from trivial though, you'll be rolling up your sleeves.

They are old school, use mainly their mailing list, which you will want to join if you implement the software. No forum, however, they are in the process of upgrading the web site to add useful documentation (engineers are notorious for putting off writing docs) :)

Not sure which distros you favor, they write for Debian first, then kinda migrate it over to rpm's. I've added Debian to my list of server distro's, and to be honest, I like it a lot.

Hope this helps


All times are GMT -5. The time now is 03:02 PM.