#2314 1.9.2 how to limit access to an area to a specifiy ldap group

[Thomas S.]

Hi

MRBS version: 1.9.2.

I have a very special request:
There should be an area to which (inlcuding all rooms within) only people who are in a ldap-group (i.e. cn=special-users,ou=groups,dc=testsite,dc=de) should have access (like normal, read/change/delete their own entries).

This is because of an approval process, but its not enough to approve one event (which is possible and configured already), instead, people have to be approved beforehand and are then added to the ldap-group.

Access should always be possible for mrbs admins though (they are in a special ldap-group anyway).

Is there a way to achieve this?

Best,
Thomas

[Campbell Morrison]

This is a feature that is under development at the moment. However it is far enough advanced (at least for LDAP authentication) that you could test it and see whether it does what you want. I recommend that you just use it in a test environment initially.

The development is in the roles branch and you can get the latest code by following the Download Snapshot link on that page.

The way it works is that you can create roles and assign roles to individual users or to groups (in this case LDAP groups). Each role that you create can have the following permissions assigned on a room by room basis and an area by area basis:

• Read: the room/area is visible
• Write: users can create bookings for themselves, but not edit or delete other people's bookings
• All: the user has admin rights for that room/area.

[Nicola Praticelli]

Hello, I tried to access the page https://sourceforge.net/p/mrbs/hg-code/ci/roles/tree/ as you indicated, but it returns me "forbidden", but I'd like to use the roles and groups into mrbs, is there a way I can download those features or to activate them in a test site in which I installed mrbs 1.11.0?

[Campbell Morrison]

We've moved the repository to GitHub. The roles branch is now here. Follow the green Code button.

[Nicola Praticelli]

Thank you very much Campbell, but now I have another issue: I can't give as input a room name longer than 25 characters, is there a way to change the $maxlength parameter for text input fields? I saw that now the global variable has been replaced by a function which calculates it automatically, but I can't find a way out to change it, I need to create rooms with longer names and I already altered the database table setting room_name as varchar(80). But nevertheless in forms still I can't type more than 25 characters. Thanks

[Campbell Morrison]

That should work. Have you refreshed the form page? If you are still having problems, are you sure you have changed the correct column in the correct table?

[Nicola Praticelli]

Yes, I managed to make it work, but I had to delete and recreate the database, alter the table and then re-install mrbs, and the variable $maxlength has been correctly set to 80. Thanks a lot for your support.

[Campbell Morrison]

I am surprised by that: you shouldn't need to have to recreate the database. You should just need to alter the column structure. Anyway, I'm glad it's working now.

[Thomas S.]

Hi

Thanks for your reply:
Can i achieve the following with this?
-everybody has read access in a specific are (currently the setting for the whole MRBS installation)
-There is an ldap-group per room in that area and only people in that ldap-group can write (create bookings only for themselves)

If i checkout your code, please tell me the files where i can set this up or where to look at :)

[Campbell Morrison]

Yes, you can achieve that. You don't have to change any files. You should find two new menu items : Roles and Groups.

[Thomas S.]

This doesn't work. i patched my 1.9.1 code with the files from the snapshot, but i don't see the new menu items. Where are they supposed to be (i haven't changed anything in my config.inc.php)

[Campbell Morrison]

Did it ask you to do a database upgrade? (It should have done).

You should see the new menu items next to Help Report etc. (but only if you login as an admin).

[Thomas S.]

No it didn't ask me for a upgrade and if im logged in as admin, i don't see the new menu items

[Campbell Morrison]

It sounds like you haven't installed the release properly. You should treat it just like an upgrade release and overwrite all your existing files (except the config file) with the new files.

If that doesn't work try installing it as a completely new installation.

[Thomas S.]

Hi

I fixed it so that the code works. Looks really nice but i have added one ldap group and noticed that even after restarting apache it is not displayed in the ui to be able to be mapped to a role. What am i doing wrong here?

[Campbell Morrison]

Have you done a Sync? There is a Sync button on the Users page.

[Thomas S.]

Thanks a lot, now i see my ldap group :)

-I created a role with the area, the permission is set to "write" and the state to "Granted"
-I mapped an ldap group to that role
-However i noticed that in the specified area and rooms, everybody can see and create events and not only the persons that are specified in the ldap group.

[Campbell Morrison]

Yes, by default it behaves just like traditional MRBS, ie the default rule is that admins have "All" permission, ordinary logged in users have "Write" and unlogged in users have "Read". What you have done is grant write permission to your group, but they already had that.

To ensure that only your group has access you need to assign everybody else to another group and deny that group access.

The other thing you could do is change the default rule (which is in the method getDefaultRule() in lib/MRBS/Location.php) so that the default is that nobody has access to anything and then you selectively grant access as required. (I suppose that the default rule should be more configurable, either through a config setting, or else by having a default rule that can be edited. )

[Thomas S.]

Well whati want to achieve is that:
-Everybody who can login (ldap) can book all areas except for this particular one (for which you have to be member of the special ldap group).

[Campbell Morrison]

It's maybe easier to define your group differently. Instead of it being the people who can book that area, make it the people who can't book that area and then deny that group write access to the area.

[Thomas S.]

This doesn't work as the people have to be explicitly put in the special ldap group (whitelist approach) rather than all others beeing access denied (blacklist approach).

[Campbell Morrison]

Mmmm. This probably needs more thought. Maybe there should be a default group to which everybody belongs automatically and then you can assign roles to the group to define default behaviour. Or maybe there should be an interface to define the default rules for areas and rooms.

In the meantime you could probably solve it by adding the following method to lib/MRBS/Area.php

  public function getDefaultRule($user)
  {
    // Every area except one has the default permissions
    if ($this->id != 7)  // or whatever the id of your area is
    {
      return parent::getDefaultRule($user);
    }

    // The special area has restricted permissions
    $result = new AreaRule();

    $result->state = $result::GRANTED;

    if (!isset($user) || empty($user->level))
    {
      $result->permission = $result::READ;
    }
    elseif ($user->isAdmin())
    {
      $result->permission = $result::ALL;
    }
    else
    {
      // Modified from the standard WRITE
      $result->permission = $result::READ;
    }

    return $result;
  }

[Thomas S.]

Hi

I put the following in Area.php at the bottom:

  public function getDefaultRule($user)
  {
    // Every area except one has the default permissions
    if ($this->id != 21)  // or whatever the id of your area is
    {
      return parent::getDefaultRule($user);
    }

    // The special area has restricted permissions
    $result = new AreaRule();

    $result->state = $result::GRANTED;

    if (!isset($user) || empty($user->level))
    {
      $result->permission = $result::READ;
    }
    elseif ($user->isAdmin())
    {
      $result->permission = $result::ALL;
    }
    else
    {
      // Modified from the standard WRITE
      $result->permission = $result::READ;
    }

    return $result;

The area id of the special area which has the ldap-role is 21, i picked that up from the url query string (hope thats fine).

I restarted the webserver but the behaviour is still the same
My test user who is not in the group can book all other areas but also the one that has the ldap role (and like i said, he is not in the specific ldap group).

[Campbell Morrison]

I suspect this may be related to https://sourceforge.net/p/mrbs/support-requests/2321/ and your test user is really an admin?

(By the way there's no need to restart the webserver for the changes to take effect).

[Thomas S.]

Hi

No my test user is a normal user. He is part of the special ldap grouo

-My test user who is not in the group can book all other areas but also the one that has the ldap role (and like i said, he is not in the specific ldap group).

-As another user, i can also book all other areas but also the one that has the ldap group restriction role.

[Anonymous]

Please help me fix this issue. This is important for our institute. Please!