ASTRA

ASTRA for Developers: Overview

How do I start using ASTRA?

The first step in using ASTRA is to meet with an ASTRA team member to discuss the authorization needs of your application. If you are interested, please send an email to astra-dev@cac.washington.edu.

After the initial meeting, typical steps include:

• Define authorization schema
• Define spans-of-control import processes
• Configure service for new consuming application
• Configure Consuming Application contact information

Benefits, Limitations, Alternatives

What are the benefits of using ASTRA?

• Supported 24x7 service
• Multi-platform support
• Simple user interface for managing authorizations
• Distribution of authorization decisions to the people who should be making them -- helps to relieve the application team from this responsibility.
• Client support client regarding authorization questions and problems
• Audit trail of all authorization activity
• Flexible authorization data scheme
• Post-Entry Review Messages (PERM's) sent to both the person who authorizes and the person who is authorized.
• Visibility of who is authorized to do what on campus

What are the limitations of ASTRA?

Limited support for existing campus groups. ASTRA can be used to support well-defined groups, but there are other means of doing this already e.g. LDAP/EDS, catalyst. ASTRA's current support is primarily for what individuals can do in particular applications.

What are alternatives to using ASTRA for authorization needs?

Authorization data exists in multiple data stores on campus. Sometimes, it makes sense for ASTRA to import that data and serve it to consuming applications. Sometimes, it makes sense for consuming applications to use another existing interface.

For example:

• SDB: Students and classes
• PubCookie: If all that is desired is that a person has a UWNetid
• LDAP Groups: Groups such as Nebula, CAC, etc.
• Catalyst groups Web service: Add-hoc groups