Middleware
CorporateTime & LDAP Integration Issues
(2/9/01)
Following is a list of issues that either need to be researched or may become problems as we attempt to integrate CorporateTime calendaring into UDS/LDAP.
1. Delegated administration
What kind of delegated administration will we do? Will we delegate things like password resets and user account creation.
If we allow delegated administrators to create user accounts, how do we make sure that usernames stay unique? (Not only does the application need to know that the username is unique, but UDS needs to know so that it doesn't give that name to someone else).
Password changes could cause similar issues. If we allow delegated password changes/resets from the calendar application, how do we reconcile these with other applications served by UDS (ie, changing your password will change it for calendaring, but not for the portal or email). Can we disable password changes in the calendar app and send everyone through a common interface?
2. Schema
It appears that there's a fair amount of schema that needs to be added for each user as they're added to the LDAP directory. This is no big deal, as long as the data added is the same for each user or if the information can be derived programmatically from other information we have about the user.
For example, the ctime admin manual states (p.23) that we'll want to size things with about 10,000 users per node. This will probably give us 8 or so calendaring nodes. It looks like node membership is something that's stored in LDAP. How will we know as we import users what node they're supposed to be on?
(There's some information on the schema needed in the admin guide starting on p.61 and in the appendixes, but we'll need to know more than what's there).
3. Importing users
There's an import procedure that needs to be done once a user is in LDAP to import them into the calendar application (admin guide, p.61-63). As long as we can call out to run this utility programmatically, we should be ok.
The utility that synchronizes LDAP information with the registry is a set of perl and shell scripts, so we can easily call out to command-line utilities. A lot does depend, however, on how well the ctime utilities do in process management, returning error codes, etc).
We should also make sure that the platform we choose for ctime has sufficient support for scripting utilities. Any Unix flavor should be fine, but I'd be nervous if we were contemplating doing this on NT.
4. Deleting Users
The ctime admin guide (p.66) recommends that you not immediately delete accounts, but instead rename them until all of their scheduled activities have passed.
This seems like good advice, but we'll need to consider how to reconcile this with a user's status in the registry. We may have to do something like marking the user as inactive in the ctime LDAP instance once they go inactive in the Registry, then running a daily job on the ctime LDAP instance to clear accounts that have been disabled for more than X (days/weeks/months).
5. Groups
It's not clear from the ctime admin guide exactly how groups work. From some very brief testing, it looks like groups might be entirely contained within the ctime system, with no information about them stored in LDAP. I'm hoping this is actually the case.
If we do need to provide some group support in LDAP, we'd want to do it via dynamic groups whenever possible. We'd also need to figure out what our grouping criteria was so that we could either populate the groups (in the case of static groups) or create the group criteria objects (in the case of dynamic groups).
The admin manual does state on p.68 that ownership of public groups 'is exclusive and cannot be transferred'. Since people will appear and disappear from the calendar server as they appear and disappear from UDS, this probably means that we need to create service accounts to own each public group.
If we allow end-users to create public groups, it looks like these groups will disappear when the user does. There's probably not much we could do about that (and I'm not sure we'd want to do anything about it anyway).
6. Data that goes beyond people
The ctime admin guide spends a fair amount of time talking about setting up scheduling for rooms and resources. We'll probably want to consider adding these things, but we need to keep in mind the following:
The UDS was constructed to be a 'people registry'. There is no data in it presently about rooms, courses, or other resources. There are no plans to add this information to the UDS.
If we do need to funnel this information into the calendar server, we'll probably have to look at a direct feed into either the ctime database(s) or the LDAP instance used by the calendar system.
This is almost certainly going to be a huge job.
7. Security
We consider the following a baseline for good security when connecting to UDS datastreams:
- Passwords stored in hashed or encrypted form. If the application caches them, they need to be hashed or encrypted in the application as well.
- Network comms between app server and LDAP server either encrypted (SSL) or firewalled onto a private net.
- IP Restrictions on the LDAP service account that the application uses.
- OS-level firewalling (or TCP Wrapping) on the LDAP host to limit incoming connections to only the application server and trusted administrators' machines.
If any of the above are not possible with ctime, we'll need to find a workaround that doesn't detract from the overall system security. Since workarounds may involve either different or additional hardware, we'll need to have answers on the above before we buy hardware.