[[toc]]
+ Horde Policies
The idea of Horde Policy is to implement a replacement for the current prefs system, modeled after how Group Policy Objects work in a Microsoft Active Directory. Including a nice administrative GUI, meaning no more editing prefs.php files, and happier admins.
----
++ Visualization of a Horde Policy
<code>
policy
|-- name
|-- date-updated
|-- attribute-group
| |-- attributes
| | |-- attribute1
| | | |-- value
| | | `-- scope
| | `-- attribute2
| | |-- value
| | `-- scope
| `-- attribute-group
| |-- attribute-group
| | `-- attribute1
| | |-- value
| | `-- scope
| `-- attribute1
| |-- value
| `-- scope
|-- attribute-group
| `-- attribute1
| |-- value
| `-- scope
`-- targets
|-- target1
`-- target2
</code>
* each app would have a policy.xml file defining what policy attributes are available.
* A target can consist of one or more:
* entire horde installation
* horde group
* individual user
* guest user
* OU if using LDAP backend
Another internal structure idea:
<code>
policy
|-- name
|-- targets
| |-- target1
| `-- target2
|-- app1 (ie, imp)
`-- app2 (ie, turba)
|--attribute-group1
| |-- attribute-group2
| | `-- attribute1
| | `-- value
| `-- attribute2
| `-- value
`-- attribute3
`-- value
</code>
----
++ What would need to be done
* build a Horde Policy manager to list, create, edit, delete, etc. policies.
* Store Horde Policies in DB table(s)
* horde_policy table(s)?
* extend the datatree? The data structure fits perfectly with a few performance tweaks
<code>
horde_policy
------------
policy_id
policy_name
policy_updatedpolicy_name
</code>
<code>
horde_policy_attributes
-----------------------
policy_id
attribute_name
attribute_scope
attribute_overrideable
attribute_value
</code>
<code>
horde_policy_targets
--------------------horde_policy_targets
policy_id--------------------
policy_id
target_id
target_type <-- maybe
</code>
* there should be a default "root" policy, which cannot be detached from the root installation. This policy would be a site-wide policy that always exists.
* Should we keep a history of who created or edited a policy? Can we use the history classes for this?
----
++ Links
http://www.microsoft.com/technet/itsolutions/msit/security/grppolobjectmgmt.mspx - gives a good overview on how MS GPO's work, and a nice graphic that really helped me visualize the internal workings.
----
++ Cut & Paste from mailing list until I can better organize my thoughts
> - with something like this in place I think it would make more and
> more sense to move everything that's at all user-related in conf.php
> files to this system. Things like "user capabilities" in both Horde
> and IMP - they can even be locked (overridable = false?) by default,
> but letting people easily manage them on a per-group basis, or
> whatever, sounds very good to me.
Just brainstorming here, but we could even go a step further and use this type of system for all of the configs (except for maybe the very basic stuff, like authentication). Doing so would let different groups have different configs, which might be helpful for sites hosting for various groups.
> If there were a way to manage, say, IMAP server configs, or other
> backend configurations (sieve servers, etc.) using this system, that
> would be even better.
Yes! We could put IMAP server configs, etc. in a GPO and assign to targets as necessary. Same way that printers can be assigned in an active directory. "group A uses this IMAP server, group B uses this other IMAP server, group C gets to specify their own IMAP server." The possibilities are endless! I love it!