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
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
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
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
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
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
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
R
- Rule
- Refer to Audit. See also: Audit
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
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
