Scenario 1: Enhancing Security in a Java EE Application Scenario 2: Securing an Oracle ADF Application

2 Understanding Users and Roles 2-1 2 Understanding Users and Roles This chapter describes various characteristics of users and roles, such as the anonymous role, the authenticated role, role mapping, and the role category. It also includes the definition of terms used throughout this guide and an overview of the User and Role API Framework. OPSS delegates authentication to Oracle WebLogic Server authenticator providers managed with the WebLogic Administration Console. This chapter is divided into the following sections: ■ Terminology ■ Role Mapping ■ The Authenticated Role ■ The Anonymous User and Role ■ Administrative Users and Roles ■ Managing User Accounts ■ Principal Name Comparison Logic ■ The Role Category For further details about managing users and roles programmatically, see Chapter 25, Developing with the User and Role API.

2.1 Terminology

This section definies most of the OPSS security terms. Users A user, or enterprise user, is an end-user accessing a service. User information is stored in the identity store. An authenticated user is a user whose credentials have been validated. An anonymous user is a user whose credentials have not been validated hence unauthenticated that is permitted access to only unprotected resources. This user is specific to OPSS and its use can be enabled or disabled by an application. For details about anonymous user support, see Section 2.4, The Anonymous User and Role. Roles An enterprise role or enterprise group is a collection of users and other groups. It can be hierarchical, that is, a group can include arbitrarily nested groups other than itself. 2-2 Oracle Fusion Middleware Application Security Guide A Java EE logical role is a role specified declaratively or programmatically by a Java EE application. It is defined in an application deployment descriptor and, typically, used in the application code. It can be mapped to only enterprise groups or users, and it cannot be mapped directly to application roles. An application role is a collection of users, groups, and other application roles; it can be hierarchical. Application roles are defined by application policies and not necessarily known to a Java EE container. Application roles can be many-to-many mapped to external roles. For example, the external group employee stored in the identity store can be mapped to the application role helpdesk service request in one stripe and to the application role self service HR in another stripe. For details about the anonymous role, see Section 2.4, The Anonymous User and Role. For details about the authenticated role, see Section 2.3, The Authenticated Role. Principal A principal is the identity to which the authorization in the policy is granted. A principal can be a user, an external role, or an application role. Most frequently, it is an application role. Application Policy An application policy is a functional policy that specifies a set of permissions that an entity the grantee, a principal or code source is allowed within an application, such as viewing web pages or modifying reports. That is, it specifies who can do what in an application. An application policy uses: ■ Principals as grantees, and must have at least one principal. ■ Either one or more permissions, or an entitlement, but not both. Policies that use an entitlement are called entitlement-based policies; policies that use one or more permissions are called resource-based policies. Figure 2–1 illustrates the application policy model.