Re-reading my reply, I realize I did not properly address your question.

Assuming a similar config from the previous reply, I would create a
group-policy structure.

<?xml version="1.0" encoding="UTF-8"?>
<acl>
  <def>
    <user xml:id="SUSER">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="10">SUser</value>
    </user>
    <user xml:id="ADMIN">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <sub_user xml:id="clan1 domain">Clan1_Admin</sub_user>
      <sub_user xml:id="clan2 domain">Clan2_Admin</sub_user>
      <sub_user xml:id="clan3 domain">Clan3_Admin</sub_user>
      <value xml:id="20">Admin</value>
    </user>
    <user xml:id="USER">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="80">User</value>
    </user>
    <user xml:id="GUEST">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="90">Guest</value>
    </user>
  </def>
</acl>

This is not a production ready example, so please come up with whatever
works for you, but that should give you a better idea of a config setup.
(it would need to be more verbose and much more semantic than the
above!)

With that kind of structure you should be able to chain those subusers
onto the higher-level admin user group and chain the appropriate
rules/assertions to each specific one depending on any settings you
would pull in from another config file.

Just ensure in the user's session their user_type could use something
such as this: user_type = admin::clan1_admin

You could easily write a function to interpret the double colon (or even
map actual ACL objects to these user types/roles) and perform a domain
specific check against that usertype. So if all admins are allowed in
the Admin chat and forum, anyone with admin:: would be let in; but Clan1
admin chat would only allow someone with admin::clan1_admin to enter...

Okay, hope that helps! (given me a few interesting ideas too...)

Reply via email to