Considerations

Considerations

The EUS capability is impressive. Many organizations have standardized on the concept for their best practices level. Before you begin converting, be aware of a couple of caveats.

Single Credentials and Performance

Single sign-on is motivated by ease of administration, which is generally accomplished via centralization of user data, and ease of use, meaning that the user doesn’t have to remember or supply multiple identifiers and authenticators for the different applications or databases.

The primary goal with EUS is to support these two requirements for database users. The user information is centrally stored in a directory. The Oracle databases are also registered with the directory. When the user wants to access a database, the database defers authentication to the directory. The directory also provides authorization information by way of role mappings (see Chapter 7 for more information).

While often promoted as a single sign-on capability, the EUS implementation is actually a single-credential capability. The authentication occurs every time a user requests a connection to an Oracle database. The username and password just happen to be the same for all Oracle databases participating in EUS. When using a certificate for logon, the user simply connects to a database by supplying the connection alias—no username or passwords are required. It subsequently gives the user a single sign-on experience. This is an important distinction to recognize when deciding on overall system performance, because every login will require an authentication call to OiD.

A potential issue for deploying EUS centers on performance. For every Enterprise User, the database has to look up the user’s authentication, find their schema mapping, and determine which authorizations they should have. (See

This slow down in the authentication process may not be an issue. It’s generally only an issue when the application scalability or performance characteristics are high. My internal tests show different times ranging from a couple hundred milliseconds to a couple of seconds. Location of servers, network utilization, processor speed, number of users, and about a dozen other things affect these results. Your mileage will vary.

In general, the authentication process is almost always acceptable, but it’ll definitely take longer than database authentication. If there is a need to have the authentication process occur as quickly as possible, EUS will have to be thoughtfully compared.

Dependencies

With the implementation of a single authentication source also comes the risk that the single source will become a single point of failure. Oracle builds its LDAP server on the Oracle database to help ensure reliability and availability. However, if you don’t prepare for and utilize these Oracle features, such as Real Application Clusters, you won’t have a high availability solution.

Other bad things can happen, too. Network failures or other hardware failures can make the LDAP server unreachable or unavailable. It’s important to consider this when deciding on how and when to use EUS. Network redundancy and data mirroring are two critical elements for ensuring the enterprise directory is always available and accessible.