Skip to end of metadata
Go to start of metadata

DRAFT DRAFT DRAFT

February 27, 2019 – This page is draft for review by ASTRA 2.1 implementation partners.

Purpose

This page describes how business application owners can take advantage of ASTRA 2.1 access control features and auto-deprovisioning.

Audience

This page is intended to be used by business application owners and their teams.

Authorizers and delegators should refer to other documentation on how to manage authorizations for applications that use ASTRA 2.1 access control features and auto-deprovisioning.

Process

The following process should be followed to add ASTRA 2.1 access control features auto-deprovisioning to your business application.

1. Define your access policy in natural language.

The ASTRA team will ask you to describe your access policy in everyday business terminology. A natural language policy is useful to the ASTRA team to help understand who is authorized to use your application.

Here are some examples of natural language policies:

"All current employees are eligible to access our application if authorized by our central office."

"All current employees are eligible to access our application if authorized by their unit Authorizer.   Exceptions are granted on a case by case basis for non-employees."

"All current staff, students, postdocs, and members of the IRB office are eligible to be authorized to use our service unless their account has been administratively locked by the Office of the Chief Information Security Officer.”

"All students, all teaching faculty, and all computer lab administrators can access computers in our lab."

Tip

Most applications that rely on ASTRA for access management are administrative applications available only to current employees, with occasional exceptions for non-employees based on business justification.

2. Translate your access policy into technical controls in ASTRA.

The ASTRA team will help translate your natural language policy into a technical access control policy that ASTRA can apply to authorizations for your business application.

Converting a natural language policy into a technical access control policy based on known business definitions for common affiliations and memberships is a fundamental pattern and objective of access management across services.

These common business definitions enable the translation from natural language policies to technical policies, and enables the automated enforcement of the policy as the status of users change (e.g. from "current employee" to not a "current employee").

UW-IT provides central services like ASTRA to enable management of access based on common business definitions like "current employee" that can be defined once and reused across multiple applications and services.

In turn, as more business and technical policies are implemented, access policies become easier to discover, reuse, and verify.

Tip

When translating your natural language policy into a technical policy, make sure you've considered any exceptions you have. The ASTRA team can help create a mechanism for you to maintain a well-managed list of exceptions.

3. Schedule deployment of technical controls in ASTRA EVAL environment.

Once the ASTRA team understands your policies, we can configure the technical policy on the ASTRA EVAL environment.

We will schedule when to deploy the technical access control and auto-deprovisioning for your application on ASTRA EVAL.

We will also ask if your team would like to receive email notifications of the removals and how often this process should run on ASTRA EVAL.   If you do, we'll collect an email address for your team.  The default timing is daily, but the process may be set to run more frequently during testing period.  The routine setting that will be applied for ASTRA Production will be to run once/daily. 

If you maintain any exceptions, we will show you how to use the UW Groups Service to manage a list of those exceptions that will be utilized by ASTRA for your application.  The groups used will be structured as follows:  

  • groups used by ASTRA EVAL for exceptions, (eg; u_astratst_<priv>_eligible-user):  u_astratst_etravel_eligible-user
  • groups used by ASTRA PROD for exceptions, (eg; u_astra_<priv>_eligible-user):  u_astra_etravel_eligible-user

Tip

Does your team have test accounts that may need to be in your ASTRA EVAL (u_astratst_<priv>_eligible-user) group?

4. Test and review.

We will schedule when to deploy the technical access control and auto-deprovisioning for your application on ASTRA EVAL.

On ASTRA EVAL, you can test your policy, ie; see how adding and removing members to your group impacts authorizations or ability to authorize.


5. Schedule deployment of technical controls in ASTRA TRAIN environment.

If needed (if you use TRAIN), we can configure the technical policy on the ASTRA TRAIN environment.

We will schedule when to deploy the technical access control and auto-deprovisioning for your application on ASTRA TRAIN.


6. Plan for production deployment.

The ASTRA team will help you plan your deployment to production, including communication to your ASTRA Authorizers and Delegators, as well as documentation you'll need to sustain efficient operations for access requests, reviews, and removals.

  • Target date
  • Access exception request process:
    • documentation (url/link to application page, help contact, access policy info, in-line 'help' content within ASTRA User Interface)
    • how to request (customers)
    • how to process or fulfill (application customer support team)
  • Renewal or review process
  • Collaborate on communication; will Application team send or ASTRA team send?
  • Does your application customer support team want the daily email summary from ASTRA about authorizations removed? 

7. Deploy to ASTRA PROD environment.

When ready, we'll schedule when to deploy your access controls into production.


  • No labels