Using Zivios Identity Management - Page 3
Identity Management using Zivios
IDM is accomplished using the supplied Group and User plugins. Once a service is initiated, groups in visibility would see that service and allow you to EXTEND them with that service.
Once a group has been extended with that service, users in that group can initialize that service which exposes the User Specific options of the service. It is up to the module creator to decided what functionality should be in these four components namely User, Group, Service and Computer.
Group Plugins
Let's create a new group. Right click on your group container that you created earlier and select add group. The only required parmeter is the group name.
You would see the group automatically inherits a few plugins. Keberos, Ldap, CA, Posix all define 'group' and 'user' portions. DNS, NTP, DHCP do not provide such portions and hence they cannot be added to groups. It is upto the module developer to define these portions and zivios would adjust automatically.
Click on "Service Management" inside the group. You will notice that an Asterisk plugin can now be added to this group. Install this plugin.
You would notice that the group now has the orange asterisk tab added to it. All plugins show as these orange tabs.
Note: You can also simply extend the first group you created earlier with the Asterisk plugin. The user you created earlier would AUTOMATICALLY allow the Asterisk plugin to be added to it.
User Plugins
Users inherit plugins based on their group memberships. Sometimes this is useless - as sometimes the group portion of a plugin does absolutely nothing (Squid for example). However this is the norm we have chosed to maintain consistency.
The user you created earlier should list 'Asterisk' as the plugin. Clicking on it you would see the plugin is disabled. Plugins need to be explicitly enabled per user. In later version we might provide a 'Bulk Subscribe' feature.
You would notice that information being asked for the 'Asterisk' plugin is closely related to User specific information. His extension, voicemail password, codecs, email etc.
When you click Apply, multiple things happen. First of all his information gets stored in LDAP for later retrieval. Secondly, the Asterisk plugin contacts the agent on the asterisk machine and asks it to make these changes in Asterisk's SIP.conf, extensions.conf, voicemail.conf automatically.
You would also see a 'Route permissions' section. Zivios Asterisk plugin also provides a feature to enable route based acls. This is an example to show how you can add custom functionality to Asterisk using a zivios plugin and provide it with a nice front end.
Delegated Adminsitration
Zivios allows fine grained ACLs to be placed on any part of the tree. Since everything inside Zivios is a LDAP object, any sort of control can be incorporated using Ldap ACLs. Zivios also features Zivios ACLs which can further lock down the system and provide ACLs of sort that are not exactly possibly with bare OpenLDAP ACls. However, in doing so security of the system is completely preserved.
Zivios logic has been carefully examined by us and every care is taken to NOT leave security holes. This means that we make sure there is no situation in which you can get MORE access by bypassing Zivios (Binding to LDAP directly). If you can produce a scenario where this does not hold true- please report it immediately as a bug or discuss it on our mailing lists! We believe that security should never be compromised regardless how easy to use a system is.
Transactions and Workflow
All actions in Zivios utilize transactions to defer execution till a later time. This allows module developers to chain arbitrary code to any transaction. Transactions are necessary as they allow:
- Arbitrary Rollback
- Workflow (deferring transactions till a later time till approved by a authority)
Currently, transactions bypass workflow and execute directly.
Managing ACLs
Right click on "Zivios, Inc" and select "Manage ACLs". This would bring you to the following screen:
These are ACLs placed on the Zivios,Inc object. ALL objects allow for ACL management. You can restrict who can read, write, auth, search, compare (standard LDAP ACLs) based on his user-id or group. Attribute level ACLs are not yet possible, but would be made available SOON.
Understanding Zivios ACLs
Some actions require Zivios ACLs. Password changing is one of them. You seen that currently ALL access is allowed to EVERYBODY. You should most likely change this something more strict (like Deny all and allow zadmin). However, when denying ALL making sure another ACL not currently mentioned: CORE_LOAD_DN is accessible by all. Without this, Ldap object loading would start throwing Access Denied exceptions.
Modules can provide CUSTOM acls, which is why we only have a TEXT field for entry (since we dont know what ACLs are required). However we do plan to list available ACLs by using some sort of Variable Reflection in the future so you dont have to TYPE it in (and induce errors!)
You can try disabling password change for a particular user. the ACL name is CORE_USER_CANCHANGEPW. Ask it to be DENIED to all users and allowed to zadmin.
