OneLook supports two authentication modes: Active Directory (AD) integration and local authentication via the user’s table. While approximately 99% of deployments use AD, both modes are fully supported and behave identically with respect to rights inheritance.

Authentication Modes

Active Directory Authentication
In AD-enabled deployments, Active Directory is used strictly for login validation.

When a user logs in:

1. The user’s credentials are validated against Active Directory.
2. Upon successful validation, their AD group memberships are retrieved and compared against groups configured in OneLook. Any matching groups are treated as group memberships for that user within OneLook.
3. The user’s login name is checked against the OneLook Users table to retrieve any rights configured at the user level.
   A user is not required to have an entry in the Users table to log in via AD. However, they must belong to at least one AD group that matches a configured OneLook group in order to inherit any rights.
   

Local Authentication (Non-AD)
In deployments not configured for AD, users are validated directly against the user’s table. Once authenticated, the system determines group membership by looking up the groups to which that user belongs within OneLook.

*Workbasket Consideration
Regardless of authentication mode, any customer using the Workbasket feature must also have user records created in the user’s table for every user configured to use Workbasket. These records are required for assigning users to Workbasket queues. This applies even to AD-authenticated deployments, where user’s table entries would otherwise be optional.

*Group Membership
Every user automatically belongs to the *EVERYONE group, regardless of authentication mode or any other group assignments. This group serves as the baseline for rights that should apply to all users.

Rights Inheritance

A user’s effective rights are the union of all rights assigned at the user level and all rights assigned to every group the user belongs to. Rights are cumulative and additive — group-level and user-level rights combine, and no assignment removes or overrides another.

Example
Consider the following configuration:

• *RVIAdmin — grants access to all systems
• *RVIScan — grants access to Systems A and B
• *EVERYONE — grants no access rights
• User Barry — granted access to System C at the user level
  

Scenario 1: Barry logs in and is a member of *RVIAdmin.
Barry’s effective rights are the union of *RVIAdmin (all systems), *EVERYONE (none), and his user-level rights (System C). Because *RVIAdmin already grants access to all systems, Barry has access to all systems.

Scenario 2: Barry logs in and is not a member of *RVIAdmin, but is a member of *EVERYONE only.
Barry’s effective rights are the union of *EVERYONE (none) and his user-level rights (System C). Barry has access to System C only.

Scenario 3: Barry logs in and is a member of *RVIScan.
Barry’s effective rights are the union of *RVIScan (Systems A and B), *EVERYONE (none), and his user-level rights (System C). Barry has access to Systems A, B, and C.

Copyright 1992, 1999, Real Vision Software, Inc. (RVI), Alexandria, Louisiana. No part of this document may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language in any form or by any means without the express written consent of RVI Software, P.O. Box 12958, Alexandria, LA 71315-2958. However, copies of the One Look Manual can be reproduced, in whole or part, for use with the Real Vision Imaging System by Real Vision Software Licensee’s, for use with the imaging system.