Oracle SSO and OID Integration with EnterpriseOne: Part III

Copyright © 2009 by Klee Associates, Inc. www.JDEtips.com

May/June 2009 On Technical/CNC

In this article, I will conclude

with the enablement of Oracle Single Sign-On with

the JD Edwards EnterpriseOne

JAS server.

Oracle® Single Sign-On for JD Edwards® EnterpriseOne®: Part III

Enabling Oracle Single Sign-On with JAS Server By Charles Anderson

Editor’s Note: Charles Anderson has presented us with the key steps of Single Sign-On, including a standalone install of an OAS Infrastructure “Home”, and the integration of Oracle Internet Directory with the Microsoft Active Directory. In this final article of the series, Charles takes us through the final steps to point a single JD Edwards EnterpriseOne JAS instance to the Oracle Single Sign-On server and validate successful logins using your Active Directory credentials. This article is the final installment of a three-part series on Oracle Single Sign-On. In Part I of our series, we walked through the process of a basic, standalone server install of an Oracle Application Server Infrastructure ―Home‖, which includes a dedicated Oracle 10g database and the Oracle Single Sign-application. In Part II, we successfully integrated Oracle Internet Directory (OID) with Microsoft Active Directory (AD). This integration included the synchronization of user accounts from AD into the OID using the Directory Integration and Provisioning (DIP) utility. We customized a DIP ―map‖ to pull AD accounts into OID and into a more user friendly form. We also enabled the External Password Authentication Plug-in for AD so that users could authenticate directly against AD Domain Controllers using their Windows password. In this article, I will conclude with the enablement of Oracle Single Sign-On with the JD Edwards EnterpriseOne JAS server. We will accomplish this with the Oracle Application Server 10g R3 platform, with EnterpriseOne Tools 8.97 and Server Manager. When I originally began the outlining process for this article, which ultimately transformed into a somewhat lengthy ―white paper‖, I was relying on my knowledge from having worked with Oracle Single Sign-On with both Oracle Portal and EnterpriseOne (running Tools Release 8.96.) My present employer had signed on to participate in the Tools 8.97 beta program, and at that time, documentation for Oracle Single Sign-On integration with 8.97 was still being prepared. Also, as Tools 8.97 was the first Tools release to support (and require) Oracle Application Server 10g R3 (10.1.3) for the Java Application Server, the steps needed to configure OAS for Oracle Single Sign-On support changed from the virtually streamlined process available with OAS 10.1.2, to a more manually intensive process with OAS 10.1.3.

Oracle Single Sign-On for JD Edwards EnterpriseOne: Part III

Copyright © 2009 by Klee Associates, Inc. www.JDEtips.com Page 2

So being the enterprising (part-time) systems administrator that I am, I created my own custom documentation and tagged it with a ―For internal use only‖ label. Basically, I hacked it together by merging multiple sources including Oracle on-line documentation and, of all things, a Hyperion installation manual. Since that time, Oracle has released a supplement to their Security Administration documentation that details some of the steps you will see in this article series. Having stated that, I trust you will find added value in this guide in addition to the ―stock‖ product documentation. For instance, at least one of the steps in the supplemental documentation is not valid for EnterpriseOne Tools 8.97, due to the advent of Server Manager. Also, in my opinion, the product documentation leaves a lot to be desired in terms of helping this previously uninitiated but budding LDAP administrator along during the process, whereas these articles provide additional screenshots, insights, etc.

Pre-Configuration Notes Prior to beginning the steps outlined in this article, you should be familiar with, and have performed, the installation and configuration of the Oracle Application Server 10.1.2 Infrastructure ―home‖, which includes OID and Oracle SSO (for more info, see Part I.) As you have learned in Parts I and II, although it is not technically required for this portion of the exercise, you can configure OID to synchronize with third-party LDAP servers such as Microsoft Active Directory (see Part II.) You should also have a supported EnterpriseOne release with Tools 8.97 or greater and EnterpriseOne HTML client hosted on Oracle Application Server 10.1.3.1. Although the Oracle product documentation mentions limited ―unidirectional‖ support for Websphere Application Server (WAS), I am focusing this guide strictly on ―Red Stack‖ components. My demonstration, including screenshots, is from a JD Edwards EnterpriseOne 8.12 installation with Tools CPU 8.97.2.5. I will make some concessions to those of you running older releases, such as EnterpriseOne 8.10 and 8.11, and provide some additional hints in an effort to help you be successful if you attempt this possible career expanding maneuver. For those of you following along on Linux or UNIX instead of Windows, you'll be fine provided that you make the necessary adjustments to the command strings. Although you may have chosen to start with a more recent version of Oracle Identity Management—10g R3 (which includes Oracle Internet Directory and Single Sign-On components)— this three-part series focuses on the Application Server 10g R2 release. Most of what you will find in this series will still apply to the newer release, although there are a few appealing features in the latest release, such as Server Chaining support, which will not be covered. Finally, before getting started, I'd like to update my recommendation of the LDAP Browser Editor tool, which was mentioned and used in Parts I and II. This was a recommendation based on convenience, not born of a technical requirement for entering into the world of integration between OID and Active Directory. It has come to my attention that since the Part II was published, the web hosting provider for the LDAP Browser/Editor has reworked their website and is no longer providing a copy of this fine utility. I've searched for other web hosts for the same utility, and for alternatives, and have come to the conclusion that Softerra LDAP Administrator is an excellent substitute (http://www.ldapbrowser.com), but it is commercial software. It is, however, available for download as a 30 day free trial. Also, note that you can simply use the tools provided with OID (Oracle Directory Manager) and Active Directory MMC snap-ins at no additional cost.

http://www.ldapbrowser.com/



Special Considerations (Password Policy and Super-User Account Unlock Procedure) Now that we've gotten the formalities out of the way, let's begin. First verify that you can login to the Oracle Internet Directory using the special super user account ―orcladmin‖. If it has been several months since your last login, you may find that your account has expired. The default OID password expiry time is quite restrictive (two months), and because a password reset grace period is not present by default for all accounts, this account lockout event is a common occurrence. This presents a problem for you, unless you had the foresight to add an account from your Active Directory account to the OID administration group. To correct this, navigate to your OID server and start a command prompt session. Next, execute the following command to unlock ―orcladmin‖, assuming your OID database name is ―orcl‖: oidpasswd connect=orcl unlock_su_acct=true You will be required to provide the password for the ―ODS‖ user, which is the same password entered during installation and the same password that the installation routine assigned to orcladmin, ias_admin, etc. Upon entering the ODS password, you will receive confirmation that the OID super user account has been activated, as shown in Figure 1.

Figure 1: Confirmation of Activation The next step you should take is to configure the default password policy for your OID realm using the Oracle Directory Manager. First, start ODM and login with the orcladmin user account that you just unlocked, as shown in Figure 2. Navigate to the ―Password Policy Management‖ System Object and specify a new value for ―Password Expiry Time‖ in seconds. As indicated in the screenshot shown in Figure 3, a value of ―0‖ indicates no expiry time for the accounts contained within OID; you can also choose to disable the OID password policy entirely.

Figure 2: Oracle Directory Manager Connect



Figure 4: Error Message

Figure 3: Setting Password Expiry Time to Not Expire No recommendation is made or implied here, so please refer to your internal security policies if applicable. You may instead choose to set, among other options, the expiry time to a value of 31556926 to indicate ―1 year‖ and set the ―Reset password upon next login‖ and ―Need to Supply Old Password when Modifying Password‖ values to ―Enable‖ from their default value of ―Disable‖. This does not impact the password policy of your Active Directory domain in any way, so passwords will still expire and present the user with a prompt to reset based on the existing Microsoft policy. The OID Password Expiry Time will affect only those accounts whose password is actually stored in the OID. (Remember, the AD integration we configured in Part II utilizes the External Password Authentication plug-in.)

Oracle SSO Configuration for JD Edwards EnterpriseOne Let’s begin the configuration of Oracle Single Sign-On for the EnterpriseOne HTML client from an EnterpriseOne administration ―fat client‖. Although some LDAP configuration can be performed from the HTML client with EnterpriseOne releases starting with 8.11, for SSO node configuration we'll need to use the fat client. Attempts to run P986115 from the HTML client will result in the message shown in Figure 4.



From the EnterpriseOne Security Maintenance Advanced and Technical Operations Task View on the administration workstation (Fast Path JDE029147), select ―SSO Environment Configuration Tools‖ (see Figure 5). Select "Single Signon Node Configuration", as shown in Figure 6.

Figure 5: Select SSO Environment Configuration Tools



Figure 6: Select Single Signon Node Configuration



Click the ―Add‖ button to begin adding our nodes, as shown in Figure 7. We'll add two nodes, one for the EnterpriseOne Enterprise or dedicated Security Server and another for the web (OAS) server; then we'll

configure them to trust each other. The end result should look something like what’s shown in Figure 8.

In my example, my Enterprise server is ―ENTLAB‖ and my OAS server is ―JDEWEB‖. JDEWEB is actually an alias in DNS for host ―OASLAB‖, but this shows that the Node and Machine Name parameters are not actually tied to an actual machine or host name. It is the shared configuration between the EnterpriseOne tables (F9861680 - Node Configuration Table, F986181 - Node Lifetime Configuration Table , F986182 - Trusted Node Configuration Table), and the OAS servers TokenGen.ini. If running EnterpriseOne 8.9 (no longer supported) or 8.10 (soon to be no longer supported), you must add the configuration to the JDE.INI on the EnterpriseOne Enterprise or dedicated security server. Here, we've added the trusted node ―JDEWEB‖ with the same alias for the Machine Name (any description will do), activated the record, and defined a secure password. I'm tossing good security out the window in my examples and will just use ―abc123‖ for the password. See Figure 9.

Figure 7: Adding Nodes

Figure 8: Added Nodes



Again, be sure to activate the nodes, and set and verify the node password. Record this password as it will be shared with the Enterprise/Security server JDE.INI (for EnterpriseOne 8.9 or 8.10) and the TokenGen.ini on the OAS server (for EnterpriseOne 8.10.) Back at the main SSO Environment Configuration Tools screen, select the next option (third in the list) ―Single Signon Token Lifetime Configuration‖. The end result should look something like what is shown in Figure 10. In Figure 10, we've added a Regular and Extended lifetime ―Token‖ with maximum values for each (defined in seconds). Our last step in the SSO Environment Configuration Tools application is to select the fourth option and define the Trusted Node Configuration.

Figure 9: Adding Node JDEWEB

Figure 10: Single Signon Token Lifetime Configuration



You can type in the name of the trusted node, or select it from the list of available nodes using the visual assist. The nodes must have been defined already using the Single Signon Node Configuration (form W986115P). See Figure 11. We'll set them up to trust each other as shown below; your configuration should look something like what’s shown in Figure 12, depending on your chosen host or alias names for the Enterprise and OAS servers.

Now that we've accomplished all that we need to from within the EnterpriseOne administration client, we can close that for now and move on to the OAS server configuration. Let's go ahead and populate the TokenGen.ini on the OAS server with the required parameters. We'll need to grab a copy from the administration workstation or the Deployment Server, as the TokenGen.ini is not automatically copied to the OAS server, even as of Tools 8.97.2.5. I understand that is considered a bug and is fixed in a later release of Tools 8.98, and I presume it will make its way back to an incremental release of 8.97. You can find a sample copy of the TokenGen.ini in the System\Generator directory on your Deployment Server or administration workstation (see Figure 13). Be sure to add the trusted NodeName and Node Password (NodePwd) parameters to the file after copying it

Figure 11: Trusted Node Name

Figure 12: Node Configuration Outcome

Figure 13: TokenGen.ini.file



For those of you with 8.9 or 8.10 "at home", there is an additional step. You'll need to ensure the JD Edwards EnterpriseOne Enterprise or dedicated EnterpriseOne Security Server is configured to support Oracle SSO. The [TRUSTED NODE] stanza is populated with the number of trusted nodes, Token lifetimes (both "regular" and "extended"), the Node and Machine names, and Node passwords as defined in the EnterpriseOne Security Single Sign-On Node Configuration application. The following shows the [TRUSTED NODE] configuration view from within Tools 8.97 Server Manager. Note the highlighted section, which indicates that 8.11 and beyond will ignore the Trusted Node configuration in the JDE.INI on the Enterprise Server and default to the configuration stored in the EnterpriseOne tables in the database:

Here is the view from within the actual file (for those of you still on Tools 8.96 or those who prefer to edit these files manually as opposed to using EnterpriseOne Server Manager. If you do not have a [TRUSTED NODE] stanza, be sure to add it!

over to your OAS server. It’s usually not a good idea to store the trusted node password in the copy you keep on the Deployment Server, unless you have good security (filesystem) policies in place and account for these types of additions on a routine and faithful basis. Now, the Oracle product documentation states that this TokenGen.ini file should be placed in the ORACLE_HOME/ j2ee/blah/ blah/blah directory. This was good for Tools 8.96, when there was no Server Manager. With the advent of Server Manager with Tools 8.97, the JAS configuration files are no longer read from that location and instead are located in a config directory off of the root on which you installed the Server Manager client agent. For instance, on the OAS lab server for this demonstration, the Server Manager client agent has a home directory of E:\JDE_HOME with a target of ―JDE1‖ for the OAS server. Within that subdirectory is another subdirectory, ―config‖, which stores the jas.ini, jdbj.ini, and tnsnames.ora (even if running RDBMS other than Oracle); this is where you will place the TokenGen.ini and customize with node and password parameters (see Figure 14).



If your shop has many, or even as few as only two,

Oracle SSO capable

applications (this includes Oracle

Portal), supported by a shared Oracle SSO server, once

you log in to one of them, you're “pre-authenticated” to the rest of them,

provided you keep the first browser session open the

entire time.

To provide support for Oracle SSO within EnterpriseOne, or, for that matter, any other Oracle SSO capable application, we must configure ―mod_osso‖. This is a custom HTTP authentication module for Oracle HTTP Server that provides the Oracle SSO support and enables the redirect from EnterpriseOne to the Oracle SSO server for the authentication process. This then redirects the user back to EnterpriseOne with the proper credentials. If your shop has many, or even as few as only two, Oracle SSO capable applications (this includes Oracle Portal), supported by a shared Oracle SSO server, once you log in to one of them, you're ―pre-authenticated‖ to the rest of them, provided you keep the first browser session open the entire time. It is a persistent cookie that crosses both browser windows and tabs, and works with not just Internet Explorer but also Firefox (the two supported EnterpriseOne browsers) and others. Now that we have the table additions made and files edited and copied into the proper location, it is time to register the OAS instance with the Oracle SSO server. Note that many of these steps can be configured out of sequence, but they must all come together to form the foundation of support for Oracle SSO with EnterpriseOne. The first step in registering the OAS server that hosts the JD Edwards EnterpriseOne JAS instance is to log in to the OID/SSO server (or the SSO server, if you've split the roles across servers in your environment). From there, drop to a command line and if necessary, change to the drive letter where the Oracle Home hosting Oracle SSO is located (in my example, C:), then change to the directory %ORACLE_HOME%\sso\bin.

Figure 14: E:\JDE_HOME\targets\JDE1\config



Note: If ORACLE_HOME is not defined as an environment variable, you'll need to specify the full path to this directory, and then you can execute the following command (see Figure 15): ssoreg -config_mod_osso TRUE -site_name JDEWEB -remote_midtier -config_file %ORACLE_HOME%\Apache\Apache\conf\osso\jdeweb.conf -mod_osso_url http://jdeweb.home.local

Of course you will need to substitute ―JDEWEB‖ with your chosen site name (it can be anything, really, within reason), the path to and name of the OSSO config file (jdeweb.conf in my example), and of course the URL you are ―protecting‖ behind Oracle SSO. The Oracle product documentation might tell you to use ―osso.conf‖, but in my experience, I've had better luck using a unique name for the config file. We'll reference that filename later on in the osso.conf, which is located on the OAS server (once it has been copied over from the SSO server). Figure 16 is an example of a successful SSO registration.

Figure 16: Successful SSO Registration

Figure 15: Command Prompt to Change Directory



Next we'll look into the %ORACLE_HOME%\Apache\Apache\conf\osso directory to find the OSSO config file we specified as a parameter in the SSO registration command, as shown in Figure 17.

Then, we can copy it from the SSO server over to the OAS server that hosts our JD Edwards EnterpriseOne JAS instance (see Figure 18). For Windows installations, we can simply drag and drop the file using the Windows Explorer UNC method. For Linux and UNIX installations, be careful to transfer the file using binary mode if using FTP. This is, of course, not a concern with CIFS or NFS mounted directories.

Figure 17: Finding the OSSO Config File Specified as a Parameter in the SSO Registration

Figure 18: Copying from SSO Server to OAS Server



Log out of, or lock, the session on the OID/SSO or separate Oracle SSO server and log in to the OAS 10.1.3.1 server hosting your EnterpriseOne JAS instance. Before moving forward, I would recommend setting the ORACLE_HOME environment variable and then checking to make sure the variable is ―set‖ as illustrated in the Figure 19.

Also, it is possible to run the next step in one of two ways, but I will show you how to execute the commands using the Perl method. The other method, manually editing each file, is obviously more labor intensive, and this is why the Perl script was written – it automates this process for us. Check to make sure that the ―perl‖ executable is in the path as shown in Figure 20.

Figure 19: Verifying the ORACLE_HOME Environment Variable is “Set”



Figure 20: Verify the “perl” Executable Is in the Path Now we can execute the following command: perl %ORACLE_HOME%\Apache\Apache\bin\osso1013 e:\install\osso\jdeweb.conf (where osso1013 is the actual Perl script and e:\install\osso\jdeweb.conf is the full path to the staged copy of jdeweb.conf, which was copied over from the Oracle SSO server—see Figure 21).

Figure 21: Command Prompt Execute

Figure 22 illustrates a successful completion of the osso1013 script; we can next verify that the staged copy of ―jdeweb.conf‖ has been copied to the proper location and is referenced in the Oracle SSO configuration file on our JAS server.



Figure 22: Successful Completion of osso1013 Script As you can see, the osso1013 script we called with Perl updated the mod_osso.conf file with a reference to osso.conf, and placed the osso.conf file in the proper location on the JAS server. See Figure 23.

Figure 23: osso.conf File in the Proper Location on the JAS Server



The osso1013 script also updated the httpd.conf file and made sure that mod_osso.conf is included when the Oracle HTTP Server starts up (see Figure 24).

We're not done yet, though. We must still configure the JAS instance to use Oracle SSO for authentication rather than its own application security. The default JAS configuration defaults to internal JD Edwards EnterpriseOne Security. This means that all login requests are handled by code contained within the JAS server instance, and configurable options within the JAS.INI, which point the JAS server to an EnterpriseOne Security Server for authentication. By changing the JAS instance to use Oracle SSO for authentication, we're instructing the JAS server to redirect the user to the Oracle SSO server for authentication, while still maintaining full JD Edwards application security as configured in the EnterpriseOne Security Workbench application.

In EnterpriseOne Server Manager, select the correct JAS instance and locate the Security Server Configuration options. Select ―Enable Oracle Single Sign-On‖ and specify a URL for the Oracle SSO Single Sign-Off URL. See Figure 25.

Figure 24: osso1013 Script Updated the httpd.conf File



Figure 25: Enable Oracle Single Sing-On and Specify URL Once enabled, you can restart your JAS instance and navigate to the same URL you've used previously. Instead of the standard JD Edwards EnterpriseOne HTML login screen, you should now see something similar to what’s shown in Figure 26. Once Oracle SSO has authenticated the user (in this case, JDE), the user is redirected back to JD Edwards EnterpriseOne, which then accepts the authentication from Oracle SSO and presents the application, as shown in Figure 27.

Figure 26: Single Sign-On Sign In



Figure 27: JD Edwards EnterpriseOne Menu

Conclusion Presuming you have followed me through each of the articles in this three-part series, you have now been exposed to what goes on behind the scenes with JD Edwards EnterpriseOne when deploying an alternative authentication mechanism. We walked through the initial stages of the Oracle Infrastructure home installation (including both Oracle Single Sign-On and Oracle Internet Directory, among other installable components). We established and customized the integration between Oracle Internet Directory and a third-party directory server, Microsoft's Active Directory, and configured a scheduled ―one way‖ synchronization of accounts from Active Directory to the Oracle Internet Directory. We then enabled the external password authentication plug-in so that users can login to Oracle Single Sign-On using their existing Windows username and password. To cap it off, we pointed a single JD Edwards EnterpriseOne JAS instance to the Oracle Single Sign-On server and validated successful logins using our Active Directory credentials. Oracle Single Sign-On is a complementary product and does not take the place of JD Edwards EnterpriseOne application security as administered through Security Workbench; it does not



Oracle Single Sign-On and Oracle

Internet Directory have provided my

customers with years of rock solid

and dependable service.

facilitate the setup of new user profiles, system users, etc. It is meant as a way to provide secure access to various Oracle application suites while providing the end user with a relatively seamless single sign-on experience. Although part of the Oracle Technology Foundation for JD Edwards EnterpriseOne, Oracle SSO is now considered a ―legacy‖ solution by the Oracle sales channel. I interpret this as a way of saying that Oracle SSO, bundled as part of Oracle Identity Management, Oracle Application Server Enterprise Edition, Oracle Technology Foundation, etc., is an Oracle solution tailored for Oracle applications and as such does not help them penetrate in other application spaces. Talk to them about a Single Sign-On solution and you may be presented with a bevy of options including Oracle Access Manager, Oracle Identity Federation, and the Oracle Enterprise Single Sign-On Suite. Each of these solutions have some product overlap, while serving specific targeted usage. Oracle Single Sign-On (along with Oracle Internet Directory) is a proven solution for use with many Oracle applications including, but not limited to, JD Edwards EnterpriseOne, Oracle BI Enterprise Edition, and Oracle Portal (which currently requires Oracle Single Sign-On.) At the time of this writing, Oracle Fusion Middleware 11g has not yet been released. It remains to be seen which features will ship with this product, and it is rumored that Oracle Single Sign-On will not be a part of the new Application Server suite. It will continue to be supported as part of the Oracle Application Server 10g product, however, and is still on the table as a supported solution with EnterpriseOne and Oracle Portal. Therefore, do your research, and then discuss the solution internally and with your various Oracle sales representatives before making the decision to implement in your environment. Having said that, Oracle Single Sign-On and Oracle Internet Directory have provided my customers with years of rock solid and dependable service. I firmly believe that while there are other competing solutions on the market, the value proposition of Oracle SSO, especially when utilized with other Oracle applications such as Oracle Portal, Oracle BI Enterprise Edition and Hyperion, is tough to beat.

Charles Anderson, Application Support Manager, Forestar Real Estate Group, Inc. has over 13 years worth of combined experience in both disciplines: Information Systems and Information Technology. Charles recently accepted the Oracle Excellence Award on behalf of Forestar and its former parent company, Temple-Inland, for a creative deployment of JD Edwards EnterpriseOne on the Oracle Fusion Middleware platform. Prior to joining Forestar, Charles spent six years in the IT department of a Fortune 500 manufacturing company where he spent almost five of those six years as a JD Edwards EnterpriseOne System Administrator, CNC, and later as the CNC Team Lead. Charles has real world experience supporting Oracle Fusion Middleware for a custom Oracle Portal implementation as well as the JD Edwards EnterpriseOne, Hyperion, and Oracle BI Enterprise Edition suites. Charles has attained Systems and Network Administrator certifications in both HP and Sun flavors of UNIX, Cisco Networking, and Citrix Presentation Server technologies. He is a reformed former MCSE who loves all things ―Open and Standard‖, but yet still manages to believe himself to be technology agnostic. You may contact the author at [email protected]. Be sure to mention the author’s name and/or the article title.

mailto:[email protected]



Be sure to visit our JDEtips Web site to check out the latest news, services, and offers!

License Information: The use of JDE is granted to Klee Associates, Inc. by permission from J.D. Edwards World Source Company. The information on this website and in our publications is the copyrighted work of Klee Associates, Inc. and is owned by Klee Associates, Inc. NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc. reserves the right to make changes without prior notice. NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by J.D. Edwards & Company. J.D. Edwards software referenced on this site is furnished under license agreements between J.D. Edwards & Company and their customers and can be used only within the terms of such agreements. J.D. Edwards is a registered trademark of J.D. Edwards & Company. JDE and OneWorld are registered trademarks of J.D. Edwards World Source Company. WorldSoftware is a trademark of J.D. Edwards World Source Company. PeopleSoft,the PeopleSoft logo, PeopleTools, PS/inVision, PeopleCode, PeopleBooks, PeopleTalk, and Pure Internet Architecture are registered trademarks, and Intelligent Context Manager and The Real-Time Enterprise are trademarks of PeopleSoft, Inc. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Klee Associates, Inc. is not affiliated with or endorsed by Oracle Corporation.

http://www.jdetips.com/

http://www.jdetips.com/

Documents

Oracle SSO and OID Integration with EnterpriseOne: Part III