Download
1 / 15
150 likes | 275 Vues
This case study explores the Distributed Authority Management system at the University of Washington, focusing on the ASTRA application, which has been in operation since January 2003. Supporting over 20 applications and 10,000 authorizations, ASTRA illustrates a complex authorization framework with 500 Authorizers and 100 Delegators. The challenges faced, including establishing new policies and maintaining data integrity, are discussed alongside the progress made through a multi-year development effort. This analysis highlights lessons learned, effective support strategies, and the importance of persistence in achieving organizational goals.
E N D
Case Studies in Distributed Authority Management Ian Taylor University of Washington
Where are we? How did we get here? • ASTRA currently supports > 20 applications
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by • 100 Delegators, who were identified by
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by • 100 Delegators, who were identified by • a few high-level Administrators, reporting to
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by • 100 Delegators, who were identified by • a few high-level Administrators, reporting to • the Provost and the EVP
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by • 100 Delegators, who were identified by • a few high-level Administrators, reporting to • the Provost and the EVP • as a result of a multi-year design/dev effort
Where are we? How did we get here? • ASTRA currently supports > 20 applications • and 10,000 authorizations, created by • 500 Authorizers, themselves authorized by • 100 Delegators, who were identified by • a few high-level Administrators, reporting to • the Provost and the EVP • as a result of a multi-year design/dev effort • which produced ASTRA v1.0 in January, 2003
Problems and Issues • A new way of doing business, no precedence and therefore no existing community of users. • Central authorization? Distributed? Who decides? • Maintaining the out-of-system records of delegated authority. • Unmet need for an official, systematically-usable ‘hierarchy-of-control’ map.
Policies and Practices • Application developers do not get access to production applications unless authorized. • No-one may authorize themselves. • All new applications must use ASTRA or justify why not. In-house developments are compliant. Experience with vendor products is not so good. • No automatic revocation of access rights. Instead, notices of status sent to Authorizers.
What’s worked for us • Just Do It – without waiting for every detail to be worked out (e.g. who “owns” authorizations?).
What’s worked for us • Just Do It – without waiting for every detail to be worked out (e.g. who “owns” authorizations?). • After all, what’s the worst thing that can happen?
What’s worked for us • Just Do It – without waiting for every detail to be worked out (e.g. who “owns” authorizations?). • After all, what’s the worst thing that can happen? • University loses $millions! • Huge data losses! • It hits the papers! • You lose your job!
What’s worked for us • Effective, informed, compassionate client support – builds confidence and reputation. One very good person can do this. • Persistence in the pursuit of success. • Good buy-in from IT leadership. • Good staff.
