| Oracle® Collaboration Suite Security Guide 10g Release 1 (10.1.2) Part Number B25494-10 |
|
|
View PDF |
| Oracle® Collaboration Suite Security Guide 10g Release 1 (10.1.2) Part Number B25494-10 |
|
|
View PDF |
This chapter discusses Oracle Collaboration Suite Infrastructure security. It contains the following sections:
This section describes the security features in Oracle Collaboration Suite Infrastructure. It contains the following sections:
Oracle HTTP Server controls access to resources based on user identity. Identity is established through several authentication mechanisms. These include standard Apache authentication mechanisms, such as basic authentication or SSL with a client certificate and OracleAS Single Sign-On by using mod_osso. All Oracle Collaboration Suite applications can obtain an OracleAS Single Sign-On user identity from Oracle HTTP Server by using the Apache header created by mod_osso.
In Oracle Collaboration Suite, mod_osso authenticates users by specifying whether they should have access to server resources (URLs, directories) or not. Applications accessible through Oracle HTTP Server enable you to access resources by using the user identity authenticated by OracleAS Single Sign-On.
Oracle HTTP Server can be configured to protect data exchanged between the server and Web clients by using the Secure Sockets Layer (SSL) cryptographic protocol. The SSL protocol is an industry-accepted standard for network transport layer security. SSL provides encryption and data integrity, and support for digital certificate authentication using a Public Key Infrastructure (PKI). Digital certificates for SSL authentication require the use of an Oracle Wallet.
You can deploy multiple Oracle components to work with a shared instance of Oracle Internet Directory and the associated infrastructure. This sharing lets an enterprise simplify security management across all applications. In addition to the role it plays in the Oracle Identity Management Infrastructure, Oracle Internet Directory provides the following features to protect information:
Oracle Internet Directory uses SSL to ensure that data has not been modified, deleted, or retransmitted during transmission. SSL generates a cryptographically secure message digest, through cryptographic checksums, using either the MD5 algorithm or Secure Hash Algorithm (SHA), and includes the digest with each packet sent across the network.
Oracle Internet Directory ensures that data is not disclosed during transmission by using public key encryption available with SSL. In public key encryption, the sender encrypts the message by using the public key of the recipient. When the message is delivered, the recipient decrypts the message by using the recipient's private key.
Authorization is the permission given to a user, program, or process to access an object or a set of objects. When you perform directory operations within a directory session, the directory server ensures that you have the permissions to do so. The directory server prevents unauthorized operations on data by using access control information. Access control information is the directory metadata that constitutes the administrative policies relating to access control. This information is stored in Oracle Internet Directory as user-modifiable operational attributes, each of which is called an Access Control Item (ACI). A list of ACI attribute values is called Access Control List (ACL). The ACL is associated with directory objects. The attribute values in the ACL represent the permissions that various directory user entities have on a given object.
Authentication enables a directory server to establish the true identity of the user connecting to the directory. Authentication is performed whenever a Lightweight Directory Access Protocol (LDAP) session is established. As a result, every session has an associated user identity.
Oracle Internet Directory provides Simple Authentication and Security Layer (SASL) authentication over an SSL connection. During SASL authentication, both the client and server authenticate themselves to each other by providing certificates.
Oracle Internet Directory protects directory passwords by storing them as one-way hashed values. Storing passwords as one-way hashed values, rather than as encrypted values, secures the passwords because a malicious user can neither read nor decrypt them.
A password policy is the rule that governs how passwords are used. When you attempt to access a directory, the directory server ensures that the password you provide conforms to the password policy.
When you establish a password policy, you can set the following types of rules:
Minimum password length
Expiration of passwords
Alphanumeric requirements, such as ensuring at least one numeric character in the password
Whether a new password can be the same as an old password
You cannot secure any system where the physical access to the systems is also not secured. Systems storing or serving sensitive information must be physically secured because it is easy to damage or steal the hardware.
At the lowest levels of the network, techniques to enforce security include the use of firewalls to create a demilitarized zone (DMZ). This helps ensure that the network traffic follows specified rules. For example, traffic from the Internet may not pass directly to the database but must go through both the DMZ and the application server tier. Good network security practices employ firewalls from different vendors to form the DMZ. You need to ensure that firewall rules are correctly configured and that the firewall and router passwords are secure. Switched networks, rather than bus topology-based networks, provide an intruder with less opportunity for packet sniffing.
In addition to securing the firewalls and the network, you need to secure the operating system that runs Oracle Collaboration Suite. Vendors, Oracle Consulting, and third-party security consultants often have well-defined procedures and practices to secure the operating system. These include:
Closing unused ports, such as telnet, ftp, and finger, using xinetd or inetd with TCP wrappers
Removing unused or default user accounts
Applying the latest patches
Removing unnecessary software
Checking for setuid/setgid software
Installing and configuring intrusion detection software
Removing host banners
You need at least two databases to run Oracle Collaboration Suite and at times, three databases, one each for:
Oracle Application Server Infrastructure and Oracle Internet Directory
Oracle Mail
Oracle Content Services
All these databases must be secured against attack.
Security Checklist for Oracle Database 10g
For databases, establishing a secure configuration is the first line of defense against attacks.
Implementing the following recommendations provides the basis for a secure database configuration:
Install only what is required.
Do a custom installation. Choose to install only additional products and options that you require, in addition to the database server.
Lock and expire default user accounts.
Oracle Collaboration Suite Database installs with many default database server user accounts. After you create a database server instance, the Database Configuration Assistant automatically locks and expires most default database user accounts. After the database is installed, lock the SYS and SYSTEM user accounts and use the AS SYSDBA account for administrator access. Specify the administrative passwords individually.
|
Note: If you use Oracle Universal Installer or Database Configuration Assistant, then you will be prompted for newSYS and SYSTEM passwords. The defaults values, change_on_install or manager, will not be accepted. |
The AS SYSDBA account tracks the operating system user name, maintaining accountability. If you only need access for database startup and shutdown, then use AS SYSOPER, which has fewer administrative privileges than SYS, but sufficient to perform basic operations such as startup, shutdown, mount, backup, archive, and recover.
Database Configuration Assistant is not used during a manual installation. So, all the default database users remain unlocked and gain unauthorized access to data. In addition, the default database users can disrupt database operations. After a manual installation, use SQL to lock and expire all default database user accounts except SYS, SYSTEM, SCOTT, and DBSNMP. If a locked account is needed later, then a database administrator can unlock and activate that account with a new password.
Table 3-1 lists the database users that are available after a typical Oracle Database installation using Database Configuration Assistant.
Table 3-1 Default Accounts and Their Status (Standard Installation)
| USER NAME | ACCOUNT_STATUS |
|---|---|
| ANONYMOUS | EXPIRED & LOCKED |
| CTXSYS | EXPIRED & LOCKED |
| DBSNMP | EXPIRED & LOCKED |
| DIP | EXPIRED & LOCKED |
| DMSYS | EXPIRED & LOCKED |
| EXFSYS | EXPIRED & LOCKED |
| HR | EXPIRED & LOCKED |
| MDDATA | EXPIRED & LOCKED |
| MDSYS | EXPIRED & LOCKED |
| MGMT_VIEW | EXPIRED & LOCKED |
| ODM | EXPIRED & LOCKED |
| ODM_MTR | EXPIRED & LOCKED |
| OE | EXPIRED & LOCKED |
| OLAPSYS | EXPIRED & LOCKED |
| ORDPLUGINS | EXPIRED & LOCKED |
| ORDSYS | EXPIRED & LOCKED |
| OUTLN | EXPIRED & LOCKED |
| PM | EXPIRED & LOCKED |
| QS | EXPIRED & LOCKED |
| QS_ADM | EXPIRED & LOCKED |
| QS_CB | EXPIRED & LOCKED |
| QS_CBADM | EXPIRED & LOCKED |
| QS_CS | EXPIRED & LOCKED |
| QS_ES | EXPIRED & LOCKED |
| QS_OS | EXPIRED & LOCKED |
| QS_WS | EXPIRED & LOCKED |
| RMAN | EXPIRED & LOCKED |
| SCOTT | EXPIRED & LOCKED |
| SH | EXPIRED & LOCKED |
| SI_INFORMTN_SCHEMA | EXPIRED & LOCKED |
| SYS | OPEN |
| SYSMAN | EXPIRED & LOCKED |
| SYSTEM | OPEN |
| WK_TEST | EXPIRED & LOCKED |
| WKPROXY | EXPIRED & LOCKED |
| WKPROXY | EXPIRED & LOCKED |
| WMSYS | EXPIRED & LOCKED |
| XDB | EXPIRED & LOCKED |
Change default user passwords.
Security is breached when the default database server user account has the default password even after installation. To fix this:
Change the default passwords of administrative users immediately after installing the database server.
In any Oracle environment (production or test), assign strong, meaningful passwords to the SYS and SYSTEM user accounts immediately after successful installation of the database server. The passwords for SYS and SYSTEM should never remain in their default states. Similarly, for production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.
Change the default passwords of all users immediately after installation.
Lock all accounts and expire all default passwords after installation. If any such account is later activated, then change its default password to a new meaningful password.
Enforce password management.
Apply basic password management rules, such as password length, history, and complexity, to all user passwords.
Request all users to change their passwords regularly, such as every eight weeks.
If possible, use Oracle Advanced Security with network authentication services (such as Kerberos), token cards, smart cards, or X.509 certificates. These services provide strong user authentication and enable better protection against unauthorized access.
Enable data dictionary protection.
Implement data dictionary protection to prevent users having the ANY system privilege from using it on the data dictionary. Oracle Collaboration Suite Database sets the O7_DICTIONARY_ACCESSIBILITY to FALSE. This setting prevents using the ANY system privilege on the data dictionary, except for authorized users making DBA-privileged connections (for example, CONNECT/AS SYSDBA).
Practice the principle of least privilege.
The following practices implement this principle:
Grant necessary privileges only.
Do not provide database users more privileges than necessary. Enable only those privileges that are required to efficiently perform necessary jobs:
Restrict the number of system and object privileges granted to database users.
Restrict the number of SYS-privileged connections to the database. For example, there is no need to grant CREATE ANY TABLE to any non-DBA-privileged user.
Revoke unnecessary privileges and roles from the PUBLIC database server user group.
The default role, granted to every user in an Oracle database, enables unrestricted use of its privileges, such as EXECUTE on various PL/SQL packages. If unnecessary privileges and roles are not revoked from the PUBLIC user group, then a minimally privileged user can access and run packages otherwise inaccessible to the user.
Grant users roles only if they need all of the role's privileges.
Roles (groups of privileges) are useful for granting permissions to users quickly and easily. If your application users do not need all the privileges encompassed by an existing role, then create your own roles containing only the necessary privileges. Similarly, ensure that roles contain only the privileges that reflect job responsibility.
For example, grant the CREATE SESSION privilege to users to authorize them to log in to the database, rather than granting them the CONNECT role, which has many additional privileges. Unless users require all the extra privileges contained in the CONNECT role or any other role, individually assign to each user only the minimum set of individual privileges needed. Alternatively, create your own roles and assign only the required privileges.
For example, it is imperative to strictly limit the privileges of SCOTT. Drop the CREATE DBLINK privilege for SCOTT. You need to drop the entire role for SCOTT because privileges acquired by means of a role cannot be dropped individually. Recreate your own role with only the privileges needed, and grant that new role to the user. Similarly, to enhance security, drop the CREATE DBLINK privilege from all users who do not require it.
Restrict permissions on run-time facilities.
Do not assign all permissions to any database server run-time facility, such as the Oracle Java Virtual Machine (OJVM).
Instead, grant specific permissions to the explicit document root file paths for such facilities that may run files and packages outside the database server.
Here is an example of a vulnerable run-time call:
call dbms_java.grant_permission('SCOTT',
'SYS:java.io.FilePermission','<<ALL FILES>>','read');
Here is an example of a secure run-time call:
call dbms_java.grant_permission('SCOTT',
'SYS:java.io.FilePermission','<<actual directory path>>','read');
Enforce Access Controls Effectively.
Although remote authentication can be enabled (TRUE), your installation is more secure with it off (FALSE, which is the default). With remote authentication turned on, the database implicitly trusts every client, because it assumes every client was authenticated by the remote authenticating system. However, clients such as remote computers cannot be trusted to perform proper operating system authentication. So, enabling this feature is a very poor security practice. To enforce proper server-based authentication of clients connecting to an Oracle database, leave or disable this feature (remote_os_authentication=FALSE, which is the default).
Restrict Operating System Access.
The following practices implement the required restrictions on operating system access:
Limit the number of operating system users.
Limit the privileges of the operating system accounts (administrative, root-privileged or DBA) on the Oracle Database host (physical computer) to the fewest and least powerful privileges required for each user.
Disallow modifying the default permissions for the Oracle Database home (installation) directory or its contents, even by privileged operating system users or the Oracle owner.
Restrict symbolic links. Ensure that when any path or file to the database is provided, neither that file nor any part of that path is modifiable by an untrusted user. The file and all components of the path should be owned by the DBA or some trusted account, such as root. This recommendation applies to all types of files, such as data files, log files, trace files, external tables, and bfiles.
Restrict Network Access.
The following practices implement the required restrictions on network access
Use a firewall.
Keep the database server behind a firewall. Oracle Net, which is the network infrastructure of the Oracle database, supports various firewalls from different vendors. Supported proxy-enabled firewalls include Network Associates' Gauntlet and Axent's Raptor. Supported packet-filtered firewalls include Cisco's PIX Firewall and supported stateful inspection firewalls include CheckPoint's Firewall-1.
Do not leave any port open in the firewall.
For example, if the Oracle database is behind a firewall, then do not leave the 1521 port of the Oracle listener open to make a connection to the Internet.
Leaving the port open introduces several security vulnerabilities, including more port openings through the firewall, multithreaded operating system server issues, and revelation of crucial information about databases behind the firewall. Moreover, an Oracle listener running without an established password may be probed for critical details about the databases on which it is listening, such as trace and logging information, banner information, and database descriptors and service names.
The availability of this information and an ill-configured firewall will enable an attacker to launch malicious attacks on target databases.
Authenticate resources accessing your systems.
Authenticating client computers over the Internet is problematic. Instead, authenticate users. This helps avoid client system issues that include falsified IP addresses, hacked operating systems or applications, and falsified or stolen client system identities. The following steps improve client computer security:
Configure the connection to use SSL. Using SSL communication does not allow eavesdropping and enables the use of certificates for user and server authentication.
Set up certificate authentication for clients and servers such that:
i. The organization is identified by unit and certificate issuer and the user is identified by distinguished name and certificate issuer.
ii. Expired certificates are tested by applications.
iii. Certificate revocation lists are audited.
Check network IP addresses.
Use the Oracle Net valid node checking security feature to allow or deny access to Oracle server processes from network clients with specified IP addresses. To use this feature, set the following protocol.ora (Oracle Net configuration file) parameters:
tcp.validnode_checking = YES
tcp.excluded_nodes = {list of IP addresses}
tcp.invited_nodes = {list of IP addresses}
The first parameter activates the feature, whereas the next two parameters deny or allow specific client IP addresses from making connections to the Oracle Listener. This can prevent potential Denial of Service attacks.
Encrypt network traffic.
If possible, use Oracle Advanced Security to encrypt network traffic between clients, databases, and application servers.
|
Note: Oracle Advanced Security can be configured, after licensing, with the Oracle Net Manager tool or by manually setting sixsqlnet.ora parameters to enable network encryption. |
Secure the operating system.
Secure the host operating system by disabling all unnecessary operating system services. Both UNIX and Microsoft Windows platforms provide several operating system services, most of which are not necessary for most deployments. Such services include FTP, TFTP, and TELNET. Close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and enabling the other does not secure the operating system.
Apply All Security Patches and Workarounds.
Always apply all the relevant and current security patches for the operating system on which Oracle Database resides, for the Oracle Database itself, and for all installed Oracle Database options and components thereof.
Periodically check the security site on Oracle Technology Network for information about security alerts released by Oracle.
http://www.oracle.com/technology/deploy/security/alerts.htm
Also, check the Web site of Oracle Worldwide Support Service, Metalink, for information about available and upcoming security-related patches.
Contact Oracle Security Products.
If you find a security vulnerability in the Oracle database, then raise a service request to Oracle Worldwide Support Services by using OracleMetalink or send an e-mail with a complete description of the problem, including product version and platform, together with any scripts and examples to the following address:
Oracle Collaboration Suite applications run within Oracle Application Server. This section describes the security checklist for Oracle Application Server.
Security Checklist for Oracle Application Server
The security checklist for Oracle Application Server is discussed under the following headings:
Operating System Security
To secure the operating system:
Apply operating system vendor-recommended security patches
Disable unused or unnecessary services
Remove any operating system samples or example code that is not in use
Remove any user accounts that are not in use
Consider moving to SSH and disable Telnet/FTP
General Oracle Collaboration Suite Security
To secure Oracle Collaboration Suite:
Check the Oracle Technology Network (OTN) site for relevant Oracle security alerts
Check OracleMetalink for patch set releases
Remove unused services
Utilize RedirectMatch and Rewrite rules
When using Allow or Deny rules, use IP addresses
Reduce the TimeOut setting
Protect administrative URIs
Remove any samples and examples from the Oracle Collaboration Suite code tree
Delete all users and code not in use
Configure only the ports that are necessary for the application
Change user of httpd daemon to unprivileged user
Replace standard error pages with custom error pages
Remove any unnecessary directory references from httpd.conf
Remove actual hosting server name from httpd.conf
Disable the Oracle Application Server banner from the server
Place all files that are not necessary for the application in a location inaccessible by a Web user
Remove any unnecessary directives, such as documentation directives
Turn off indexing for directories
PL/SQL Security
Securing PL/SQL Data Access Descriptors (DADs) is critical for securing applications that use the PL/SQL toolkit. To secure PL/SQL DADs:
Remove or restrict administration access
Protect PL/SQL Toolkit
Remove DAD configurations that are not required
Restrict DAD access
Limit privileges of DAD owners and users
Encrypt DAD passwords
Apply necessary toolkit/PLSQL patches
Oracle Collaboration Suite implementation may include third-party products such as SMTP relay servers, antispam, and antivirus software. These products must also be secured against potential attacks and each vendor should be consulted for best practices.
Oracle Collaboration Suite uses OracleAS Single Sign-On to provide a single password for all Oracle Collaboration Suite applications and many other Oracle and third-party systems. When users are required to use multiple passwords for different systems, they tend to do one of the following:
Use the same password for many systems. If one password is broken, then all systems with the same password are compromised.
Store passwords insecurely, such as writing passwords on sticky notes.
Use easily remembered passwords.
When using OracleAS Single Sign-On, you are required to only log in once for all the application components (Oracle Content Services, Oracle Calendar, Oracle Search etc.).
User passwords are stored not as clear text but as one-way hash values. Oracle Internet Directory enables administrators to manage users from a centralized location for account enabling or disabling and provisioning. In addition, Oracle Internet Directory helps administrators implement password policies to ensure that users are not using easily guessed or easily broken passwords. The password policies enforced by organizations are configurable.
|
See Also: Oracle Internet Directory Administrator's Guide for more information about password policies |
Oracle products use Oracle Identity Management, an integrated infrastructure, to secure users and applications across an enterprise. This section describes the Oracle Identity Management infrastructure and components. It contains the following sections:
An identity is a set of attributes that uniquely identifies a network entity. Identity management is the process by which application user identities are defined and managed in the enterprise environment.
Identity management enables you to perform the following tasks:
Provision and coordinate user identities
Automate user account provisioning
Manage user roles, privileges, and credentials
Delegate responsibility
Deploy applications easily and securely
Manage your preferences and passwords
Provide users with single sign-on access
By using an identity management system, an enterprise can:
Reduce administration costs through centralized account management and automated tasks.
Accelerate application deployment by enabling new applications to leverage the existing infrastructure to provision user accounts and privileges.
Improve security and usability by centrally managing user passwords and security credentials and customizing applications to leverage centralized authorization and policy information.
Oracle Identity Management enables rapid deployment of Oracle products in the enterprise, without the cost and complexity associated with integrating disparate systems. Oracle Identity Management also functions as a single point of integration between the Oracle environment and any third-party identity management environments.
Figure 3-1 illustrates the components of the Oracle Identity Management infrastructure and displays how various Oracle products and third-party products rely on it.
Figure 3-1 Oracle Identity Management Infrastructure
The Oracle Identity Management infrastructure includes the following components:
Using OracleAS Single Sign-On, you need to sign on to the enterprise network only once instead of being prompted for sign-on credentials each time you access other Web applications. When you log on to an application for the first time using OracleAS Single Sign-On, your identity is validated and you do not need to provide your credentials to invoke different applications during a session.
Provisioning Service refers to integrating user account creation and privilege assignment tasks for all applications across the enterprise, based on Oracle Identity Management events. These activities are governed by application-specific rules and by enterprise deployment policies. Provisioning Service facilitates both integration and automation of provisioning-related tasks.
Centralized management of user identities and other security information has its benefits. However, the process of administration could become unscalable if administrative functions are not delegated to different sets of administrators. To support this delegation, the Oracle Delegated Administration Services component defines a delegation model based on Role-Based Access Control (RBAC). The Oracle Identity Management infrastructure also supports the interfaces required to implement this delegation model and for applications that rely on Oracle Identity Management.
Oracle Delegated Administration Services consists of the following:
Interfaces to enable end-user self services, such as:
Updating, resetting, and recovering user password
Managing user preferences and profiles
Looking up white pages in the directory
Interfaces to enable directory administrator services, such as:
Creating and managing users
Creating and managing groups
Customizing Oracle Delegated Administration Services user and group management interfaces
Customizing end-user self-service interface characteristics
Configuring Oracle Identity Management service-related administration roles
Oracle Internet Directory includes:
Oracle directory server, which responds to client requests for information about resources and to updates of that information by using a multitiered architecture directly over TCP/IP
Oracle directory replication server, which replicates LDAP data between Oracle directory servers
Directory administration tools, which include:
Oracle Directory Manager, which simplifies directory administration by using a Java-based graphical user interface
Command-line administration and data management tools invoked from LDAP clients
Directory server management tools within Oracle Enterprise Manager Application Server Control. These tools enable you to:
Monitor real-time events and statistics from a browser
Integrate the data into a new repository
Oracle Internet Directory Software Developer's Kit
Oracle Application Server Certificate Authority provides a simple self-service interface for OracleAS Single Sign-On users to acquire their own X.509 certificates. If you want to deploy PKI to enable high levels of security by using OracleAS Certificate Authority, then you can do so without incurring significant overheads.
Although Oracle Identity Management is designed to provide an enterprise infrastructure for Oracle products, it can also function as a general-purpose identity management solution for user-written and third-party enterprise applications. It provides a robust and scalable enterprise-wide identity management platform for third-party applications, hardware, and network operating systems. Custom applications can leverage Oracle Identity Management by using the following services and APIs:
Oracle Internet Directory provides LDAP APIs for C, Java, and PL/SQL, and is compatible with other LDAP SDKs. Oracle Delegated Administration Services provide a core self-service console that may be customized to support third-party applications. In addition, it provides a number of services for building customized administration interfaces that manipulate directory data. Oracle Provisioning and Directory Integration Services enable you to provision third-party applications and integrate the Oracle environment with other provisioning systems. OracleAS Single Sign-On provides APIs to develop and deploy partner applications that share a single sign-on session with other Oracle Web applications.
Java AuthoriZatioN (JAZN), the Oracle implementation of the Java Authentication and Authorization Service (JAAS) standard, enables applications developed for the Web using Oracle J2EE environment to leverage the Oracle Identity Management infrastructure for authentication and authorization.
This section describes the following benefits provided by Oracle Identity Management to enterprise applications deployed on Oracle Application Server:
Oracle Internet Directory facilitates centralized user management for the Oracle environment and for the rest of the enterprise. Users are defined centrally in Oracle Internet Directory. All other Oracle Identity Management and security services, as well as all applications that in turn rely on these services, share this single definition of user identity, credentials, profiles, and preferences. This centralized management not only facilitates administrative convenience, but also enhances security for applications that share this infrastructure.
Password policies help strengthen the security of password-based authentication environments. Password policies enable administrators to establish rules that you must follow while setting and using passwords to authenticate yourself to the applications on the network. Oracle Identity Management password policies can be customized during deployment.
Oracle Identity Management supports complex password policies that enterprises can leverage to secure user passwords. Oracle Internet Directory and the OracleAS Single Sign-On services support value-based and state-based password policies:
Value-based password policies make it difficult to guess passwords. These policies force the password values to be arbitrarily complex, such as minimum lengths and presence of minimum number of special characters.
State-based password policies help enforce user discipline, such as periodically resetting password values. State-based password policies also facilitate detection and prevention of malicious attempts to break into authentication environments. Password expiration policies and lockout policies based on maximum number of retries are examples of state-based password policies.
You can use the Oracle Internet Directory plug-in capability to implement custom password policies.
Oracle Internet Directory clients can use SSL 2.0 or SSL 3.0. This section describes how to configure SSL for Oracle Internet Directory. It contains the following topics:
During start-up of a directory server instance, the directory reads a set of configuration parameters, including the parameters for the SSL profile. If you are going to run the directory with SSL enabled, you need to examine—and possibly reconfigure—the SSL parameters in the configuration set entry.
To run a server instance in secure mode, set the SSL Enable parameter in the configuration settings to 1: the default secure port is 3031. To allow the same instance to run non-secure connections concurrently, set SSL Enable to 2: the default non-secure port is 3060.
You can create and modify multiple sets of configuration parameters with differing values, using a different configuration set entry for each instance of Oracle Internet Directory. This is a useful way to accommodate clients with different security needs.
|
Note: Oracle recommends that you create separate configuration sets and modify their SSL values, rather than modify SSL values in the default configuration set. The default set may be required by Oracle Support Services in the diagnosis of certain technical issues. |
|
See Also: Oracle Internet Directory Administrator's Guide for information about configuring SSL parameters by using Oracle Directory Manager and command-line tools |
In Oracle Internet Directory, only wallets in encrypted format (cwallet.sso) are supported. Before you can start an SSL instance, you must use Oracle Wallet Manager, which is enabled to Auto Login, to open the wallet.
On Microsoft Windows, before starting a directory server instance with SSL enabled, you must change the Logon Account of the Oracle Directory Service from Local System Account to the user who owns the wallet. This user should be member of the Administrator Group.
|
See Also: Oracle Internet Directory Administrator's Guide for more information about configuring SSL parameters |
If you want to support both SSL and non-SSL clients on the same host, then you need to configure two distinct server instances.
In Oracle Internet Directory, the Oracle directory replication server cannot communicate directly with SSL-enabled Oracle directory server instances.
In an enterprise environment, you often deploy multiple applications against a shared infrastructure. For example, you may have both your HR application and your sales application hosted in the same application server. These applications have separate administrators, but both depend on the security infrastructure provided by the Oracle Internet Directory server. This section contains the following topics:
Oracle Collaboration Suite provides fine-grained control over system administration and management privileges. This enables you to:
Delegate only the privileges necessary for installation and administration
Grant application administration permissions without making the application administrator an Oracle Internet Directory superuser
Isolate application installation privileges from application administration privileges
Encapsulate privileges for each application, so that the permission to deploy one component does not grant the right to deploy or administer other components
Using the delegation model, a global administrator can delegate privileges to realm administrators to create and manage the identity management realms for hosted companies. Realm administrators can, in turn, delegate privileges to end users and groups to change their application passwords, personal data, and preferences. Each type of user can be given the necessary level of privileges.
To delegate the necessary privileges, you assign the user to the administrative group. If you store the data for both enterprise users and the e-mail service in the directory, then you need to specify a unique administrator for each set of data. For example, to specify a user as the administrator of enterprise users, you assign that user to the Enterprise User Administrators Group. Similarly, to specify a user as the administrator of the e-mail services, you assign that user to the E-mail Service Administrators Group.
The new privilege model supports the following user roles:
Oracle Application Server Installation Administrator
Responsible for installing and uninstalling applications. This administrative privilege is distinct from the next privilege, Oracle Application Server Application Administrator.
Oracle Application Server Application Administrator
Responsible for managing the roles and privileges used within an application.
Oracle Identity Management Infrastructure Administrator
Responsible for managing Oracle Internet Directory and other Identity Management technologies.
Oracle Application Server Application User
Has no responsibilities. Runs the application and has only the permissions granted by the application.
|
Note: The same user may perform multiple roles. |
In an Oracle Collaboration Suite environment, the directory superuser creates the following:
Oracle Context
Realm
Realm-specific Oracle Context
Entry for the realm administrator
The realm administrator, in turn, delegates administration of the Oracle Context to specific users by assigning those users to the Oracle Context Administrators Group. Oracle Context Administrators then delegate administration of Oracle Application Server to one or more users by assigning them to the Oracle Application Server Administrators Group. These administrators install and administer Oracle Application Server components and delegate administration of user and group data to other administrators. The latter can, in turn, delegate others to administer user and group data.
If you are working in an existing Oracle Internet Directory, then you must work with the Oracle Internet Directory administrator to ensure that you have the following privileges:
Administration privileges for Oracle Application Server. This enables you to install and configure Oracle Application Server components.
Privileges to delegate privileges to other users: This enables you to delegate privileges to application administrators (for example, the OracleAS Portal administrator).
To delegate administrative privileges, the Oracle Internet Directory super user does the following:
Creates an identity management realm
Identifies a special user in that realm, the realm administrator
Delegates all privileges to that realm administrator
This realm administrator, in turn, delegates certain privileges that Oracle components require to the Oracle defined roles, such as Oracle Application Server administrators. The Oracle components receive these roles when they are deployed.
In addition to delegating privileges to roles specific to Oracle components, the realm administrator can also define roles specific to the deployment, such as a role for help desk administrators, and grant privileges to those roles. These delegated administrators can, in turn, grant these roles to end users. In fact, because a majority of user management tasks involve self-service, such as changing a phone number or specifying application-specific preferences. These privileges can be delegated to end users by both the realm administrator and Oracle component administrators.
In the case of a group, one or more owners, typically end users, can be identified. If they are granted the necessary administrative privileges, then these owners can manage the group by using Oracle Internet Directory Self-Service Console, Oracle Directory Manager, or command-line tools.
Many Oracle components administer user entries in Oracle Internet Directory and need the corresponding privileges. For example:
When the Oracle Application Server Single Sign-On server authenticates a user, the server:
Connects to Oracle Internet Directory using its own identity
Verifies whether the password entered by the user matches the password stored in the directory
To do this, the OracleAS Single Sign-On server needs permission to compare user passwords. To set up the OracleAS Single Sign-On cookie, you need permission to read user attributes.
To grant access to a user, OracleAS Portal must retrieve the user attributes. To do this, OracleAS Portal logs in to Oracle Internet Directory as a proxy user, impersonating the user seeking access. It needs the privileges of a proxy user.
In general, Oracle components can require these privileges:
Read and modify user passwords
Compare user passwords
Function as a proxy on behalf of users accessing applications
Administer the Oracle Context where all Oracle components store their metadata
|
See Also: Oracle Internet Directory Administrator's Guide for a comprehensive discussion of privilege delegation |
