About Authorization

The authorization process applies access controls to authenticated users. After a user successfully authenticates, the DataFlux Data Management Server queries the SAS Metadata Server or DataFlux Authentication Server for the group membership information of the authenticated user. The DataFlux Data Management Server applies the group membership information to its locally defined authorizations to allow or deny the user access to the requested object or command.

Authorizations in the form of access control lists are defined on the DataFlux Data Management Server using the Administration riser in DataFlux Data Management Studio. You can define additional enterprise-level authorizations by setting configuration options. You can allow or deny access to the Data Management Server by IP address. You can also enable ALLOW and DENY groups. If the requesting user is a member, direct or indirect, of the ALLOW or DENY group, then full access is granted or denied, and no further authentication takes place.

The Data Management Server checks a user’s authorizations in the following sequence:

If the requesting user is a member of the administrators group, the DENY group, or the ALLOW group, then access is granted or denied and no further authorization takes place. Members of the administrators group and the ALLOW group are granted access to all DataFlux Data Management Server commands and objects.

After group memberships are compared against the access controls lists, the Data Management Server determines whether the following command permissions are set for the user:

Group permissions are handled in accordance with the group's membership hierarchy. For example, a user can be a member of groups G1 and G2. Group G1 is a member of group G3. So, G1 and G2 are one step away from the user, and G3 is two steps away from the user. The authorization process looks at permissions on all group sets in an increasing order of steps from the user. If a command permission can be determined from the groups that are one step from the user, then the DataFlux Data Management Server will not look further. When the server looks at a set of groups that are the same distance from the user, if any group has the DENY permission, then the user is denied access. Otherwise, if any group has the ALLOW permission, then if there is an ACL to check, the authorization process moves to the ACL. If there is no ACL at this point, then the user receives access. If permissions are not set for any group, or the permission is set to INHERIT, then the authorization checks move to the set of groups one step farther from the user.

If access rights cannot be determined after going through the groups to which the user is a member, then the next group whose permissions are checked is the USERS group. All users that have definitions on the SAS Metadata Server or the DataFlux Authentication Server belong to the USERS group. Administrators can set command permissions for the USERS group and use that group in ACLs in the same manner as any other group.

If access rights have not been determined, based on command permissions, the last step in the authorization process is to check whether permissions are set for the PUBLIC group. The PUBLIC group includes all users who are not registered on the SAS Metadata Server or the DataFlux Authentication Server. If the permission is ALLOW and is there is an ACL to check, then the authorization check moves to the ACL. Otherwise, the user is granted access. If the permission is DENY, INHERIT, or is not set, then the user is denied access.

If neither the user, nor the user’s groups, the USERS group, or the PUBLIC group have permission set, then the DataFlux Data Management Server denies access without checking the ACL. This means that the DataFlux Data Management Server requires a specific command permission before the Data Management Server will look at the ACL of an individual object.

Authorization checks of ACLs begin by determining if the user is the owner of the object. If the user is the owner, then the user is granted access to the object. If the object is owned by a group, the user must be a direct or indirect member of that group to be granted access to the object.

Next, the authorization check search the access control entries (ACEs). If ALLOW or DENY permissions are not found for the requesting user, then the ACEs are checked for groups of which the user is a member.

If the ACL does not grant the user access to the corresponding job or service, the user is denied access.