|
|
This guide describes how to secure your portal applications. Use the security techniques described in this guide to assure the confidentiality, integrity, and availability of your portal applications and application resources.
Oracle WebLogic Portal® security leverages Oracle WebLogic Server security features. The WebLogic Server, in turn, supports and enhances J2EE security services. Like other J2EE components, the security services are based on standardized, modular components. WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming. For more information about WebLogic Server security, see Security for Oracle WebLogic Server 10.3.
This chapter includes the following sections:
WebLogic Portal is part of the unified WebLogic security architecture. WebLogic Portal-specific security extensions, including visitor entitlements and delegated administration, use the WebLogic Security Service Provider Interfaces (SSPIs). All authorization checks are performed using the isAccesssAllowed method as part of the shared architecture.
Figure 1-1 shows WebLogic Portal in the unified WebLogic security architecture.
This section describes the components of the WebLogic Portal security architecture.
WebLogic Server utilizes the security services of J2EE. Like the other J2EE components, the security services are based on standardized, modular components. WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming.You can use the security providers that the WebLogic Server supplies as defaults, or you can integrate custom providers.
WebLogic Portal uses the WebLogic Security Framework, which unifies security enforcement and presents security as a service to other WebLogic Server components. The WebLogic Security Framework calls methods in the WebLogic Security Service Provider Interfaces (SSPIs) to perform security operations. The WebLogic SSPIs are set of WebLogic packages that enable security providers to be developed and integrated with the WebLogic Server Security Service.
These interfaces are implemented by the WebLogic security providers and custom security providers. Security providers are software modules that can be plugged into a WebLogic Server security realm to offer security services, such as authentication, authorization, and auditing, to applications. Custom security providers (written by third-party security vendors or security developers) are implementations of the SSPIs and are not supplied with WebLogic Server.
WebLogic Server uses Java Authentication and Authorization Service (JAAS) classes to reliably and securely authenticate clients. JAAS is a standard extension to the security in the Java Software Development Kit version 1.4.1. WebLogic Server clients, including WebLogic Portal, use only the authentication portion of JAAS.
JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. This enables you to use new or updated authentication technologies without making modifications to your application.
The JAAS LoginContext provides support for the ordered execution of all configured authentication providers and is responsible for the management of each configured provider. For more information, see JAAS and WebLogic Server.
Authentication is the verification of identity, answering the question: Is the user who they say they are?
Authentication is typically performed using a login process, during which the user supplies a credential, such as a username and password combination. Once the user is authenticated, a set of identities (such as the username and the user's group membership) is associated with the user. These identities are also referred to as principals.
This section includes these topics:
Authentication providers verify the identity of users. Authentication providers also remember, transport, and make available that identity information to various components of a system through subjects (containers for authentication information) when needed. During the authentication process, a principal validation provider provides additional security protections for the principals contained in the subject by signing and verifying the authenticity of those principals.
WebLogic Server supplies its own authentication providers, which can access user and group data in its embedded LDAP server, external LDAP stores, and external Relational Database Management Systems (RDBMSs). While WebLogic Server uses the embedded LDAP server as its authentication provider by default, WebLogic Portal uses the SQL Authenticator by default.
| Tip: | Previous releases of WebLogic Portal included a WebLogic Portal-specific RDBMS Authenticator. This has been deprecated. If you are upgrading from a previous release, you can choose whether to upgrade to the WebLogic SQL Authenticator as your default authentication provider or continue to use your existing user store. For information about upgrading your user store, see the Upgrade Guide. |
WebLogic Portal uses WebLogic Server for authentication, whether you are using one or more WebLogic authentication providers, one or more custom authentication providers configured for use with WebLogic Server, or a combination of WebLogic and custom providers.
| Tip: | WebLogic Server supplies RDBMS authentication providers including the SQL Authenticator, Read-only SQL Authenticator, and Custom RDBMS Authenticator. WebLogic Server also supplies authentication providers for external LDAP servers including Open LDAP, Sun iPlanet, Microsoft Active Directory, and Novell NDS LDAP servers, as well as its embedded LDAP server. |
Each authentication provider requires a JAAS LoginModule. LoginModules are responsible for authenticating users within the policy domain and for populating a subject with the necessary principals (users and groups). LoginModules that are not used for perimeter authentication also verify the proof material submitted (for example, a password). For more information on creating LoginModules for a custom authentication provider, see Login Modules.
An identity assertion provider is a specific type of authentication provider that allows users or system processes to assert their identity using tokens (representations of security-related information). Identity assertion providers enable perimeter authentication and support single sign-on (SSO). For example, an identity assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.
| Note: | You can use an identity assertion provider in place of an authentication provider if you create a LoginModule for the identity assertion provider, or in addition to an authentication provider if you want to use the authentication provider LoginModule. |
Web applications often consist of many different components, each of which may have its own authentication scheme or user registry. SSO enables users of these applications to authenticate only once to obtain access to all components of the application. Once users are authenticated in one site that participates in a SSO configuration, they are automatically logged into the other sites in the SSO configuration.
The WebLogic Server SAML Identity Asserter can create Security Assertion Markup Language (SAML) assertions, which allow access to remote portlets in the federated portal architecture. For more information, see the Federated Portal Guide.
| Tip: | The WSRP Identity Asserter, which provided this functionality in previous releases, is still available for backward compatibility. |
You can implement authentication programmatically using the appropriate WLP APIs. For detailed information and best practices, see Implementing Authentication Programmatically.
Authorization is the control of access to resources, answering the question: Does the user have access to this protected resource? Interactions between users and resources are controlled based on user identity or other information.
In WebLogic Portal (as in WebLogic Server), roles control access to portal resources, J2EE resources, and administrative tools, so users can access only the resources and tools that their assigned roles allow. WebLogic Portal uses WebLogic Server roles to enable you to dynamically match users to roles at login.
An authorization provider controls the interactions between users and resources to ensure confidentiality. Like a LoginModule for an authentication provider, an Access Decision is the component of an authorization provider that determines if access to a resource is allowed. Specifically, an Access Decision determines whether a subject has permission to perform the specified action on a WebLogic resource. A runtime call to the isAccessAllowed method makes this determination, based on the subject’s security roles.
It returns one of the following values:
Role mapping is the process by which principals (users or groups) are dynamically mapped to security roles at runtime. A role mapping provider determines which security roles apply to the subject when the subject is attempting to perform an operation on a resource. Because this operation usually involves gaining access to the resource, role mapping providers are typically used with authorization providers.
The default role mapping provider is the WebLogic XACML role mapping provider, which stores role policies separately in the embedded LDAP server. The WebLogic XACML role mapping provider is required for WebLogic Portal, and suitable for most needs. It is unlikely that you will need to configure a custom role mapping provider.
A security role is a privilege granted to users or groups based on specific conditions. Roles are used to determine whether to grant or deny access to resources, and to determine which capabilities on those resources are available to the user. Granting a role to a user or group confers the defined access privileges to that user or group, as long as the user or group is granted the role. Any number of users or groups can be granted a single role.
Roles are computed and granted to users or groups dynamically, based on role policies, which consist of a role name and a role definition. Role policies are dynamic, and can be based on username, group membership, user profile property values, session and request attributes, and date and time functions.
Roles can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain). For more information on role scoping, see Understanding Global and Scoped Roles.
Security policies answer the question: Who has access to a WebLogic resource? A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or roles. Hence, a role policy defines a role and a security policy defines an authorization constraint associated with that role.
BEA recommends basing security policies on roles rather than users or groups. Basing security policies on roles enables you to manage access based on a role that a user or group is granted, which is a more flexible method of management.
Security policies are kept in the authorization provider's store, which is the embedded LDAP server by default. For a list of the default security policies for the WebLogic resources, see Default Root Level Security Policies.
If a security policy is based on a user or group, the user or group must be defined in the user store for the authentication provider that is configured in the default security realm. If a security policy is based on a role, the role must be defined in the store for the role mapping provider that is configured in the default security realm.
The J2EE platform defines a means of establishing security contracts in a document known as the deployment descriptor. Deployment descriptors restrict access to resources that can be accessed directly using a URL. You must use deployment descriptors to secure portlet resources including JSPs and page flows, which could otherwise be accessed directly by anyone that knows the URL to those resources. Roles defined in deployment descriptors are based on users and groups.
For information on securing portal application resources using deployment descriptors, see Preventing Direct Access to Portal Application Resources.
Portal application resources can also be protected based on runtime constraints, such as the time of day and user profile property values. For information on setting up these runtime constraints using role-based security policies, see Setting Up Role-Based Authorization.
This section provides a high level overview of the WebLogic Portal-specific extensions to role-based access control. You can control access to portal resources for two categories of users:
For more information on role-based access control, see Setting Up Role-Based Authorization.
Use visitor entitlements to determine who may access the resources in a portal application and what they may do with those resources. Access is based on the role assigned to a portal visitor, allowing for flexible management of portal resources.
For example, if you have an Employee Review portlet that only managers should be able to access, you can create a Managers visitor entitlement role, and set entitlements so that only users who are assigned that role can view the portlet.
A portal visitor is assigned a role based on their username, group membership, user profile property values, session and request attributes, and date and time functions. For example, the Gold Member role could be assigned to visitors who are part of the frequent flyer program and have flown more than 50,000 miles in the previous year. Roles are assigned to visitors dynamically when they log in to the site. As this example highlights, visitor entitlements also enable personalization.
| Note: | If no visitor entitlement roles exist, the default behavior is to allow access to the portal and portal resources to all visitors. Content management entitlements are an exception to this policy. If there are no entitlements set on content management components, then those components are not accessible to visitors. |
Delegated administration provides secure administrative access to the WebLogic Portal Administration Console. Using the WebLogic Portal Administration Console, administrators can create and manage portals, desktops, shells, books, pages, layouts, look and feels, and portlets. A delegated administration role is a classification of a portal administrator based on their username, group membership, user profile property values, session and request attributes, and date and time functions.
In your organization, you might want different administrators to have different access privileges to various administration tasks and resources. You can use delegated administration to propagate WebLogic Portal Administration Console access privileges within a hierarchy of roles.
For example, a system administrator might have access to every feature in the WebLogic Portal Administration Console. The system administrator might then create a portal administrator role for administrators who are allowed to manage instances of portal resources in specific desktop views of your portal. The system administrator might also create a library administrator role for administrators who are allowed to manage your portal resource library.
| Note: | WebLogic Portal has one predefined delegated administration role, PortalSystemDelegator. By default, all members of the Administrators group are assigned the PortalSystemDelegator role. Anyone assigned the PortalSystemDelegator role has unlimited access to administrative tasks anywhere in the enterprise portal application. Other delegated administration roles only have access to resources if that access has been explicitly granted. |
Delegated administration roles are mapped to administrative functions on portal resources using security policies. Given the appropriate privileges, administrators can delegate both the privilege to administer a given resource capability and the privilege for the delegatee to delegate further.
For more information about the portal life cycle, see the WebLogic Portal Overview.
Figure 1-2 shows how security features fit into the portal life cycle.
The life cycle contains the following four phases:
During the architecture phase, you plan how to organize security policies and roles, and how that fits into your overall security strategy. You determine which WebLogic or custom authentication providers to use. You also determine how to secure your application using visitor entitlements and your application resources using delegated administration and deployment descriptors.
In the development phase, you can add log in and log out functionality to your portal applications.
You can also use the isUserInRole method (or tag) to verify role membership for a specific user within your application logic. This type of programmatic security, coded into portlets, books, and pages, enables you to customize a user’s path through a portal and perform fine-grained entitlement-checking.
You can use the isAccessAllowed method (or tag) to allow or deny access to a specific application resource within your application logic. This is the same method that is automatically called by the runtime framework to determine access to portal resources.
During the staging phase you can test the functionality you created in the development phase. You also set up your roles and roles and security policies. Development and staging phases often occur simultaneously. You might move iteratively between these two phases, developing and then testing what you created. If you return to the development phase and make changes, you must redeploy your portal application to see the changes in the staging phase. If you plan to use more than one development team to create your portal, determine how you will merge and assemble the code.
After you test your portal application in the staging phase, use the production phase to perfect your production environment. For example, in the production phase you might use the WebLogic Portal Administration Console to make changes to your portal application, such as changing authentication providers or making small changes in your roles or policies.
The Credential Vault is a safe storage mechanism that saves user credentials for use in any remote application. A user would enter his or her user name and password only once in a lifetime in portal. From then on whenever the user accesses a portal page that needs this information, the portlet will automatically obtain their credentials and pass them to the remote application without requiring the user to logon and enter their information again.
For more information, see Securing Third-Party Applications.
If you are new to portal development, see the WebLogic Portal Overview for more information about the portal life cycle.
For more information about users, groups, and user profiles, see the User Management Guide.
For more information about WebLogic Server security, see Security for Oracle WebLogic Server 10.3.
|