Oracle Data Sharing & Security

Executive Summary In today’s business environment, where division of labor is present all around and tasks are highly specialized, it becomes imperative for any organization to make sure that users have access to data that is relevant only to them to carry out their specified task. Businesses have to make sure that not only the relevant data is available to the users but the data is also secure. This can become quite a challenging and complex job to manage given that there are users at different level of organization, who require different levels of access, and there can be multiple systems that can be used to access data. For example, there can be a requirement that the ‘Bill To’ address of a customer can only be updated by the legal department or the customer service department should not be allowed to create, update or delete customer’s (organization party) legal name and address. Such requirements can be the result of an organization’s attempt to be SOX compliant or as a result of corporate policy. Given this, it becomes quite a complex, but necessary job to make sure that users have access to the right data with optimal security. Oracle released this much needed functionality of ‘Data Sharing and Security’ (DSS) in Oracle Customers Online, release 11.5.9 (IMC.J). This functionality gives the implementing organization a tool to centrally manage data security. System administrators can setup up data sharing groups that can be used to determine which user or responsibility has privileges to create, update, or delete data. Before this release the most common way to exercise control over data was through menu customizations where in most cases users could either have full access or not have any access at all. This paper attempts to explain the concepts of DSS (including how the DSS logic works) and illustrates in detail how an implementing organization can setup DSS to achieve data security. Data Sharing & Security (DSS) Concepts 1. To turn on DSS, system profile ‘HZ: Data Sharing and Security Enabled’ should be set to ‘Yes’ at the site level. Doing so will make all the responsibilities read only. After this, individual security groups can be created and responsibilities can be assigned create, update, or delete privileges for various TCA entities. 2. DSS provides row level security where a user can create, update, or delete a row in the table. It does not provide column level security where a user can create, update, or delete a particular column (attribute) in a row. For example, if a user is allowed to create party address the he / she will be allowed to populate all the columns in the address row. User cannot have create privilege for just Address2 and City columns. 3. Create, update, or delete privileges can be assigned to: a. User (individual users level) b. Group (responsibility level) c. Public (all users) 4. Privileges consist of ability to: a. Create b. Update c. Delete 5. DSS provides ranking to prioritize data access. For example, if a party falls under two or more classifications then this conflict can be addressed by ranking a DSS group with one classification higher than the DSS group with another classification or assigning a combination of classifications to different DSS groups. 6. Person parties that gets created by HR module can only be modified by a user who is also an authorized HRMS user. Defining A Data Sharing Group The following attributes can be secured in a DSS group: 1. Classifications: By default, users and responsibilities are allowed to create, update and delete (depending on boxes checked in ‘Assignment’) records for all the seeded and custom classifications. By selecting particular classification(s) in this region, one can specify that the user and responsibility are allowed to create, update and delete the record which has this classification(s). It’s like adding a where clause. For example, if the DSS group has a classification of ‘GSA’ and the ‘Organization Party, Address and Contact Points entities are checked, then the associated responsibility can update only the party which has ‘GSA’ classification. 2. Relationship: By default users and responsibilities are allowed to create, update and delete (depending on boxes checked in ‘Assignment’) records for all the relationship roles. By selecting particular relationship roles in this region, one is specifying that the user and responsibility is allowed to create, update and delete the record which has this relationship role(s). It’s like adding a where clause. For example, if a DSS group has a relationship role of ‘Division’ and the relevant privileges are checked, then the associated responsibility can create, update and delete only the party which has a ‘Division’ relationship role. 3. Created By Module: By default the DSS group pertains to all the modules. However, by selecting a particular module(s), users can say that the DSS holds true as long the record is being created, updated and deleted by this module(s). This refers to the ‘Who’ column in the table. Who created the record? It’s like adding a where clause. For example, if the DSS group has the ‘Created By Module’ TCA_V1_API (OCO) and the associated responsibility is of Order Management then the user will not be able to create, update and delete the record. 4. Entities: a. Person Parties b. Organization Parties c. Party Contact Points d. Party Site Contact Points e. Classification Code Assignments f. Relationships g. Parties h. Party Address The above entities can be selected to give a user and a responsibility privileges to create, update and delete any record with the checked entities. DSS Basic Process DSS Basic Process Legend Process Decision Process Start/End Create, Update, or Delete Box Checked? No Yes Select DSS Group With Highest Ranking Yes Select DSS Groups With Matching Entity Responsibility Exists? No Action Not Allowed Create, Update, or Delete Record Record Created, Updated, or Deleted Action Not Allowed DSS Logic & Setup Illustration Below is logic that the Data Sharing and Security module uses. The illustration below can also be used by an implementing organization as guidelines to implement DSS as per its needs. Requirements # Responsibility Description 1 OCO Organization Only This responsibility should allow creating, updating and deleting only organization and its attributes (profiles). 2 Sales User This responsibility should not allow creating, updating, and deleting organizations and their attributes. This should only allow creating, updating and deleting party contacts. 3 OCO User This responsibility should not have any restrictions. Should allow creating, updating, and deleting any record. 4 Inquiry Only This responsibility should make the application read only. Should not allow creating, updating, and deleting any record. Data Sharing Groups Rank Name Description Enabled 1 Create Organization Only Create Organization Only Yes 2 Create Contact Only Create Contact Only Yes 3 Inquiry Only Inquiry Only Yes 4 Human Resources Shared Data* Human Resources Shared Data Yes 5 Public* Public Yes * Already comes setup with the application. Setup Details of Each DSS group ‘Create Organization Only’ Data Sharing Group Field Value Data Sharing Group Name Create Organization Only Data Sharing Group Code CREATE_ORGANIZATION_ONLY Data Sharing Group Description Create Organization Only Rank 1 Entities Name Selected Parties Person parties Organization Parties Yes Relationships Classification Code Assignments Party Contact Points Party Site Contact Points Party Addresses Assign Privileges Type of Grantees Name Create Update Delete Group OCO Organization Only Yes Yes Yes Group OCO Users Yes Yes Yes ‘Create Contact Only’ Data Sharing Group Field Value Data Sharing Group Name Create Contact Only Data Sharing Group Code CREATE_CONTACT_ONLY Data Sharing Group Description Create Contact Only Rank 2 Entities Name Selected Parties Person parties Yes Organization Parties Relationships Classification Code Assignments Party Contact Points Party Site Contact Points Party Addresses Assign Privileges Type of Grantees Name Create Update Delete Group Sales User Yes Yes Yes Group OCO User Yes Yes Yes ‘Inquiry Only’ Data Sharing Group Field Value Data Sharing Group Name Inquiry Only Data Sharing Group Code INQUIRY_ONLY Data Sharing Group Description Inquiry Only Rank 3 Entities Name Selected Parties Yes Person parties Yes Organization Parties Yes Relationships Yes Classification Code Assignments Yes Party Contact Points Yes Party Site Contact Points Yes Party Addresses Yes Assign Privileges Type of Grantees Name Create Update Delete Group Sales User Yes Yes Yes Group OCO Organization Only Yes Yes Yes Group Inquiry Only Responsibility - OCO Organization Only Scenario I – Create Organization User creates an organization or updates an organization. The record will look at: 1. All the DSS groups which have ‘Organization Parties’ entity checked. 2. Ranking of these DSS groups. The record will select the following DSS groups with Organization Party entity checked. 1. Create Organization Only 2. OCO Inquiry 3. Public Since ‘Create Organization Only’ DSS group has a higher ranking (1) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the first DSS ‘Create Organization Only’ and then look at the responsibilities. Since this DSS has ‘OCO Organization Only’ responsibility and the ‘Create’, ‘Update’, and ‘Delete’ boxes are checked therefore, the system will allow the record to be created. Scenario I a – Creating Contact Points To create an organization, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entity checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process address and contact points, the record will select the following DSS groups with above 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS has ‘OCO Organization Only’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow address and contact points records to be created. Scenario II – Create Person / Contact Party If the user tries to create or update a contact using this responsibility then the record will look at: 1. All the DSS groups which have ‘Person Parties’ entity checked. 2. Ranking of these DSS groups. The record will select the following DSS groups with Organization Party entity checked. 1. Create Contact Only 2. OCO Inquiry 3. Public Since ‘Create Contact Only’ DSS group has a higher ranking (2) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the second DSS ‘Create Contact Only’ and look at the responsibilities. Since this DSS does not have ‘OCO Organization Only’ responsibility therefore, the system will not allow the record to be created. Responsibility - Sales User Scenario I – Create Organization User creates an organization or updates an organization. The record will look at: 1. All the DSS groups which have ‘Organization Parties’ entity checked. 2. Ranking of these DSS groups. The record will select the following DSS groups with Organization Party entity checked. 1. Create Organization Only 2. OCO Inquiry 3. Public Since ‘Create Organization Only’ DSS group has a higher ranking (1) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the first DSS ‘Create Organization Only’ and look at the responsibilities. Since this DSS does not have ‘Sales User’ responsibility therefore, the system will not allow the record to be created. Scenario II – Create Person / Contact Party If the user tries to create or update a contact (including contact points etc) using this responsibility then the record will look at: 1. All the DSS groups which have the following entity checked. a. Person parties b. Relationships c. Party Contact Points d. Party Site Contact Points e. Party Addresses 2. Ranking of these DSS groups. To process the person party record, the record will select the following DSS groups with ‘Person Parties’ entity checked. 1. Create Contact Only 2. OCO Inquiry 3. Public Since ‘Create Contact Only’ DSS group has a higher ranking (2) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the second DSS ‘Create Contact Only’ and look at the responsibilities. Since this DSS has ‘Sales User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the record to be created. Scenario II a – Creating Party Relationship To create a contact, the system must be able to create a ‘Relationship’. Therefore, the record will look at: 1. All the DSS groups which have ‘Relationship’ entity checked. 2. Ranking of these groups. To process ‘Relationship’, the record will select the following DSS groups with ‘Relationships’ entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the second DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS has ‘Sales User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the relationship record to be created. Scenario II b – Creating Contact Points To create a contact, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entity checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process ‘Contact Points’, the record will select the following DSS groups with 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the second DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS has ‘Sales User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the relationship record to be created. Responsibility - OCO User Scenario I – Create Organization User creates an organization or updates an organization. The record will look at: 1. All the DSS groups which have ‘Organization Parties’ entity checked. 2. Ranking of these DSS groups. The record will select the following DSS groups with Organization Party entity checked. 1. Create Organization Only 2. OCO Inquiry 3. Public Since ‘Create Organization Only’ DSS group has a higher ranking (1) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the first DSS ‘Create Organization Only’ and then look at the responsibilities. Since this DSS has ‘OCO User’ responsibility and the ‘Create’, ‘Update’, and ‘Delete’ boxes are checked therefore, the system will allow the record to be created. Scenario I a – Creating Contact Points To create an organization, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entity checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process address and contact points, the record will select the following DSS groups with above 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS has ‘OCO User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow address and contact points record to be created. Scenario II – Create Person / Contact Party If the user tries to create / update a contact (including contact points etc) using this responsibility then the record will look at: 1. All the DSS groups which have the following entity checked. a. Person parties 2. Ranking of these DSS groups. To process the person party record, the record will select the following DSS groups with ‘Person Parties’ entity checked. 1. Create Contact Only 2. OCO Inquiry 3. Public Since ‘Create Contact Only’ DSS group has a higher ranking (2) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the second DSS ‘Create Contact Only’ and look at the responsibilities. Since this DSS has ‘OCO User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the person record to be created. Scenario II a – Creating Party Relationship To create a contact, the system must be able to create a ‘Relationship’. Therefore, the record will look at: 1. All the DSS groups which have ‘Relationship’ entity checked. 2. Ranking of these groups. To process ‘Relationship’, the record will select the following DSS groups with ‘Relationships’ entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS has ‘OCO User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the relationship record to be created. Scenario II b – Creating Contact Points To create a contact, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entity checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process ‘Contact Points’, the record will select the following DSS groups with 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this group has ‘OCO User’ responsibility and ‘Create’, ‘Update’, and ‘Delete’ boxes are checked, therefore, the system will allow the relationship record to be created. Responsibility - OCO Inquiry Scenario I – Create Organization User creates an organization or updates an organization. The record will look at: 1. All the DSS groups which have ‘Organization Parties’ entity checked. 2. Ranking of these DSS groups. The record will select the following DSS groups with Organization Party entity checked. 1. Create Organization Only 2. OCO Inquiry 3. Public Since ‘Create Organization Only’ DSS group has a higher ranking (1) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will first select the first DSS ‘Create Organization Only’ and then look at the responsibilities. Since this group does not have ‘OCO Inquiry’ responsibility therefore, the record will move to the next DSS ‘OCO Inquiry’. This DSS ‘OCO Inquiry’ also does not has ‘OCO Inquiry’ responsibility therefore the system will not allow creation of Organization record. Scenario I a – Creating Contact Points To create an organization, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entity checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process address and contact points, the record will select the following DSS groups with above 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS does not have ‘OCO Inquiry’ responsibility, therefore, the system will not allow address and contact points record to be created. Scenario II – Create Person / Contact Party If the user tries to create / update a person record using this responsibility then the record will look at: 1. All the DSS groups which have the following entity checked. a. Person parties 2. Ranking of these DSS groups. To process the person party record, the record will select the following DSS groups with ‘Person Parties’ entity checked. 1. Create Contact Only 2. OCO Inquiry 3. Public Since ‘Create Contact Only’ DSS group has a higher ranking (2) as compared to ‘OCO Inquiry’ (3) and ‘Public’ (5). Therefore, the record will select the second DSS ‘Create Contact Only’ and look at the responsibilities. Since this DSS does not have ‘OCO Inquiry’ responsibility therefore, the system will not allow the person record to be created. Scenario II a – Creating Relationship If the user tries to create any party relationship (organization to organization or organization to person) the record will look at: 1. All the DSS groups which have ‘Relationship’ entity checked. 2. Ranking of these groups. To process ‘Relationship’, the record will select the following DSS groups with ‘Relationships’ entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS does not have ‘OCO Inquiry’ responsibility, therefore, the system will not allow the relationship record to be created. Scenario II b – Creating Contact Points To create a contact or an organization, the system must be able to create a ‘Party Address’ and optionally ‘Contact Points’. Therefore, the record will look at: 1. All the DSS groups which have the following entities checked. a. Party Contact Points b. Party Site Contact Points c. Party Addresses 2. Ranking of these groups. To process ‘Contact Points’, the record will select the following DSS groups with 1a, 1b, 1c entity checked. 1. OCO Inquiry 2. Public Since ‘OCO Inquiry’ DSS group has a higher ranking (3) as compared to ‘Public’ (5). Therefore, the record will select the third DSS ‘OCO Inquiry’ and then look at the responsibilities. Since this DSS does not have ‘OCO Inquiry’ responsibility, therefore, the system will not allow the relationship record to be created. Note: If a user has responsibility ‘A’, that has privileges to create, update, or delete entities, and responsibility ‘B’ that does not have such privileges then, responsibility ‘A’ will take precedence over responsibility ‘B’ and the user will be allowed to create, update, or delete entities. Therefore, users should not be assigned such responsibilities with contradicting privilege assignments. Limitations of Data Sharing and Security Model 1. No Account Level Protection: OCO introduced the much desired functionality of account level access in 11.5.10 release. But OCO does not have any data security through DSS. Implementing organizations will have to use OA Framework personalization to secure data. For example, if the requirement is that users with ‘Sales User’ responsibility should not be allowed to create account level contact then the only way fulfill this requirement is through removing the ‘Create Contact’ button in the ‘Account Overview’ page through OA Framework personalization. 2. Complete Visibility of All Data: Users can be given create, update and delete privileges through DSS but DSS cannot hide the data from a user. In other words, a user will always be able to see all the data even he / she may not have any privileges to create, update and delete. For example, system administrators will not be able to hide a party of ‘GSA’ classification from certain users. 3. Only Row Level Protection: As mentioned earlier in this paper, DSS can give create, update and delete privileges to the entire row in the table and not to a certain columns for that row.

Oracle eCommerce Gateway Overview

The Oracle Gateway resides between the Oracle Applications and the EDI Translator. The Gateway processes data between Oracle Applications and the EDI Translator using ASCII interface flat files. The EDI Translator accommodates the standards and all the monitoring of transmitting standard formatted data between Trading Partners. For outbound data, the EDI Translator maps data from the Oracle interface flat files to any standards of choice. For inbound data, the EDI Translator maps data from the standards of choice to the Oracle interface flat file. The format and content of this flat file can be easily adjusted using the open interface definition table within the Oracle Gateway, though any changes that are made should also be implemented within the EDI Translator set-up. The Gateway processes data via an interface file which is received from or sent to the EDI Translator. The Gateway is independent of all standard formats since only the business data is found in the Oracle Gateway defined interface files. Additionally, the Oracle Gateway provides general code conversion functions for data such as Unit of Measure, Shipping Codes, Payment Terms, and determines the Trading Partner EDI validation/authorization between the Oracle application and the EDI Translator. Inbound Transactions For inbound transactions Oracle Gateway populates the Application Open Interfaces within the Oracle Application products. All of the necessary application logic to validate and load data is provided by the Application Programming Interface code (APIs), i.e. not by the Gateway. The Gateway only populates the relevant Application Open Interface tables recognized by the APIs for the specific EDI message/transaction. Process Flow The Oracle Gateway performs the following functions during an inbound transaction process after it receives an interface file from the EDI Translator or other process: • Gets Trading Partner validation processing parameters • Applies code conversions (if set up and activated). • Loads valid data into the appropriate Oracle Application Open Interface tables for the transaction. • e-Commerce Gateway captures transaction data exceptions. These exceptions can be reviewed on-line from the staging tables to examine the exception condition. The correction action is performed in a trading partner set up or other application set up. The transaction can then be revalidated. Outbound Transactions For outbound transactions, the Gateway extracts the data from the base Application tables. Also, it may optionally extract data from other files/tables using the built-in extensible architecture using ‘Extension’ tables. The use of Extension tables requires customization of standard code packages provided with the Oracle Gateway if the user has need of this function. Process Flow The Oracle Gateway outbound transaction process creates interface data files to support any EDI Standard that is available from the EDI Translator. The Oracle Gateway collects all of the business data needed to map to a standard EDI transaction/message which the receiving Trading Partner can interpret properly into their receiving application using their equivalent of the Gateway/EDI Translator set up. The Oracle Gateway does the following: • Gets Trading Partner processing parameters, e.g. location codes, allowable/enabled EDI transactions/messages, etc., • Extracts data from the Oracle base applications tables relevant to the EDI transaction/message being processed. • Optionally, retrieves data from customer defined extension tables (requires some customization). • Applies code conversions (when set up and activated). • Populates Oracle Gateway interface tables with all the data gathered. • Sets the data extract flags in the base Oracle Application table to prevent subsequent extraction. • Produces an interface data file for use by the EDI Translator. Note The Oracle Gateway does not have communication software to transmit the standard formatted data between Trading Partners. The Oracle Gateway relies on the EDI Translator being connected to third party communication service providers to transmit data to, or receive data from, Trading Partners after the data is mapped to the desired standard format.

Integrating Oracle 11i with SSO

Setup Oracle Single Sign-On System ( iAS 10g, OID, SSO Server etc.,) It is required to install and configure Oracle Single Sign-On system as per the metalink note: 233436.1 (Installing Oracle Application Server 10g with Oracle E-business suite R11i). Following are the components which are essential in this process: · Oracle Applications Server 10g (10.1.2.0.2) · Oracle Single Sign-on (10.1.2.0.2) · Oracle Internet Directory (10.1.2.0.2) Detailed instructions are provided in the above mentioned metalink note. Integrate Oracle SSO Server with Oracle 11i Applications By default Oracle Applications is not single sign-on enabled. To make it enabled, there is a series of tasks to be done as mentioned in the metalink note: 233436.1. As pre-install tasks, one needs to install DBMS_LDAP on E-business suite if it is not done already. Detailed instructions are given in the note. It is also required to register Oracle 11i Applications as the partner application to SSO as per the instructions given. Once SSO is enabled for Oracle 11i Applications, SSO server takes care of the user authentication process instead of Oracle Apps FND USER local login. One can verify if SSO integration is done correctly or not by accessing the following URL to sign into applications. http://[host]:[port]/oa_servlets/AppsLogin Here [host] and [port] reflect the correct values for your environment. Integrate Oracle SSO Server with Oracle 11i Applications It is essential to register any custom applications and Oracle Applications as partner applications with SSO server to enable single sign-on. Guidelines for registering the Oracle Apps as partner application is described in the metalink note: 233436.1. Also, one needs to register custom applications as partner applications to make them SSO enabled by Oracle SSO server. SSO Server Admin guide has more details to achieve the same in Chapter 4 (Configuring and Administering Partner Applications). In OracleAS release 10.1.2, one use mod_osso, an authentication module on the Oracle HTTP Server, to enable applications for single sign-on. mod_osso is a simple alternative to the single sign-on SDK, used in earlier releases to integrate partner applications. mod_osso simplifies the authentication process by serving as the sole partner application to the single sign-on server. By doing so, it renders authentication transparent for OracleAS applications. mod_osso interoperates only with the Oracle HTTP listener. You can use OracleAS SSO Plug-in to protect applications that work with third-party listeners such as Sun One and IIS. Migrate Customer Master File to TCA/FND Customer Master Current customer data resides in the custom table structures. The same needs to be migrated to Oracle Applications TCA/FND schemas to enable the 11i Applications access for the customers. Following table maps the column names between OID, FND_USER, TCA tables. From OID to Oracle E-business suite (FND/TCA) From Oracle E-business suite (FND_USER) to OID Create OID Customer Directory Following is the process to create the accounts for those who have access to Oracle applications. An Oracle E-Business Suite administrator can use AppsUserExport to export a selected set of application accounts from the Oracle E-Business Suite Release 11i native user directory (FND_USER) into an intermediate LDIF file. An Oracle Internet Directory administrator then uses the Oracle Internet Directory ldifmigrator utility to convert this intermediate LDIF file into a final LDIF file, based on Oracle Internet Directory deployment choices. The Oracle Internet Directory administrator then loads the final LDIF file into Oracle Internet Directory. Following is the process to create the OID customer data for those customers who would access only the custom applications but still require single sign on. Task 1: Create an Intermediate Template File Applications generating data in national languages must store that data in AL32UTF8 in the intermediate template file as specified in the IETF RFC 2849, "The LDAP Data Interchange Format (LDIF) – Technical Specification" available at http://www.ietf.org. dn: cn=jdoe, %s_UserContainerDN% sn: Doe %s_UserNicknameAttribute%: jdoe objectClass: inetOrgPerson objectClass: orclUserV2 title: Member of Technical Staff homePhone: 415-584-5670 homePostalAddress: 234 Lez Drive$ Redwood City$ CA$ 94402 Task 2: Run the OID Migration Tool Once you have set up the intermediate template file, the OID Migration Tool enables you to bring all pertinent data from the application-specific repository into Oracle Internet Directory. Once the data is migrated, one can update whatever portion of it is relevant to the application by synchronizing that application with Oracle Internet Directory. You synchronize by using the Oracle Directory Synchronization Service. More details can be found in the Chapter 23 – Migration of Data from Other Directories in OID Admin Guide 10g R2. Setup Sync process for OID and TCA/FND Customer Directory After the Oracle Single Sign-On integration is complete, user information exists in two places: Oracle Internet Directory and Oracle E-Business Suite Release 11i: · A GUID uniquely identifies a user across multiple systems. · Both Oracle Internet Directory and Oracle E-Business Suite store GUID information for each single sign-on user. · During the authentication handshake between Oracle Internet Directory and Oracle E-Business Suite Release 11i, Oracle Single Sign-On passes the authenticated user information in the form of GUID to Oracle E-Business Suite, which then uses the GUID to locate the corresponding application account. · Once a GUID is generated and stored in both a single sign-on account in Oracle Internet Directory and an application account in Oracle E-Business Suite Release 11i, the two accounts are said to be linked. User provisioning between Oracle E-Business Suite Release 11i and Oracle Internet Directory · New users created on either system can be provisioned into the other via the provisioning process. The provisioning system consists of components of both Oracle Internet Directory and Oracle E-Business Suite Release 11i that queue user events on each system, plus an Oracle Internet Directory process that periodically pushes or pulls these events to or from Oracle E-Business Suite Release 11i. · The provisioning process establishes the GUID link for provisioned accounts. During this process, single sign-on accounts are automatically linked to Oracle E-Business Suite Release 11i application accounts. · Once linked, user changes from either system can be provisioned into the other. · The provisioning process between Oracle Internet Directory and each Oracle E-Business Suite instance is determined by a provisioning profile. · The provisioning profile controls which user events are provisioned, the direction of provisioning, and the user attributes included in each event. Oracle E-Business Suite Release 11i is said to be a provisioning integrated application with Oracle Internet Directory when a provisioning profile is created for it. Strategy for user management After the initial migration, you may choose to allow new users to be created either from Oracle Internet Directory or from Oracle E-Business Suite, and then provision them into the other system. This is achieved by enabling either the SUBSCRIPTION_ADD event from Oracle Internet Directory to Oracle E-Business Suite Release 11i, or the IDENTITY_ADD event from Oracle E-Business Suite Release 11i to Oracle Internet Directory. Whether new users are created in either Oracle Internet Directory or Oracle E-Business Suite Release 11i, they must have the appropriate Applications responsibilities assigned to them, via the Applications Security forms. More details can be found in the document, Integrating Oracle E-Business Suite Release 11i with Oracle Internet Directory and Oracle Single Sign-On located in metalink.

Introduction to Oracle Single Sign-On System

Introduction Single sign-on Server (SSO) provides a mechanism that allows a number of different Applications common to an enterprise to share a user authentication service. With Oracle's enterprise-wide Single Sign-On, a user is required to log on, or authenticate once. That verification of the user identity is valid for the duration of the user session, and for every Application participating in the Single Sign-On framework. The user session ends, across every Application, when the user logs out of any partner Applications. User authentication process will be delegated to SSO and it will manage user credentials (password, digital certificate, etc.) Key Components in the Single Sign-On System OracleAS Single Sign-On interacts with the following components: 1. Single Sign-On Server 2. Partner Applications 3. External Applications 4. mod_osso 5. Oracle Internet Director 6. Oracle Identity Management Infrastructure Single Sign-On Server The single sign-on server consists of program logic in the OracleAS database, Oracle HTTP Server, and OC4J server that enables you to log in securely to applications. These applications take two forms: partner applications and external applications. In both cases, you gain access to several applications by authenticating only once. Partner Applications OracleAS applications delegate the authentication function to the single sign-on server. For this reason, they are called partner applications. An authentication module called mod_osso enables these applications to accept authenticated user information instead of a user name and password once you have logged in to the single sign-on server. A partner application is responsible for determining whether a user authenticated by OracleAS Single Sign-On is authorized to use the application. External Applications External applications do not delegate authentication to the single sign-on server. Instead, they display HTML login forms that ask for application user names and passwords. Each external application may require a unique user name and password. You can configure the single sign-on server to provide user names and passwords to external applications on users’ behalf once they have logged in to the single sign-on server. The server uses the single sign-on user name to locate and retrieve application names and passwords and to log the user in. mod_osso mod_osso is an Oracle HTTP Server module that provides authentication to OracleAS Applications. It replaces the single sign-on SDK, used in earlier releases of OracleAS Single Sign-On to integrate partner applications. Located on the application server, mod_osso simplifies the authentication process by serving as the sole partner application to the single sign-on server. In this way, mod_osso renders authentication transparent to OracleAS applications. The administrator for these applications is spared the burden of integrating them with an SDK. After authenticating a user, mod_osso transmits the simple header values that applications may use to authorize the user: · User name · User GUID · Language and territory Oracle Internet Directory Oracle Internet Directory is the repository for all single sign-on user accounts and passwords: administrative and non-administrative. The single sign-on server authenticates users against their entries in the directory. At the same time, it retrieves user attributes from the directory that enable applications to validate users. Oracle Identity Management InfrastructureOracleAS Single Sign-On is just one link in an integrated infrastructure that also includes Oracle Internet Directory, Oracle Directory Integration and Provisioning, Oracle Delegated Administration Services, and OracleAS Certificate Authority. Working together, these components, called the Oracle Identity Management infrastructure, manage the security life cycle of users and other network entities in an efficient, cost-effective way.