ASTRA

Information for Developers: What You Can Expect

The following information is to help application developers work with ASTRA. In particular, it is to prepare you for the collaborative effort needed when ASTRA is used for system authorization management. This can be a quick and simple process, or it can take longer and involve more complexity -- it all depends upon the authorization needs of your application. Either way, the process will go more smoothly if the following points are considered.

Roles

We have found it useful to define the following roles, as they fulfill different functions during the process of integrating your application and ASTRA. From the developer side the roles are:

• Application development team
• Application business owner
• Application client support

In some cases these roles are all filled by different people, in other cases two or more may be combined in one person. From the ASTRA side the roles are:

• ASTRA development team
• ASTRA client support

Other possible players include those who support:

• Pubcookie
• UW Certificate Authority
• SecurID

Steps

The following steps outline the typical course of collaborative work. Not all steps will be necessary in each case. Again, the intent here is to describe what you can expect so that there are few, if any, surprises along the way.

1. Initial contact

Initial contact is made between an application team and the ASTRA team. A team with previous experience with ASTRA will return with another application, or developers with no prior experience will hear about it and wonder if it will work for their application. In that case the first contact will explore some basic questions: is ASTRA a good fit? Does it make sense in this case? This initial contact almost always leads to a meeting, which is the next step.

2. Early conversations: First Meeting

This is an information sharing meeting. You will be expected to describe the business functions supported by your application, and to give some idea of its expected use across the UW. The ASTRA team will identify some technical prerequisites to be sure your application can integrate with the ASTRA API. We will describe the ASTRA authorization structure, and perhaps map out a tentative schema for your application -- to illustrate that structure. As the discussion develops we will jointly be considering the costs and benefits of using ASTRA, and in the end we will decide whether to continue the conversations or not.

3. Continuing Conversations

With the benefit of shared information we will begin to dig into the details, discuss timelines, refine the authorization schema, and address many related issues, including:

• New Span of Control types (if needed) and an appropriate institutional source for that data
• Conversion of existing authorizations (if needed)
• Plan if, when, and how developers should have authority to access the production application
• Plan for UW Auditor access, especially in the case of a financial application
• Discuss existing environments and how to use them: Eval, Train, Prod
• Identify someone to determine application-specific ASTRA help text
• Discuss Delegation/Authorization -- what it means, and who is involved (identify real, production Delegators).

These conversations will conclude with a decision: to proceed to development; to defer the work to a later time, or not to proceed at all.

4. Development

At this stage it is normal for the ASTRA team to load the authorization schema for your application into the EVAL version of ASTRA. At the same time arrangements are made for application developers to receive all appropriate permissions, authorizations, certificates etc. You may then begin to test the ASTRA API from your development environment. If New Span of Control types are needed, the tables will be created in ASTRA at this point and an import/update process created to keep them current.

Development then follows the usual cycle of build, unit test, adjust - and so on - until system testing is appropriate.

5. Testing

System testing takes place in the EVAL environment. Developers may be authorized for all roles, and may act as Delegators and Authorizers in the EVAL environment. It is common practice for application developers to be supported in the testing process by participants from the associated business office, or business owner, or client group.

6. Prepare for Deployment

This is a very critical phase of the process and outcomes -- successful or otherwise -- depend upon good communication between all parties.

Prior to deployment, the production Delegators need to be identified and set up in ASTRA. This facilitates the early creation of Authorizers (who will use ASTRA to create end-users of your application). The sequence of events at this point can be adjusted to meet whatever your deployment needs may be. It is important that ASTRA client support, application client support, any related business office, and your development team leadership be tightly integrated and closely cooperating at this stage.

If conversion of existing authorizations is needed, it will happen at this point.

If training is necessary -- either for the new application, or for ASTRA, or both -- that should be designed and scheduled prior to deployment.

Note: developers will normally only have production authorizations to their application if so authorized by production Authorizers. This practice keeps a clear distinction between the production world and the development world, and reduces the risks of inappropriate access to production systems and data.

7. Post Deployment

With good planning and careful design an authorization schema will support all the authorization needs of the application for which it was designed. It is certainly preferable to have considered all the possibilities in advance, because post deployment changes to the authorization schema -- which will directly affect live authorizations for your production system -- can be painful to implement.

It is possible, however, that some changes may be needed, perhaps due to new business requirements that emerge later. The ASTRA team can support post deployment schema changes and data manipulation. Bear in mind that these are delicate operations as they will affect the access your users currently have. Once again, good design and thorough testing will be needed. We have carried out several of these post deployment schema revisions with uniformly good results.