![[Graphic: Behind the Screens]](/computing/windows/graphics/Behind_the_screensB.gif)
The first challenge of any computing security system is to verify that you are who you say you are, and to give you access to the services and information you need in your role as faculty, staff, or student. The next is to ensure that communication between your programs and other clients and servers on the network is protected.
Authentication may be based on any of the following:
Currently at the UW, you authenticate yourself every time you type your login name and password to access UW computing services. Your login name for your accounts on UW central computers is the same as your UW NetID.
For UW applications requiring more verification, a SecurID is used as an additional identifying credential in the authentication process.
The challenge. As the UW reaches out electronically to vendors, alumni, supporters, and citizens of the state, we will need to be able to authenticate hundreds of thousands of people above and beyond our own faculty, staff, and students for some level of access to university information.
As more UW business is handled electronically and as your personal information passes over the network, it becomes increasingly more urgent to make certain that no one can impersonate you. Hence the methods for initially acquiring and then protecting your UW NetID must be enhanced. How we do that without making everyone come to a central office with picture identification in hand is a challenge.
One or more authorization attributes may be associated with an individual. These define which services or applications can be accessed, and the type of access: read only, or read and update, or no access at all. For example, one authorization level might allow you to review your payroll information, but would not let you make modifications to the data.
The challenge. Authorization methods supporting diverse networked client-server systems--such as we have here at the UW--can become quite complex. The challenge is to give quick, reliable access to information and systems for those who should have it, while preventing such access for others.
Although the concept is simple enough, setting up a workable, university-wide authorization system is difficult. Our size, complexity, and decentralized organizational structure all add to the challenge.
The UW needs a solution that offers many types and levels of authorization:
The most complex authorizations are those that define who can authorize others. At the UW, there is a network of relationships that includes the legal hierarchical delegation of authority as defined in the UW Handbook, the channels of authority unique to each department, and the authority of each individual to grant accesses to resources under his or her control.
It is feasible, from a technological standpoint, to start to put together the protocols and tools that enable authorization and access controls for applications. Defining the university's organizational relationships in a way that they can be understood by the software systems is now the fundamental hurdle.
How do we develop an authorization infrastructure for the UW when positions and roles are not uniform across campus? A particular department chair, for example, could delegate authority to his or her administrator, who could then delegate certain functions to support staff. When staff or their duties change, the administrator could be responsible for changing the authorization profile of the support staff. Another department chair, however, might delegate his or her authority differently.
A centrally administered system could not possibly track how individual work roles change from day to day, or which departments will choose to use the centrally managed systems for their own use such as in a departmental lab, let alone transfer authorization roles from one individual to another, as in the previous example. Therefore, once defined, the authorization relationships will need to be maintained under a distributed administration environment.
We are watching as other institutions also struggle with the issue of authorization. No uniform or readily portable approach has yet come to light.
W3C (WWW Consortium) Security Resources Web site: www.w3.org/Security/
The W3C World Wide Web Security FAQ: www.w3.org/Security/Faq/