TechTalks Transcript
Campus Directories
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Jeff Hodges [JH] |
 Frank Grewe [FG] |
April 22, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk Series for Spring of 1999, and to this session on Campus Directories: How, How and Who? You are here because it's time to discuss the core technologies in your future.
This is Judith Boettcher, your CREN host for today. I'm pleased to welcome the technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known Web and all-around Information Technology expert. Welcome, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of technology Webcasts. The job of the technology anchor is to engage our guest expert -- or in this case, our guest experts -- in a lively technical dialogue that will answer the questions you'd like answered and ask those very important follow-up questions. You can ask our guest experts, Jeff Hodges and Frank Grew, your own questions by sending email to expert@cren.net any time during this Webcast. If we don't get to your question during the Webcast, we'll provide an answer in the Webcast archives.
In past TechTalks, we explored questions such as "How can I do surgery over the Internet?" or "How can I make telephone calls over the Internet?" "Who can sue me because of what I do on the Internet?" And the most basic question of all, "Who am I?" We've also discussed middleware, the basic glue that holds our distributed network systems together.
Directories, our topic for today, is an important part of that glue and they help to answer the "Who am I and what am I allowed to do" questions. No doubt, you've used directories and know quite a bit about them. In a printed telephone directory, for example, you can look up a person's phone number or find out the nearest place to have your car repaired. These valuable directory-services-and-more have analogues on computer systems that all of us use every day. No doubt you have an email address book, can look up other folks' email addresses, and have access to some systems that require you to provide ID and a password. These are common examples of directories that you know a great deal about and that have been used in computer systems for decades.
Directories actually are really very simple things. You provide some key, such as a name, and use it to look up some data related to that key. A directory could be a simple table or a simple relational database. All of this has been done long ago and is available everywhere.
So how can we do a TechTalk on such basic, common stuff? In talking with today's two experts, it became clear to me -- as it will to you -- that our knowing all there is to know about directories is an illusion caused by our familiarity with directories and our comfort level with the crude way directories have been implemented in most places so far. Like Conrad Cornelius O'Donnell O'Dell in Dr. Seuss's On Beyond Zebra (who is surprised to discover that there is more to the alphabet than the letters from A to Z), you are about to discover what is beyond the directory services that most of us are familiar with. As Cornelius says:
'Now I know everything anyone knowsToday, we will quickly review the A to Z part of directory services, but we need to go far beyond that. We need to do that because directory services were first developed when we had very simple isolated systems. Our systems have multiplied, become distributed. They require appropriate tools that match the sophistication and maturity of our current systems, and the systems we will run in the future.
From beginning to end
From the start to the close
Because Z is as far as the alphabet goes.'
Then he almost fell flat on his face on the floor
When I picked up the chalk
And drew one letter more
A letter he had never dreamed of before.
And I said, 'You can stop if you want with the Z.
Most people stop with the Z, but not me.
In the places I go, there are things that I see
That I never can spell if I stop with the Z.'
Cornelius sums it up much better than I can:
You'll be sort of surprised what there is to be foundWhile we probably still won't know all there is to be known, Jeff and Frank will be taking us some distance in that direction in today's Webcast of TechTalk.
Once you go beyond Z and start poking around.
So on beyond Zebra, explore like Columbus.
Discover new letters like Wum, which is for Wumbus.
So on and beyond Z, it's high time you were shown
That you really don't know all there is to be known.
Judith?
JB: Thank you so much, Howard. I was anxious to hear those extra letters that come after Z.
HS: I have a picture of them, if you would like.
JB: Let me tell more about our guest experts for today's TechTalk (and also more is at the Website for today's event).
Frank Grewe is a manager in the Academic and Distributed Computing Services Unit of the Office of Information Technology at the University of Minnesota. And in that role, Frank tells us that he manages virtually all the Internet services at the campus level, which includes things like the directory services, mailing services, newsgroups, etc.
Jeff Hodges is a senior technical staff member in -- and I'm going to trip over this, Jeff, this is a very long title, but I will read it out anyway here -- Directory Services and Public Key Infrastructure, Computing and Communication Services, with Stanford University.
HS: See, that goes way beyond Z!
JB: Oh, right! It's the first time I've ever seen Public Key Infrastructure in a title, Jeff. You'll have to share with us sometime how that all happened.
Jeff has been working in the directory services field at Stanford since 1994. He contributed to the production deployment of Stanford's first phase of the registry and directory infrastructure system in 1996 and was responsible for deploying and operating the stand-alone LDAP directory services that were part of that system. Jeff is also an active contributor to the LDAP effort in the IETF and co-author on two Internet LDAP RFC drafts. Additionally, he's been consulting in the directory services area under the Kings Mountain Systems moniker.
I'm really pleased that we have these two experts who are nationally known in the building of these kinds of directories to chat with us today about directories. Welcome, both of you.
JH: Glad to be here.
FG: Happy to be here.
HS: Okay, why don't we start off, Jeff and Frank, by establishing some foundation here. Perhaps you could both take a poke at telling us what a campus directory is and why we need them.
JH: Frank?
FG: Well, when we first implemented a directory at the University of Minnesota, it was about six and a half years ago. And at that point in time, we felt we needed a directory because we were going to implement email for all students and staff campus-wide (which comes to about 90,000 people), and we needed to have a way so that people could find each others' email address. And that was pretty much limited to what our vision of a directory was at that point in time.
Since then, we've learned that there's a lot more than just finding out where somebody is or what their email address is or what their telephone number is -- that directories have considerably more to do with the workings of the university, with the workings of our applications than those simple concepts that, generally speaking, are what people think of.
HS: Could you tell us a little more about that? When you say the "workings of the university."
FG: Primarily today, the biggest use of our directory is for authentication and authorization. That is probably the largest single thing that has grown over the last six years and continues to be our primary focus when we look at directory growth and usage of the directory.
JB: And you mentioned one thing, Frank, about the fact about finding where people are. After talking with the two of you, it seems to me that we are more interested in just finding people and it doesn't matter where they are.
FG: That's very true, although there's a lot of nice features one can build into the directory. For example, our Web-based directory: when you click on somebody's office address, a map pops up and shows you exactly where on campus you can go to find them. But that's an individual looking up another individual. What is the largest single use of our directory is applications determining what individuals can and cannot do within the various applications that run on campus.
HS: When we talked to you before, both of you said that most universities really hadn't done very much with directories. If directories are so important -- and they seem to be -- how do these universities get along without them.
JH: Well, I don't know. I think there's actually a fair amount. It's hard to say. A lot of places have directories utilizing some protocol, running on some database. I guess maybe what we were trying to imply is that using the open standard protocols -- X.500, LDAP and such -- is relatively new.
For instance, here at Stanford, we've had a nominal directory for a long time -- since before I got here in the late '80s -- and you could access it is using the who-is protocol, which is extremely rudimentary and is not suited at all for doing the sorts of things Frank is talking about, where applications do lookups. It's much more suited for just simple, casual queries by individuals. And so we provided descriptive information about people via that. It wasn't until we were really thinking seriously about providing email addressed strictly by the stanford.edu domain rather than by specific hosts that we realized we really needed to use a more formal notion of a directory service.
HS: It sounds like you're saying that lots of universities are using some really old technology to do directories, but that LDAP and X.500 are newer technologies. What are the kind of things that they add if you're a university and you're thinking about going to X 500 or LDAP? Why would you do it?
FG: I'd back up a second and say that I think a lot of universities have silos of data where they might have some very good idea of who their current staff and faculty is, in some cases, or they might have a very good idea of who students are in particular departments.
But a central directory -- where they actually have all people who have a relationship with their organization -- is sometimes very hard to find. In addition to students and staff, you have retired faculty, you have alumni, you have people who are associated -- consultants, for example -- who are associated with your organization for short periods of time. All these individuals, in addition to have email perhaps have other types of rights or entitlements within your organization. And the ability to be able to centrally manage the entitlements that people have is oftentimes not present in a lot of organizations.
JB: And Frank, when you say silos, what you mean -- you're from the farm country up there, right? You mean that there's multiple organizations across campus that all have different databases with different information in them -- is that what you mean?
FG: That's right. You might have a very good HR database with your faculty and staff in it, and the very same organization can have a very poor idea of exactly who all the students who should be able to have computing access on campus are. Or vice versa, and whether or not you have a good handle on who your consultants are -- who is really using your network?
JH: Right. And the example here at Stanford is that faculty and staff are handled by the Personnel organization and they have their own mainframe-based database, and students are handled by the Registrar which has its own mainframe-based database.
FG: And then we have the Alumni Association. The list goes on and on. There is no one campus group that necessarily manages all of the information.
HS: But then who manages the directory? It sounds like there's silos of information around and it sounds like the directory needs access to that if it doesn't have the data in it itself.
FG: That's really the role of the directory, in my view -- to bring together the information from these various sources and be able to present it as one unified piece of information or one unified group of information.
JH: Yeah, I would tend to agree. A coherent schema, in a way.
HS: But then some central organization manages THE directory or directories? Which is it?
JH: Well, the model we seem to be evolving here at Stanford is, yes, a central administrative organization -- which is Communications Services. We run the directory which in some contexts we term the "enterprise directory." And this is getting a little bit down the road, I think, of where we want to go, but to give a peek in terms of this conversation, other departments will undoubtedly buy directory-enabled software including directory services off-the-shelf and then ask to integrate it with the enterprise directory service. That's a big thing to figure out how to do down the road.
HS: But you are saying that it's essential that somehow these directories be centrally managed? We can't have directories scattered all over campus.
FG: I would agree that you have to have a central directory, a central repository. If nothing else, if you're going to manage things in groups around campus, you have to at least have a directory hierarchy so that there is one place you can go to find out the definitive information on an individual.
The people who manage the directory, however -- there should be a big distinction between managing the directory and owning the data. The directory managers are not the data owners. The data owners are the student systems, etc.; and the people-who-are-managing-the-directory's job is to present this information and also guard its privacy, because we have private data as well as public data about individuals.
JB: It sounds like that's a really important distinction in terms of getting the cooperation across campus for access to all this data. Is that true?
FG: That is very true -- that we are not running a new database. That is not what our job is in managing directories. We are managing the presentation of existing data and the data owners have control over the data and have control over what is displayed and made public and what is reserved and kept private.
HS: But isn't the directory a database?
FG: I would make a big distinction between a directory and a database. A database -- typically you would have transactions against it, you would be looking at being able to back out transactions, all this sort of thing, a lot of traditional things that you think of when you think of databases. Directory technology is one where you have extremely fast and reliable read-access to information.
JH: Right, and actually on the Webpage, we have Exhibit 5.
JB: Is now a good time for people to go to that if they're right there?
JH: Sure, and I mean, it's a long talk by Steve Kill which is precisely on the topic of what the difference is between a directory and a relational database and the scenarios where you would use one or the other or perhaps both.
HS: In fact, for folks who are looking at the figures, I've just been informed that figures 7 and 8 have just been added, so you can refer to figures all the way up to 8 now.
JH: So reload the page if you haven't done that recently.
HS: Jeff, Frank, one of the things that I've heard about, just poking around in some of the literature, is something called "registries." Now that we've talked about directories a bit, what are registries? How do they relate to all this?
JH: Well, the definition we came up with for them is that it's "a service that serves the needs of applications for coordinated maintenance of identity information about a class of business objects." And I guess that's kind of a fancy (and perhaps a somewhat vague) way of saying that although we're not the data owners necessarily, we are adding value to the information in at least two ways.
One way is providing uniform access to the information via the network and open standard protocols. And also we're doing some synthesis where, at least here at Stanford, we've come up with ways to classify the affiliation of an individual represented by an index. So then it's possible to do the authorization function that Frank has been talking about. Without doing that synthesis and coalescing that information, you would have all these disparate notions of affiliation that come from all the disparate source systems, and we wouldn't have a cohesive notion of affiliation.
That's part of the value we're adding, and we do that within our registry. That's a registry function. And then we use the directory to disseminate information via open standard network protocols.
HS: Perhaps we could turn to some of the things that are actually in the directory. You've been talking about people being in the directory, but are there other things, other than people? Are there applications, services, groups, other kinds of things?
FG: Yes, in our situation at the University of Minnesota, in addition to people, you would have various types of applications registered, various types of groups registered, departments are registered in the directory, etc. They, of course, don't account for anywhere near the same volume as the people, but there is certainly importance there in terms of --
HS: But if you have a person there, well, maybe we could talk about what information do you keep on a person vs. what kind of information do you keep on, say, an application? They seem like quite different things to me. And it seems a little strange that they would be in the same place.
FG: They are completely different objects, however. In a directory structure, you define the different types of objects you're going to have in your directory. For us, we have people-objects. We call them "University of Minnesota persons," for lack of a better word. (X.500 likes long names, so that's where we're coming from.) But we also have applications in the directory, or departmental objects in the directory. These different objects would have totally different sets of attributes.
HS: Could you give us some examples of the attributes you might have, say, on a person and what you might have on an application -- just to give us some sense as to what's kept in the directory?
FG: Well, a person, for example, is certainly going to have a job title, a department that they work for. If they're a student, they're going to have a major. They're going to be taking a certain number of credits this quarter, a certain number of credits the last quarter. They're going to have registered for different classes, etc. And a department, of course, is not going to have a job title associated, but it will have a director. It will have a principal secretary perhaps or other types of roles that are within that department and those roles might point to people-objects.
JH: Right, exactly. Yes, I agree completely.
HS: Is all this stuff really in the directory, or are there just pointers from the directory out to this stuff? I think you'd want to keep as little stuff in the directory as you could so that you wouldn't have synchronization problems.
FG: In our situation, we would classify attributes as being two types.
One type of attribute we definitely keep in the directory at all times, and those attributes would be ones that we want extremely fast access to. An example would be your email address that you really receive your mail at.
Other attributes potentially don't have to be in the directory, but instead, the directory has a pointer. In other words, it's sort of a meta-directory and it's pointing to a file offline. And an example of that would be a photograph, for example, of you. That's not something we want in the directory itself, but in a separate area. Something that's not in the directory would typically be something that is not accessed a lot or that, when it is accessed, a time delay is not a significant factor.
HS: I assume that some of the data is off in university HR systems and things like that, right?
FG: That is where the source of the data is, but we would actually keep a copy of that information online in the directory.
HS: And you do that just to speed up access or to solve sync problems? Why are you doing that?
FG: Speed-of-access is certainly a situation. Also, a single point of failure. We currently are running three completely parallel directories here on campus. We have to have directory services up 24 hours a day, seven days a week, without interruption. We can't take something down for backup or --
HS: So you have replicated your directories three times.
FG: That's right. There are three copies of them active.
JH: Yeah, we're doing the same thing.
HS: And if some application goes off to a directory, somebody decides which one it's going to go to.
FG: We're using the DNSA records in our situation, where we actually have three A-records pointing to the servers on campus that round robin.
JH: Mapped to the same name?
FG: Yes.
HS: And if you're using copies of the data, how often do you update that data? I mean, data gets changed all the time. So if I look at your system and you have copies of the data, is it in sync overnight?
FG: This depends on the source of the data. Our primary data sources of HR and student records are synchronized. We get the delta changes for the day from those sources overnight. Someone who changes their email address -- something that an individual, for example, can change online, that is synchronized immediately. (There's caching involved in that, by the way. We could talk a little bit about that.) But then there would be other data that we might have received from departments. For example, IT students have some attributes associated with them from the departmental level that we might update only once a quarter or two, three times a quarter, something like that.
JB: And Jeff, what about you for the synchronization or the updating of the data? How often do you do it at Stanford?
JH: If the change is made in a source system, we get the change immediately.
HS: One question related to this is, do folks update their own data?
JH: Yes.
FG: Yes.
HS: Okay, so that's not just part of the directory operation. That's really part of your Human Resources operations, etc. So somebody who wants to update their own address, for example, is updating it in the HR system. Is that what's going on? And then it's reflected back in the directory.
FG: At the University of Minnesota, this depends on the nature of the data. If we're talking about an email address or a password, that's directory data so it's changed in the directory, vs. HR data is changed on the HR system and then reflected back up.
HS: Okay, then you have some scheme so that if it's changed in the directory, you have these three replicated directories, so somehow it's got to get immediately propagated to the other directories.
FG: In our situation, what actually happens for change management is that after a change passes our business rules, it is sent off to a registry. Before we talked, I really didn't realize I had one of those! But we call it a registry, and the registry is responsible for sending that on to the three copies of the directory so that they get synchronized up.
JH: And at Stanford, Exhibit Number 2 is applicable here, and it actually is very similar to University of Minnesota.
Some information gets updated directly into the directory via the Web-based user interface. For example, we've secured agreements with Personnel that they will allow us to provide the user interface for updating a person's descriptive information. Now, this is like phone number and address, mailing address, let's say. And they will actually take that information via the event broker on our middleware stuff and incorporate it into their system, so they are actually going to retire part of their user interface. Note that the Personnel system only handles faculty and staff. We have not been successful at securing such an agreement with the registrar, and the registrar's system has its own user interface which --
HS: Those are those blue boxes.
JH: Yes, which is called Access, which is a Web-based program that students use to update their information. So they have to go to that user interface and use that, which updates the Registrar blue box and then the information flows through.
JB: But for the personnel, what you've done is actually at Personnel -- they've identified a portion of a record that is owned by the person, the individual themselves. That's interesting.
JH: Yeah, they've actually provided that functionality for quite a while. They've provided their own user interface, a mainframe-based program that I've used to manage my own information.
We've believed in delegating responsibility to the user as much as possible here at the institution overall for quite a while. Though that was Personnel's turf; they have their own user interface and their own system and such. And a theme -- as systems become more and more distributed and directory systems are just one symptom of that -- is that people are going to have to be willing to let go of the reins on certain things. Source of information may be one of the thing, and as the example in particular here, entrust other people to supply that information.
HS: What you're saying is that data has to become a university resource, which it is.
JH: Exactly.
HS: That's a real difficult thing for folks to accept, but it seems inevitable.
Wonder if we could take some questions that we have coming in at expert.cren. (And we would encourage you to send in your questions to expert@cren.net.) We have a question from Steve Wood, and I'm sure I'll say the corporation wrong, so I'll spell it. It's XIOX Corporation. Steve says, "Can a directory include related pulldown information? For example, a pulldown list of valid office locations so that the user can pick from this list rather than manually typing (and likely misspelling) the information?"
JH: Sure.
FG: Sure. And I would recommend that highly for things like departmental names. If you allow that to be a free text, it's unbelievable what department people think they work for!
HS: Sure, if people can mistype something, they will. They will find creative ways to do that. We have another question from Scott Brummage from Forest State University, and Scott says, "The best network security techniques can always be circumvented by human carelessness. Given this and the desire to coordinate and synchronize various directory services for a given organization, should there be some directories which remain completely isolated and inaccessible except for a few trusted IT workers? If so, what kinds of information should be so protected?"
JH: Well, an example of that that we're doing here is we have a Kerberos-based authentication infrastructure, and the Kerberos key distribution server has its own database. You could call it a directory. And that which stores the secret keys -- that map to all the subjects, which are people -- and that information is going to stay on the Kerberos KDC, locked away someplace. (I don't even know where it is physically.) And that information's not going to be put into the enterprise-wide directory service. That's one example.
FG: In our situation here at Minnesota, we feel very strongly that directories have to be given the same level of security on the network that you would potentially give a certificate authority -- which you would give a Kerberos key system -- and the reason is that one of the easier ways of breaking security is not necessarily my becoming you, but my obtaining your authorization attributes. So the attack is to go against the directory and change the few little flags that say, "Yes, this person can go into HR and change salaries." You've suddenly found a way around the system without becoming somebody else.
JH: Right, just giving yourself added authorization.
FG: So it's very, very important when you're designing your directory to be looking at the security issues behind preserving that data and making sure that your data is going to be accurate.
I think, going back to the registry idea, that is one area that you want to take a close look at -- that you have a separate location that really is the master as far as what all the data ought to be, and that you're not relying solely on the directory itself or some update to it that somebody comes in there and surreptitiously changes things.
JH: Right, and I wasn't implying that we don't have security wrapped around our enterprise directory. We actually have quite a bit. I was more pointing out that the question was asking, was there anything that we wouldn't put in the directory, no matter how much security we wrap around it. And yes, in our case, that's like the secret keys for our authentication infrastructure are not in the commonly-available directory service.
But there is information in there that is passed out to only certain classes of requesters. And actually, that's one of the features that we've given users is people have the ability, on a nearly attribute-by-attribute basis, to declare who can see what information about them. And the granularity we're deploying right now is private, or Stanford community, or Internet at large.
HS: So someone could decide that you shouldn't be able to look up their office address, for example?
JH: Correct. And I can go to our Web interface, if you're looking at Exhibit Number 2, right now I could do it from my workstation right now, and change the privacy settings on my office address to Stanford community or private and you wouldn't be able to see it.
HS: Now, with respect to authorization and authentication, I forget which of you said you were using Kerberos, but one of you said?
JH: I did, Stanford.
HS: Okay, and I also hear that directories and registries can be used for authentication and authorization. How does that fit together when you're using something like Kerberos and you're also trying to use directories to do some of this? How do those interface or how do those work together?
JH: The authentication system is a formally separate system. And the way we access the directory, if I want to access it as myself, Jeff Hodges, I have to authenticate to the directory formally. And there is an operation in both X.500 and LDAP which is called BIND. And the BIND operation can carry authentication credentials. So the first thing I do is I go have a conversation with the authentication system and obtain my credentials.
HS: That's with Kerberos?
JH: That's using the Kerberos protocol.
HS: Okay.
JH: And then, I jam those credentials into a BIND packet or a BIND operation, toss that into a packet and ship it off to the directory service, and I BIND using those Kerberos credentials. We have configured our directory service on the back end to understand Kerberos authentication. The protocol allows for this, but you typically have to configure your directory service --
HS: When you say the protocol, do you mean X.500 or do you mean LDAP?
JH: LDAP. X.500, I'd have to look at the protocol spec. It has a notion of strong authentication. I'm not sure it explicitly allows for putting Kerberos credentials in there. I haven't looked that closely at it. The LDAP protocol allows for explicit Kerberos authentication.
HS: And you can't get to the directory without authenticating yourself to Kerberos?
JH: No, we allow anonymous access. You can do anonymous queries, but the information that is revealed to anonymous requesters is very limited.
JB: That would be the Internet-at-large setting, then?
JH: Correct.
HS: Frank, does it work similarly at the University of Minnesota?
FG: It's similar. We do not have Kerberos at the University of Minnesota. You would BIND to the directory and the authentication information is in the directory as well as your attributes, so your authentication key -- it's actually similar to Unix in that it's a hash of what you would consider --
HS: Okay, just like the Unix password schemes.
FG: That's right. Not that terribly different from that, but --
HS: So your systems are easier to break into than Jeff's.
FG: Well, I would hope that my servers aren't any easier to break into.
HS: Just trying to give our listeners some advice as to where to attack here!
JH: That's not necessarily a correct assertion. It all depends.
HS: Well, I was trying to get you to challenge that, if that was not correct.
JH: It depends. That's a true assertion if University of Minnesota passwords are going across the net in clear text, then that's a true assertion. If they are not, then it is not necessarily a true assertion.
FG: On the other hand, you know, with Kerberos, so many times I've seen Kerberos implementations and then the Kerberos client so happens to be sitting between where you're typing in your password and there's a nice clear text path all the way to the first Kerberos client that you're actually doing this authentication against the Kerberos server,�
HS: I'm sorry I brought this up!
FG: But nonetheless, we're off directories here.
JB: We can talk a long time about this!
HS: We'll do a TechTalk on Kerberos.
JB: Yeah, I think so.
HS: I think we have plenty of material, actually.
FG: Clear text passwords are a terrible thing, no matter where they are.
HS: Correct! We talked about a number of directory services. Are there others that either of you want to mention that would be of some interest to folks listening or that would be unexpected?
FG: At the University of Minnesota, the ID cards that are issued to students and staff are linked with the directory so that the magnetic stripe that is on the back of the ID card is a pointer into directory services. Thus, people can use their ID card to determine whether they're qualified to get into a particular computer lab, into sports and rec, onto the golf course -- a whole wide variety of access rights that have to do with your ID card are actually transactions against directory services.
JB: And you have sufficient card readers around for access, determining that?
FG: That's right. Going into a public computing lab, for example, you would swipe your card and there are labs on campus that are open to all students. There are labs that are open to students that are only taking particular courses or are in particular majors, etc. And so those types of resources are governed by your attributes in the directory.
HS: We have a couple more questions that came in. One just came in from Kelly Carter. She's at Berkshire University in Macon, Georgia, and she says, "Could you please give more examples of how the LDAP is used when the LDAP has been loaded with data from Personnel, the Registrar, etc.?" I think she's trying to understand a little bit more about what LDAP really is and does. Maybe that's her question.
FG: I guess I would look at it and say that LDAP is simply a protocol to get at directory information, and certainly in our case, we have other protocols than LDAP to access the directory. Certainly, LDAP is the one that you would want to prioritize if you're starting from scratch at this point in time, but how it's used, I would hope my example of access to labs, etc., is sort of a different way of thinking about using LDAP to get at something.
JH: Right, it's using it as an authorization service.
JB: When we were talking, we had talked briefly about this overall space that's being taken by X.500 and LDAP and DAP and databases. Do one of you want to just clarify how those are related? In 25 words or less!
HS: That would also help answer Kevin Schala's question from the Illinois Institute of Technology who also was trying to understand a little bit better about the relationship between LDAP and X.500.
JH: Well, X.500 is a suite of protocols that defines a directory service. One of the suite is called DAP, Directory Access Protocol, and it specifies how a requester can perform operations against a data store -- where that data store is, the data in the directory.
And an example of an operation would be doing a search on some given attribute, say common name, and retrieving entries that match some assertion that the requester is making about what the common name should contain, like "Frank," for instance.
LDAP is a lightweight version of DAP that was designed in the ITF because at that point in time -- back in the early '90s -- it was very hard to create a complete DAP implementation, even client-side implementation, on personal computers of the day. And so it ran directly over TCP/IP, which DAP did not do at that time, and provided a more narrow set of functions. That's basically it.
JB: And LDAP, just to further contextualize this, is now in its Version 3 format. Is that correct?
JH: True. It's a little more fine-grained than that. Version 3 is a proposed standard, which means that it might change a little bit. But we believe it's largely done and it's at a point where it should be implemented and it is being widely implemented. And based on experience with it, the standard may change a little bit before we hopefully get it progressed all the way to full Internet Standard.
HS: One other thing that Kevin Schala asked was where could he go to learn more about LDAP and X.500. My assumption is that we have some fairly good pointers from the CREN Website right now. Is that true?
JH: Yeah, I would say so. The LDAP/X.500 roadmap being a very key link.
HS: We have yet another question from Jeff Lemich from the University of Maryland, and his question is, he says, "If we expect departments to use information in the directory rather than extracted data from the production systems, is it necessary that they have easy access to the directory?" The second part of the question is, "What rapid application development or reporting tools such as MS Access, Filemaker Pro, Brio or Crystal Reports, etc., allow for the seamless integration of database LDAP information?
JH: Well, I can take the first part. The first part, if I remember --
HS: I can read it again.
JH: Is easy access, and the short answer is, yes. The second part was, gee, what about all these development tools? Do they provide plug-and-play development capabilities for mixing LDAP and databases and such, and shucks, I don't know.
FG: The second question is one I also have to claim I don't know. It is necessary, though, that departments have the easy access. But in addition to easy access, they have to have controlled access. Because it's one thing to say the department is going to use the public data in the directory -- those things that an anonymous request would find out. It's quite another to say that a department needs to use some of the data that's considered sensitive or private about an individual.
In those cases, we have a very informal way for an application to say, "Here is the data that I need about somebody from the directory," and then those things that are not public data, we take it and pass that request to the various data owners so that they can sign off and say, "Yes, that application does in fact have a good business reason to be using that piece of information." So it is easy access, but we still have to remember that the data owners behind this data have to have the control over who gets any type of sensitive or private information.
JH: Yeah, I agree completely and the term you've used before, Frank, I believe is "need to know," right?
FG: That's right. And the directory managers are not the ones who determine that.
HS: We only have about 13 more questions to do.
JB: Did you want to take one of those or did you want to add a practical end-of-the-session line?
HS: I'd like to sneak in two questions, if I can, at the end. Our normal end of the TechTalk question and then one beyond that, if I can. So the next-to-the-last question maybe is how -- when should a university get started in implementing directory services? What should they do to get going?
JH: You want to shoot at that, Frank?
FG: I guess the first question is what are all the groups that have the information on the people who are part of your community? You have students, you have staff, you have consultants, you have alumni, you have a wide variety of people who are a member of your community. Where all do you have to go in order to get that information so that you can get all the right people involved?
And then there has to be somebody who's going to sponsor this effort, and the person who sponsors it certainly isn't going to be a member of HR, isn't going to be a member of Student Records, etc. The sponsor has to be somebody who is going to be looking at this from the university enterprise perspective and say, "Yes, it is really necessary for us to have a central place that we can go to to access this information." A technical person will never be the good sponsor. You have to have somebody who's well-respected across all departments and groups within your organization.
JB: And you didn't mean to say that the IT folks wouldn't be well-respected, right?
FG: No, that isn't what I meant! I'm just trying to say that us techies aren't the guys to do that, that might be carrying that torch.
JH: And another way to do it -- and perhaps doing it in parallel with Frank's description, which is somewhat top-down -- is also the bottom-up way (which is a way some things get done here at Stanford), is you do what you can and create a service and get people using it and then combine their desire to have even a better service along with that sponsorship to help finally close the gap and make it a for-real supportive service.
JB: That sounds great.
FG: One of the things Jeff mentioned as a thing to get things started was that one of the impetuses behind the directory was the desire to have email be at stanford.edu.
JH: Right.
FG: That's a real good one because you can grab hold of that one and I think a lot of people can relate to it. And in order to do that, you need to have some sort of simple directory system.
JH: Right.
FG: So email is kind of a techie thing that you can use to try and bring a need for this forward. That's certainly what happened here at the University of Minnesota.
HS: Okay, you may have answered my last question, but I'll ask it anyway. Just in case you haven't! But in setting up these directory services, how much of this thing is a technical problem vs. how much is really administrative or political?
JH: Well, the hardest part is the political part, I would say.
FG: I would certainly agree. I think that you get the good technical people in a room and we can do the job. Here at the University of Minnesota, the actual technical implementation of our directory actually took place between mid-July and Labor Day in the year that we had to put it up. So I mean, that was pretty darn fast compared with, I would guess there was probably a year of meetings before that.
JH: To get the data feeds.
FG: To get the data feeds, to get everybody on the same page, okay? So comparatively in time, the technical part will not be the one that's going to hold you back.
JH: The other thing that pushed things here not only was the desire for @stanford.edu email, but also that we had had the who-is based directory service for quite a while that had a very funky, not very well understood data feed that took days. We had a change in the HR system and it took days -- it still takes days, because that system's still running, for the change to appear in the who-is system. And as more and more people started depending on who-is, we were getting more and more questions, especially at the beginning of a quarter. "Hey, I just made a change to my phone number or my address. Why isn't it there yet?" And a big part of the second phase of our project here that we're in pilot on right now is to smooth out the data feed and make it understandable and also much faster. And because of that desire in the community to see it, that gave us the oomph, the political oomph to get this to happen.
JB: So it was that real-time, up-to-date data that people really want to have?
JH: Absolutely. They make a change and they don't see it for four or five days, they really wonder what the heck's going on.
JB: They probably think it fell into a black hole somewhere and didn't happen, right?
JH: Yeah, exactly.
JB: Howard, do you want to ask our guests if there's any final question or comment they have before we kind of wrap it up, and we'll do that?
HS: Jeff, Frank, is there any final thing you'd like to say here? Nope, I guess not.
JB: I guess that was a pregnant silence.
HS: I should mention that we did have several other questions come in. We just simply didn't have time to ask them, but we will pass your questions to Frank and Jeff and you will see an answer eventually in the archives. So don't think we're going to ignore your question. We would never ignore a question here!
JB: We do try and get those questions answered, actually, within the next 24 hours, but Jeff or Frank, hopefully you can do that.
HS: So Suzanne and Wayne, two people I see who've asked questions, we will get your questions answered.
JB: Okay, great.
JH: I do want to point out Exhibit 8, for my final thing to say, has a bunch of pointers to documents and Webpages here that describe a bunch of our background thinking on registries and identifiers in the directory, and the applications that are going to use it. So that's a resource for people to go use to look at that stuff.
JB: So as they start thinking about how to do this, then, that's a good place for them to start?
JH: Sure.
JB: Okay, great. Thanks to all of our guests and to our Web participants for being with us here today, and as we mentioned, Jeff and Frank will be answering the questions that we didn't get to individually and then posting them on the Web.
I'd like to invite everyone to come back just next week. It's seldom that we have two in a row here, but we have another TechTalk next Thursday, one week from today, on April 29th. And that TechTalk will feature a very key topic, on Tools for Teaching and Learning Online. We will have two guests again. One is Joan Gettman from Cornell and Nick Laudato from the University of Pittsburgh who will share with us how they are supporting faculty in their use of online courses. So please plan on joining this session and inviting your friends and colleagues. Check the Website also for upcoming spring events, and as always, let us know if you have any suggestions or feedback on what or whom you'd like to see and hear on TechTalk. Thanks to all who helped to make this possible today. Was it Cornelius that had the A to Z, Howard?
HS: Yes, it was.
JB: Okay, to Cornelius; the Board of CREN; our guest experts, Frank Greweee and Jeff Hodges; technology anchor, Howard Strauss; Web content producer, Terry Calhoun; Harold Ansell, Lee Perlis of CREN; and Paul Bennett and Martha Vander Kolk at UM Web services; and all of you for being here. You were here because it's time. Bye, Jeff. Bye, Frank.
JH: Bye-bye. Thanks a lot.
FG: Bye.
JB: Bye, Howard.
HS: Bye, Judith, bye, Frank, bye, Jeff. Take care. Bye-bye.
