Skip to end of metadata
Go to start of metadata

Web Service Authorization Management

ASTRA can not only manage authorizations for people who use web applications, it can also manage authorizations for "processes".  By "process" we mean a web service that delivers data from some source to the applications that need to comsume that data. 

UW-IT has adopted the use of client certificates to authenticate web applications in calls to a web service.  The client certificate serves two purposes:

  1. It is used to authenticate an application.
  2. It is authorized in ASTRA by a data custodian who has approved the use of the data supplied by a web service to the application that this certificate authenticates.

These certificates are the gate keepers that manage applications that use the UW-IT web services in order to retrieve data from UW data sources.

A Quick Review of ASTRA Terminology

ASTRA has adopted the term "Party" to mean either a person or a process.  The Party Chooser in the ASTRA web application is the place where either people or processes (i.e. certificates) are chosen.

An ASTRA role is part of every authorization that is assigned in ASTRA.  The most common roles that web application developers and ASTRA users know about are:

  • User: Any party that is authorized through ASTRA to use an application is given a "User" authorization.  These parties do not use ASTRA itself and most likely will never even see the ASTRA web application.  Furthermore they may not even know of ASTRA's existance.
  • Authorizer: These are the people who create "User" authorizations in ASTRA.
  • Delegator: These are the people who create ASTRA Authorizers.  A delegator cannot create "User" authorizations unless they are also set up as an "Authorizer".
  • APIReader: A consuming application's client certificate is given an "APIReader" authoriization so that it can query ASTRA for authorizations via the AstraWS web service. ASTRA team members set up these authorizations.

Two additional ASTRA roles exist in order to manage process authorizations in ASTRA.  They are:

  • Process Authorizer: These are the people who assign user authorizations to certificates instead of people.
  • Process Delegator: These are the people who create the Process Authorizers. 

How do you give a certificate an authorization in ASTRA?

In a process authorization the web service (as opposed to a traditional web application) is the consuming application and the certificate (rather than a person) is the "User".  Process authorizations make up a minute portion of the authorizations stored in ASTRA and there are only a handful of authorizers that will ever set up a process authorization.  For this reason the "Process" radio button in the Party Chooser is hidden from any authorizer who is not a Process Authorizer.  To enter a certificate in the Party Chooser, pick the "Process" radio button and then enter the entire certificate common name, taking care to avoid any mis-spellings.  Proceed to choose the appropriate web service in the application drop down list, and select a role and action as well.  Select the "User" ASTRA role checkbox if that is an option.  Add the authorization to the cart, and commit the authorization on the checkout page. 

Web Services Whose Access is Managed in ASTRA

  1. AstraWS web service:  One of the security features in ASTRA is that an application can only query on it's own authorizations and will not be able to access authorizations for any other applications.  An application must have a client certificate associated with it for the reasons outlined in the section above.  The ASTRA role of "APIReader" is assigned to an application's client certificate.  This way when an application makes a call to the AstraWS and authenticates with their client certificate ASTRA looks to see if that certificate is permitted to retrieve authorizations for that application.  If it is the authorizations being requested are returned from thr AstraWS web service.
  2. UW-IT Web Services:  There are a number of web services that have been built in order to retrieve student, financial and human resources related data.  Due to the sensitive nature of this information the University of Washington must be able to control who gets access to that data.  There are "data stewards" that review the applications that are requesting access to this data.  When a data steward deems that an application has a legitimate need for the requested data they will authorize the application's client certificate in ASTRA in order for it to be able to use a specific web service.  The certificate is given an ASTRA role of "User" for the web service, which in this case is an application.  Just as a person can be authorized to use an administrative application, a certificate (which is a proxy for it's underlying client application) can be authorized to use a web service.
    The web services that can have their access controlled in ASTRA are:
    • Student Web Service (SWS)
    • ID Card Web Service (IDCardWS)
    • Financial Web Service (FWS)
    • Windows Engineering Web Service (WinEngWS)
    • Human Resources and Payroll Web Service (HRPWS)
    • Person Web Service (PWS)
  3. NOTE:  Just as a traditional web application must have an APIReader authorization for it's client certificate in order to retrieve authorizations through the AstraWS web service, each of these web services must do the same.  Each web service will have its own client certificate, and that certificate must be set up in the ASTRA role of "APIReader" for that web service.


ASTRA is a good place to manage authorizatons for web applications and web services.  It is a transparent access management tool where authorizations can not only be added, but also can be updated or deleted when necessary.  It's flexible design allows both people and processes (i.e. certificates) to be assigned authorizations.  In the future it is possible that authorization management for Groups could occur in ASTRA as well if the business case arises.