ASTRA

ASTRA for Developers: Guidelines for Consuming Application Developers

Use different authorizations for different environments

Typically, authorizations to a development instance of an application are different from authorizations to a production instance of an application.

When a consuming application makes a call to ASTRA to request authorization data, it must specify an environment.

ASTRA currently supports three environments for each application: eval, train, prod. The following matrix gives additional information on these environments.

Environment code	Environment description	URL to administer authorizations
Eval	Development and Testing	https://iswwweval3.cac.washington.edu/astra
Train	Training	https://iswwwtrain1.cac.washington.edu/astra
Prod	Production	https://ucs.admin.washington.edu/astra

For this reason, it makes sense to create some kind of casing logic in your application that says something like:

if DEV environment
    use ASTRA EVAL auths
else if EVAL environment
    use ASTRA EVAL auths
else if TRAIN environment
    use ASTRA TRAIN auths
else 
    use ASTRA PROD auths

As a safety check, it would be advisable to run your application under different identities in pre-production and production environments. This will also help to prevent your production identity from accessing pre-production authorizations inadvertently.

Prior to deploying to production, we also recommend that you test the application against the production ASTRA service in some kind of staging/release candidate environment using the same identity that will be used in production.

Cache authorization data for the duration of the user session

Whether this is appropriate will depend upon the application, but in authorizations are not likely to change during a user session. If user sessions are particularly long or if having up-to-the minute authorization data is critical to the application, then shorter cache durations should be implemented.

By minimizing trips to the server for authorization data, consuming applications will see better performance and ASTRA will benefit from reduced load.

Bulk load authorizations when converting from another system

Typically authorization data is entered through the ASTRA Web application by UW employees that have been given permission in ASTRA to authorize users to have access to their application. It is also possible to enter existing authorization data through a bulk load process in the case of existing applications that are switching to ASTRA to cover their authorization needs.

Use UW Regid to identify persons

The UW Person Registry provides different keys to identify a person. The only guaranteed unique key is UW Regid, a 32 character alpha-numeric key.

A Consuming Application can look up authorizations for a person in ASTRA using either UWNetid or UW Regid, but we recommend using UW Regid. Because UWNetid is mutable, if a CA uses it as a key, it will be necessary to manage the cases in which a person's UWNetid changes.

The UW WebLogin service currently returns only UWNetid, which means that an additional lookup to the UW Person Registry is necessary in order to obtain the UW Regid.

ASTRA currently reconciles UWNetid's with the Person Registry in the following cases:

• When someone modifies a person's authorizations via the ASTRA web application
• When a CA makes a real-time call to IAP_AuthCom for the old UWNetid
• When a nightly reconciliation job runs

This means that there are currently gaps during which ASTRA UWNetid's are not current with the Person Registry. In the future, we plan to move to an event based model that will allow us to be more current.

For more information on the best practices for the use of Regid, see Person Registry Regid Documentation.