Identity Management

Identity Management is Oracle's initiative to move user accounts and permissions out of the Oracle database and into a centralized repository. To understand this better, it helps to first understand the problems with the current user management system.

User Management Problems

Currently, most organizations have multiple systems that access different databases. Within those databases are database users who must log in to the application, each one as a set of database roles through which access is provided. Within each database in the system, the same users (perhaps with a different username), passwords (perhaps being different), and often the same types of roles exist redundantly.

For medium- to large- sized organizations, there's a big problem with the previous situation. With all these users stored redundantly in different databases, and with each one having multiple accounts and passwords with different permissions, the management of these users becomes an administrative nightmare. Just adding a new employee can involve the creation of multiple, redundant accounts in different databases, new passwords, and permissions. The problem becomes a security issue as users need to be deleted. If someone forgets to delete an account, that person (perhaps fired and disgruntled ) still has access to the system. Just managing these user accounts can become a full-time job for a team of administrators.

Problems further occur with all these passwords that the individual user must remember. Oftentimes the user will have multiple accounts in different databases for different applications. The usernames may be slightly different (no standardization) and the passwords are likely different, especially if they have different expiration dates or requirements. Therefore the user must either remember all the good, hard-to-guess passwords or she cheats and writes them down next to the PC. Or she could just use easy-to-guess passwords. This complication also results in the increased likelihood of forgetting a password and having to call the User Management support desk and ask them to reset the password (incurring more work for them).

Even in the best case, the user will have to keep logging in to multiple applications with the same password multiple times per day. For example, if the user has a Forms application, a Portal application, and a J2EE application, he has at least three different logins that he must remember and repeat multiple times per day.

Clearly, this creates a user management system that is inefficient at best, and at worst is expensive and a security risk.

Identity Management Solution

Oracle proposes improving the current user management situation by moving all the accounts out of the database, storing them as a single account per user in a central repository, and having all applications authenticate user logins and permissions against that repository. By implementing this method, two benefits are possible:

• Centralized user management is more efficient and secure.

• Applications can authenticate a user once against the repository and then access is automatic until she logs out.

This solution allows users to be managed centrally and provides Single Sign-On (SSO) for applications. If properly implemented, this is an excellent way to reduce administrative costs while improving efficiency and security.

Users like it, too, because they only have one username and password to remember as provided by the centralized management. With SSO, users are able to log in once in the morning to the first application they use. Then, until that user logs out, he can access any other application configured to use SSO without having to manually log in again.

This provides benefits for both the users and administrators, but the following challenges first must be overcome :

• Not all applications are well suited for having the individual user accounts taken out of the database. In some cases, the security model of the application dictates that the user needs to exist within the database instead of accessing it via a proxy user. Legacy applications are often in this situation.

• Storing user accounts in one location offers improved efficiency, but it's also a potential single point of failure.

Fortunately, some legacy applications can be modified to support Identity Management. Integration with the Identity Management framework is optional (except for Oracle Portal), so if an application cannot upgrade to this framework it can still function as normal. Newer applications can be designed from the beginning to support this user management model.

As for a centralized repository being a potential single point of failure, it likely will become a sudden, immediate problem if you don't take adequate precautions to mitigate the risks inherent to this single point of failure. As you'll see, this "repository" is actually an Oracle database and it can use the high availability and performance benefits common to all 9i and 10g databases.

Identity Management Implementation

Setting up Identity Management for an organization is a big project and there's far too much detail to completely cover it in this text. However, we wanted to explain what it is conceptually. Additionally, we wanted to identify some of the key Oracle technologies that support this initiative:

• Oracle Internet Directory (OID)

• Delegated Administration Service (DAS)

• Oracle Single Sign-On (SSO)

We'll provide an overview of the role of each of these components within Identity Management.

Oracle Internet Directory

OID is Oracle's database implementation of a directory service. Specifically, it's Oracle's Lightweight Directory Access Protocol (LDAP). This LDAP server is physically stored inside an Oracle database ( asdb or a separately configured database) and is considered part of the Oracle Infrastructure installation.

For Identity Management purposes, an LDAP is a directory lookup service for users. The LDAP implementation exists as a hierarchical tree structure that contains entries for users and attributes. Systems access the LDAP to query information about a user such as password validation, authorization, certificates, and so on. While this might sound like a database (and it is indeed stored inside a database), it's not relational in structure, it's hierarchical. Lookup speed is what is important in this directory service and OID is geared for fast lookups rather than updates.

The data within OID can be replicated to other LDAPs and can even be integrated with third-party LDAPs (iPlanet and Microsoft Active Directory) using Oracle Directory Integration and Provisioning (DIP). OID data can be loaded and modified either from the command line using ldap commands or by the GUI tool Oracle Directory Manager.

To start the Oracle Directory Manager, you'll need to log in to the infrastructure server, verify that the infrastructure is running, and then configure an X Windows connection. You may then start Oracle Directory Manager with oidadmin , as shown here:

 $ cd $ORACLE_HOME/bin $ oidadmin 

You'll be prompted to connect to a server on port 3060. You get the port number from $ORACLE_HOME/install/portlist.ini , as follows :

 Oracle Internet Directory port = 3060 

The server is the name of the node, in this case use mike.wessler.name . Enter this entry and then click Add.

The username is orcladmin and the password is what it is for ias_admin . Oracle Directory Manager is then started, as you can see in Figure 20-10.

Figure 20-10: Oracle Directory Manager

Explore the tool and learn about how users and attributes are defined. Working with OID and configuring it correctly can be tricky for new administrators. Getting used to thinking in terms of the hierarchical structure, entities, and attributes takes time, research, and hands-on experience.

Delegated Administration Service

DAS is essentially a user-administration tool. Specifically, it allows normal users to be able to change their passwords and some personal information without having to log in to the Oracle Directory Manager as an administrator (which would be a major security risk).

To access DAS, enter http://mike.wessler.name:7778/oiddas/ .

Once in the DAS page, click the Login link. You're prompted with a username and password prompt. In this case you log in with the superuser orcladmin account. In Figure 20-11 you can see how orcladmin can change account attributes.

Figure 20-11: Oracle Delegated Administration Service page

Normal users will use this page to change their passwords and the attributes (such as last name) listed previously. The orcladmin account can also use the tool to make configuration changes.

Oracle Single Sign-On

SSO is implemented via the OHS module mod_osso in conjunction with OID and DIP. The SSO server allows users to log in to an application using their OID-stored username and password as normal.

Oracle defines applications based on whether or not they're fully integrated within OID and Oracle development tools, or whether or not a username and password is simply stored in OID, as follows:

• Partner applications are Oracle applications such as Portal, Forms, and Discoverer, which are integrated within OID and SSO and validate the user's permissions against the OID account.

• External applications are applications (often non-Oracle) that present to the user a simple login page requesting a username and password. They aren't fully integrated with OID, which does little more than just storing a username and password and presenting these to the requesting application.

The user's username and password is validated within OID and a cookie is then stored in their browser. Later, when the users want to log in to other applications for which they're authorized within OID, they gain access without having to retype their username or password. This SSO authentication will continue until the user exits the applications and closes the browsers. The SSO ability is one of the greatest benefits of Identity Management.

To administer SSO applications, use the Single Sign-On Server Administration page at http://mike.wessler.name:7778/pls/orasso/orasso.home . This takes you to the home page for SSO. It lists all the partner applications currently established. To log in to the administration tool, click the Login link at the top right of the screen.

The link will prompt you for a username and password. Use orcladmin and the ias_admin password.

The Single Sign-On Server Administration page is shown in Figure 20-12.

Figure 20-12: Single Sign-On Server Administration page

Creating, modifying, or deleting new partners or external applications can be done via the SSO Server Administration page. Timeout settings for SSO can also be modified in the Edit SSO Server Configuration page. The default is a timeout after eight hours.