discussion from Chevron at OpenWorld
Roger Raj – Oracle
Roy DeRenzi – Chevron
project connects badge with pin code into the database and identity server. The technology behind this is how to integrate the AD server, Applicaiton Server, and JD Edwards, and other Oracle app technology.
Most applications web based. Global IDs and Desktop Ids
SmartBadge is a common access card. It contains a Java Chip that has the user credentials. It authenticates you locally without passing passwords over the network. It also has the ability to lock/destroy itself if multiple passwords fail. The idea is to authenticate against the card and the card connects to Kerberos without passing the password across the network.
Server chaining has identities stored in one server and referred to by another server. User entries are not replicated. The request is redirected to the other auth server. Oracle currently supports redirection to LDAP and Active Directory. It is available in the OID 10.1.4 and higher versions
Chevron uses AD for user provisioning and auth/authz. Smart badges presents a user certificate and passes the cert across the network. Kerberos is used for all IT services and tickets are passed between applications.
The unique part of this solution is that the Oracle 10gAS SSO server is linked into the Kerberos server and the ticket exchange is done with the AD server. The user is logged in to the web env without having to authenticate into the service.
Four major OID servers. One in US is master, others are primary for the site but replicas of the master. Each of the primary OID servers locally sync with the local AD server.
The mapping of an AD entry to an OID entry was relatively easy. There were some challenges and did require some sophisticated search filters to restrict the search to ensure that all of the information was not brought across with a user search.
Issues with sync – network bandwith caused backlogs in updates. Group entry changes caused a flurry of transactions in a short window. The capacity of the AD server lookups was not adequate at peak loads.
Server chaining allowed the directory to be virtualized and entries did not need to be replicated between AD and OID. The OID was populated with a reference. This did put more of a load on the AD server for simple queries but not for large search queries.
When a change occurs in AD, a reference is pushed out to the OID server and not the actual data. This was challenging at first but worked better once it was deployed. By default chaining is disabled. When you enable it it allows for bind, compare, modify, and search LDAP functions. Nothing needs to be changed in AD to make this happen.
Summary, two different options, Server chaining or Directory Integration Process. One or both can be used. Chevron used server chaining to reduce replication and delays involved in walking through the AD change logs (which include login events).
A good example of where the DIP component is needed is where a portal function is required that needs more attributes in the LDAP server where AD can not or does not want to store these attributes. In this example, DIP is required and chaining can not be used.
This solution does require alternate solutions for lost badges, badges left at home and temporary access for the day, and charge backs to the departments for help desk support.