Base CAMP Boulder Colorado June 6th, 2003
Ask the Experts Session
Robert Banz, Middleware Architect, University of Maryland, Baltimore County
Thomas J. Barton, Senior Director for Integration, University of Chicago
Brendan Bellina, Senior Systems Engineer, University of Notre Dame
Keith D. Hazelton, Senior IT Architect, University of Wisconsin-Madison
Todd Piket, Analyst/Programmer, Michigan Technological University
Moderated by Kenneth J. Klingenstein, Project Director, Internet2 Middleware Initiative & Chief Technologist, University of Colorado at Boulder

Q: Are there commercial meta-directory products or are people just developing their own? People are mostly developing their own applications. If you have a very limited number of sources and targets to start with for building your directory service it's not that difficult to build your own. It's as time goes on and it grows that it becomes difficult. If you build your own starting small by the time you need a tool you will know what you want the tool to do. There are some commercial products but they are not really aimed at higher education. There is software that may help with some aspects. IMB Directory Integrator (IDI), formerly Metamerge, Sun ONE, MCS from Microsoft.

There is a metadirectories document available from http://middleware.internet2.edu/dir/ that is worth reading. Brendan solicited suggestions for updating the document, i.e. definitions in terms of directories.

Q: 1. Does anyone know how to set the size limit in AD so it can return more than 1000 entries?
2. Tested Active Directory (AD) 2003.net and most of the standard schema multi-valued attributes are multi-valued in AD. There's still the issue with not being able to use any attribute for RDN other than common name (cn). They've worked around this without violating the schema by placing each user object in a separate container defined as cn=UIDvalue so basically it looks like the following: cn=FirstNameMiddleInitialLastName, cn=UID, ou=people, dc= and so on. Not pretty, but it works, scales and does not violate the cn definition as defined in the RFC. Is this a really good practice?

One of the things Microsoft does in its object classes is in Active Directory you have the ability to define an object class to define restrictions on where it can be in the DIT and what can be the RDN component. Microsoft has chosen that cn is the only thing that can be part of the RDN component of the user object and that restricts us. This is an example of why many say Active Directory is not where we're going to put our enterprise directory. We have it managing our windows domains but we don't want to point people at it and have them look things up.

Q: Specifically in AD 2003 there is a notion of application directory and application mode, which allows you to create a directory entirely separate from the operating system directory. Has anybody looked at possibly using that as a container for the enterprise directory? We know the operating system side of the directory is highly restricted but the other side might not be.

Certainly Microsoft has heard about this. The notion of trying to get the user store to be the enterprise directory is never going to work because of the tradeoffs. In looking at the software they've taken AD and stripped everything out of it. If you've ever done an open LDAP install where upon install there is nothing, it's like that. You can use it as a proxy to AD, such as to submit to hidden fields you can't get to directly. It may be Microsoft's way of answering some of the issues people have had.

Q: How do institutions define UID, how are they assigning it, and how are they assuring that their DN is unique? The UID tends to be the UID attribute. The interpretation of that is it's a username, a login name, and a netid. It is usually 8 characters and that tends to be unique over a much longer period of time. If you look at all the identifier documents that are part of NMI (http://www.nmi-edit.org) there is a lot of discussion about reallocation and re-usability. Local policy plays a big role. Some campuses let their users pick their own user id's so they can remember, other campuses are generating random strings so they can't be guessed.

There needs to be a distinction between the user name and the login. You ought to be able to change user names without changing the DN. You can put deep in the registry an identifier that is permanent and never changes in the RDN. The thing in the RDN should be the identifier that has those characteristics that doesn't change for a very long span of time. It can however expose the breakage that exists in some clients. The client may display that thing when you want to see something user friendly because it assumes that from that DN you'll be able to tell whom it is and this is not necessarily the case.

One institution has used an access id with two characters and four numbers for seven years. Everything is built on top of that access ID. They still give the ability to choose a unique e-mail name. Another person could reclaim the e-mail name later but everything else will still be unique.

Another institution has the concept of the online ID, the user name; it's unique across campus. Don't know if HIPAA or any new regulations have played as role but as of this summer they're going to stop retiring those user names. They will live forever to prevent private information intended for one person going to another person that now has that ID.

Q: Yet another institution is going to switch their LDAP directory to be slightly more enterprise this summer. The next step is probably WebISO. Would it make sense to use Shibboleth as a WebISO? If starting from scratch Shibboleth is a good thing to use.

Q: After seeing info on Shibboleth it looks like it could solve a problem we have. Because of the privacy nature and distributed authentication how do you do tracking, auditing, security help? How do you get a handle later to go back to an institution to say this person had a problem, did something wrong, or used a pay service and has a fee due?

What does an internal federation mean to auditors who are trying to build enterprise wide policy? How long do we log etc? In terms of Shibboleth if an application needed to know whom that person was to charge them wouldn't it ask the handle server/attribute authority for that information? Doesn�t the handle service have to log the opaque string it created along with the identity verified?

There are some policy issues wrapped around this: To what degree your institution is going to provide access to the handles, and in turn identity, vs. how another institution is going to want to do it. Is this going to be one of those defining areas of a federation that under the following circumstances we all agree to share the appropriate amount of information to be able to deal with certain legal problems? They are all institution questions. In terms of exposing attributes to allow the application to track what it needs to do that is what Shibboleth is about. An application is going to want some amount of data out of the directory. Hopefully, there is a process that application will go through with some kind of a directory committee to make sure they get the data they need to carry out the job of the application. One would hope you go through the same kind of process with Shibboleth and that would be not just within the organization but also within the federation.

So the central question is: in Shibboleth 1.0 what kinds of logging options exist on the handle server side? Can you track the opaque ID's assigned? The understanding is that it does do a complete log, which will be utilized as middleware diagnostics are developed.

What about that whole issue of discoverability? If you collect the data and it's stored it ends up being discoverable. How long do we log it from the institutional perspective? If it's possible to do the handle logging, that's just defining that the technology can do it. Whether you do it and how long you keep it is a policy matter.

From the auditor perspective, they care about "are business objectives being achieved." An auditor is also concerned about risk and risk avoidance. Underlying all this is strong policy issues of IT governance. The development of these standards is not at the strategic table when management is developing their policy and objectives. Want people at the top, someone with the signature authority, to say this is the level of risk we're willing to take; this is risk we're not willing to take. It doesn�t happen that way and it's a big hole in the system at present. There is a need to have an intermediary, a forum where that conversation takes place so all sides understand the technical risk and accept it. Think often we obscure the risk, the underlying fragility/ weak link in the system. Solutions can't ignore the policy side and ideally both should be developed at the same time. Sit down and talk with an auditor to see how they approach the issue and what they look for so you can design solutions with those things in mind. Legal will also have to be involved at the right time because of issues such as retention, how long do you keep logs? Technologists should devise systems that anticipate as much as possible the range of policies and be built flexible enough to support any remotely reasonable policy.

How different is this from the issue of how long do we keep e-mail? It's a general university retention problem. Some lawyers will say no e-mail should be kept longer than it's read because it's discoverable. Other's will say keep it as long as you want.

Discussion: There were some comments during the Shibboleth discussions that the attribute authority (AA) was turning out to be a useful concept that might be applied elsewhere. There were also comments about wanting to put class rosters inside directories.

One point of view is there's got to be some standard way of referencing something outside the directory and something as dynamic as a class roster doesn't belong in the directory. There is a tendency for information systems databases to accrete new mass. Need a reference mechanism to say, if you want the class attributes redirect to somewhere else.

There is a product (name unknown) that tries to solve this problem. It allows you to front end the Oracle or any relational database with LDAP and it maps between the LDAP attributes and the database. So if you do LDAP calls and the info is in LDAP that's what you get. If it isn't in LDAP it goes to the relational database brings it back and displays it as if it is in LDAP.

Others disagreed and think it is quite appropriate to put things like class rosters in the directory, depending on what you're trying to accomplish. It's not the only or necessarily best option, it all depends on the problem you're trying to solve. You should expect growth of more and diverse information in these systems since they integrate that information between applications. It's a policy question of what does and doesn't go into the registry and the LDAP. There are technical costs and benefits with anything that goes in. It comes back to trying to create a technological infrastructure that can support reasonable policy. One thing is that you have a process where appropriate stakeholders have an input queue of requests to make data available in the identity management store. The answer comes back either yes we'll put class rosters in or no we won't. If the answer is no there needs to be a fallback that keeps the identity store potentially linkable. If you're maintaining data of interest to someone else outside of your business unit, which makes it institutional data, then you are obliged to carry whatever causes the least trouble in your system so those with proper access can link to the data.

Several people expressed that if information is going to be used for authorization purposes it does belong in the directory. That does mean the directory has to be scaleable and that you need capable metadirectory processes but authorization is what that database is for. You don't want applications to go back to the source systems to pull authorization information. That's the point of building this layer of indirection and letting target applications come to that layer rather than going to the source system. It gives you the flexibility in changing the source system and target applications. A department brings in a new application you don't have control of that. If the information they need for authorization is in your directory service they don't have to go to the source system. They don't have to create another hard linkage between their application and the system of record. It's a win-win to have that data in the directory service though it might be a pain.

There was disagreement. A function is needed to make it look like it's in some logical seamless store. Not convinced in every case all of us will decide that means it all goes into the directory. The attribute authority is a logical place to hide the fact that some of it's in the source system or some other operational data store. The consumer should have the sense it's all in one place.

Caution was sounded about back ending LDAP with other things. While there are clients out there that do that, LDAP products are designed to do specific things in highly read, very little write intensive environments. LDAP directories tend to be extremely fast. When you start back ending them with other things such as a database, that slows down processing because you have to deal with commit, transaction rollback etc. The LDAP operation, even just a search, slows down because of these things. Some companies have spent lots of money to try and tune an Oracle database to be as fast as LDAP and it hasn't worked yet.

Some are uncomfortable with keeping so much in the directory. It's basically rebuilding the ERP. The directory is an example of where we have to have redundant data. Essentially raw data from the ERP and security functionality will have to be replicated as well. Can we protect data in the directory the way we do in the ERP?

It's also true that data needs to be in the format and place where it's most useful to the applications that need it. The reporting that you do against the data warehouse would kill your transaction system. You need to pull the data out and package and store it differently. In the case of directory services it’s the same deal. You're going to have multiple data store that you pull the data from. 100% of the user base doesn't come in through the ERP. There are still exceptions. The enterprise directory is where there should be no exceptions. You're going to have the ERP bringing in 95% of people and some will come in a different way, they will all be collected in the enterprise directory. Completely entrusting the ERP is trusting too much to that solution.

Q: Compare and contrast the AA vs. the SML. Directory Services Markup Language (DSML) is XML, it's web services etc. Should a directory itself be supporting a DSML interface? Does it make sense for the AA to support the DSML interface? Should there be something else all together? Where does DSML fit in as compared to the AA?

They're all valid approaches. DSML is an SML schema that a lot of people have touted though it's not widely used. XML is probably easier to parse then ASN.1. Somebody might be more willing to write a client to query LDAP via DSML than LDAP itself. As far as the AA is concerned the AA is now going to have a web services SOAP based interface that can be queried. Perhaps one of those schemas it will accept will be DSML.

The AA's face is towards the target. And the schemas defined are already XML. There's no problem importing what you want from the SML to that message. What serves the level of indirection is behind the face talking back to the source systems. The AA knows how to talk LDAP back to the directory. Probably going to have meta-directory, connector type things between the AA and where the data really lives. Everybody is going to make a different set of decisions about that.

Q: For those who allow your directory to updated by end users, and who also maintain a registry what mechanisms do you use to ensure that the changes to the directory update the registry or do you force it through the registry before allowing it to post to the directory? If your backend is something like an Oracle database, is there a period of time when updates are not allowed because the registry is down for backups?

For one institution there is a one way feed and the database is authoritative and users are not allowed to directly modify anything in the LDAP directory server. They maintain the identity registry, removed from the Oracle database, to provide a mechanism for users to add e-mail aliases etc. in real time. The Oracle database goes down twice a week, and many applications shifted to the LDAP server since it's up 24x7.

Q: We're, charged with looking at Single Sign On (SSO), and we have talked about moving toward Kerberos, should we be moving towards PKI instead? It depends on your timeframe and budget. PKI is generally expensive to do correctly, especially for SSO. What seems to be the best solution is a smart card with a person's credentials, with readers on machines, parking lots etc. The cost is not in the certificates but in the hardware to deploy it. In the future PKI or something like it will be the way to go, in the near term Kerberos is a known thing, it's here and works.

Q: If you’re doing a layered security approach and it's not parking garages would PKI be good now?
In terms of SSO PKI gets you there faster than Kerberos. One concern about the PKI approaches is the lack of ability to enforce the users concepts of security. Are they choosing good keys, are they patching their machine? One solution is to issue the key on a token so you don't have to rely on users reading documentation. To do it correctly requires money.

A fair answer is all of the above. If you start to look at systems like XML Key Management Specification (XKMS) you start to see an enterprise approach to PKI. You would use passwords to unlock your certificate and move them down to the machine you're currently on. That's a case where one benefits the other and all of the above makes sense.

It's a complex issue and there is a number of getting started on PKI documents available from http://middleware.internet2.edu/ under the certificates and PKI section and on the www.nmi-edit.org site.

A requirements versus technologies matrix would be of great benefit. There wouldn't be a check mark in the cell, it would say "if you want to meet this requirement with that technology you would need to use the hardware tokens etc.

Something else to consider is the levels of assurance that comes with a PKI infrastructure. It is similar to the handle server discussion with logging, how long do you keep them? If you allow them to do cryptography do you escrow their keys? If you escrow your keys you're liable for certain things. It becomes a large problem very quickly.