The University of Texas at Austin

Apollo

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A

Apollo Steward
Apollo stewards provide customer support for the Apollo system and perform routine maintenance activities.
Application

Apollo applications are organizational and storage tools used to control access to systems such as Mainframe (3270) systems or UT Direct services. Apollo applications generally have similar names as the application they correspond to. Application names start with a two-letter *DPUSER prefix, such as BD for Budget or NR for Student Records.

Applications can have up to 10 attributes, each of which represents a logical component of the corresponding system.

See also: Attribute, Authorization
Application Owner
Application owners can add and remove any authorizations to and from people or groups for the application they own. Owners can also change application metadata. For example, an application owner can add new attributes or delete exsiting ones, or modify the metadata about those attributes. Applications can have up to five owners. See also: Application, Authorization
Assignable Attribute
Another name for an attribute. Assignable attributes are owned by the application owners; only the application owner or a delegate can grant an assignable attribute. Compare with an ownable attribute. See also: Application Owner, Attribute, Ownable Attribute
Attribute
Attributes are groupings of similarly structured authorizations within an application. For example, an attribute might represent departments. There are two types of attributes: ownable and assignable. Each application can have a maximum of 10 attributes. See also: Application, Assignable Attribute, Authorization, Ownable Attribute
Attribute Owner
An individual who is authorized to grant and remove authorizations that have the Field 1 value they own, regardless of the Field 2 value. Only ownable attributes may have an attribute owner. See also: Authorization, Field 1, Field 2, Ownable Attribute
Audit

Audits determine what values are permissible for an application or group. For example, an audit for a particular group might require all group members to be faculty, while an attribute value audit might limit acceptable values to buildings on the UT Austin campus.

Audits are written by application developers. The audit must be a Natural subprogram or Secured Module stored in the System Library. Application owners can apply an audit to their groups or applications.

See also: Application, Application Owner
Authorization

Authorizations allow individuals to access specific features or functions of a system. Similarly structured authorizations are grouped together under a single attribute.

Each authorization is comprised of up to two values: Field1 and Field2. The values for the fields are static strings pre-defined by the application owner, or they can be freeform (insert text here format). The freeform values may or may not have audits to ensure proper values.

Authorizations must be approved by the authorization administrator.

See also: Application, Attribute, Authorization Administrator, Field 1, Field 2
Authorization Administrator
An authorization administrator is allowed to add or remove an authorization. Administrators can include application owners, attribute owners, super-users, and delegates. See also: Application Owner, Delegate, Super-user

Back to top

D

Delegate
Delegates are appointed by an authorization administrator and are allowed to grant specific authorizations (delegates must also have these authorizations themselves). Delegates can only grant authorizations for assignable attributes. See also: Assignable Attribute, Authorization, Authorization Administrator

Back to top

F

Field 1

An authorization must be composed of a value for Field 1. This field can be a single value or a list of values. The values for the field can be static strings pre-defined by the application owner, or they can be freeform (insert text here format). The freeform values may or may not have audits to ensure proper values.

The Field 1 name is identical to the name of the attribute.

See also: Attribute, Authorization
Field 2

Some authorizations may also include a value for Field 2. If a value for Field 2 exists, the authorization is represented by the Field1, Field2 pair. This field can be a single value or a list of values. The values for the fields are static strings pre-defined by the application owner, or they can be freeform (insert text here format). The freeform values may or may not have audits to ensure proper values.

The Field2 name is determined by the application owner and should provide a description of the values contained within the field.

See also: Attribute, Authorization, Field 1

Back to top

G

Group

A group is a collection of people who can be granted authorizations all together. However, not every person in the group necessarily has the same authorizations, since it is possible that certain group members may not fulfill the audits required for all authorizations for that group. It is also possible that an authorization administrator may not approve an individual for an authorization, even thought the individual is a member of the group which has been granted that authorization.

Individuals can be members of more than one group.

See also: Audit, Authorization, Authorization Administrator
Group Member
Group members are individuals who are included in a group. Group members are eligible to inherit any authorizations that have been granted to the group, as long as they fulfill any audits required for the authorization and as long as the authorization administrator approves them. See also: Audit, Authorization, Authorization Administrator
Group Owner
Group owners can add and remove individuals to or from a group. Owners may also change information about the group. See also: Group

Back to top

I

Inherit

Any authorizations that are applied to a group are automatically applied to any member of that group. Therefore, any individual who is added to an existing group automatically inherits any authorizations for that group, assuming the individual fulfills all the audits for the authorizations.

It is possible that an individual may not be approved for an authorization (by the authorization administrators) for a group for which they are a member.

See also: Authorization, Authorization Administrator, Group, Group Member

Back to top

O

Ownable Attribute
An ownable attribute is just like a regular attribute, except that the Field 1 values are assigned to specific owners who are distinct from the application owner. Therefore, only the attribute owner (and NOT the application owner) can grant access to that attribute value (to that Field 1 value and associated Field 2 values). These are generally used for programmatic interfaces. See also: Application Owner, Attribute, Attribute Owner, Field 1, Field 2

Back to top

P

Person Audit
Person audits apply to individuals. There are two predefined person audits: one checks to see whether or not the individual has a "high assurance" UT EID, and the other checks to see if the individual is an employee. Person audits can also be defined programmatically if necessary. See also: Audit

Back to top

R

Rule
Refer to Audit. See also: Audit

Back to top

S

Super-user
An Apollo super-user is someone who can take any action on any group or application in the Apollo system. These actions include adding and removing authorizations, group memberships, group owners, and application owners. See also: Application, Application Owner, Authorization, Group, Group Owner

Back to top

V

Value Audit
Checks to see if the value for Field 1 or Field 2 is an acceptable value. These audits are defined programmatically. See also: Audit, Field 1, Field 2, Person Audit

We Can Help

Get help from an expert:

* ITS Help and Service Desk

* Call us at 512-475-9400

* Submit a help request online

We also have a walk-in service in the first floor lobby of the Flawn Academic Center (FAC). Stop by and let us help you!