Middleware
Commoditize UDS
A Working Group
Project Description
The purpose of this project is to make the UDS easy to use, but well controlled. One way to do this is to create common components and associated documentation for developers to use; essentially, creating an API for the UDS.We plan to release these components incrementally and as quickly as possible. In this process, we will transfer Middleware knowledge of the UDS design, capabilities and limitations to AppsTech "go to" folks.
Look here for a description of our approach and working group members.
Approval Process for UDS Access
Applications must obtain approval to use any element or attribute in the UDS by submitting Draft Form Request Download of University Directory Service (UDS) Information to the UDS Steering Committee.
By doing so, developers agree to the UDS USER AGREEMENT TO ACCEPT RESPONSIBILITY set forth in this form.
Please note that application development and testing can and should proceed without waiting for the return of the approval form. However, the approved form must be returned prior to production.
See also Draft Policy for a University Directory Service that serves the University
Frequently Asked Questions about approval requirements for UDS access.
Using the exposed interfaces to University Directory Services
The University Directory Service is composed of two components the Oracle-based Registry and the LDAP-based directory. If you are new to the UDS, you'll want to review the Middleware web site which has background n and technical information about the these components. In addition, we have create a FAQ about the more common developer questions about the UDS.At this time, we have two primary interface to the UDS.
1. EXPORT database:
The UDS export database is an Oracle relational database named DREXPORT and resides on UWP1. This database was created to provide easy access to up to date information such as a person's demographic, role, and contact data. People kept in DREXPORT are in some way currently involved with the UW campus. A person could be a professor, a DoIT employee, a student, a person special to the UW, or a combination of various campus roles. A DoIT employee who is getting their masters in computer science would show up in DREXPORT tables with information showing ISIS data and information showing IADS data. This information is tied together with a common internal key, the PVI or Publicly Visible Identifier.
2. Modular Authentication, Authorization, and Directory Access
MAADA is a set of Oracle tables, views and procedures intended to provide authentication and authorization services to Oracle-driven applications within the DoIT application development community.
MAADA can be used to authenticate a user via NetID and password, discover a user's Publicly Visible Identifier (PVI – the key used by the University Directory Service or UDS), and find other information about the user by using their PVI as a key into other data sources. This can all be done by applications using conventional Oracle programming facilities.
More on the Export Table and MAADA (Modular Authentication, Authorization and Directory Access)
Export TableMAADA Technical Specifications