1 / 35

LLNL Implementation Overview

LLNL Implementation Overview. DOE/NNSA laboratory Managed by the University of California since 1952 Unique world class research capabilities Nuclear science Lasers & electro-optics Supercomputing Bioscience & healthcare Energy & environment Employees: 8000 30%-40% PHDs & Masters

ursa-deleon
Download Presentation

LLNL Implementation Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LLNL Implementation Overview

  2. DOE/NNSA laboratory • Managed by the University of California since 1952 • Unique world class research capabilities • Nuclear science • Lasers & electro-optics • Supercomputing • Bioscience & healthcare • Energy & environment • Employees: 8000 • 30%-40% PHDs & Masters • Annual operating and capital funds: $1.3B/yr

  3. The Laboratory’s programmatic evolution

  4. LLNL is organized into 12 Programs/Directorates Director Deputy DirectorScience & Technology Laboratory Executive Officer Deputy DirectorStrategic Operations CIO Chief Financial Officer Nonproliferation,Arms Control, &International Security Defense & Nuclear Technologies National Ignition Facility Programs Biology &Biotechnology Research Physics & AdvancedTechnologies Energy & Environment Chemistry &Materials Science Engineering Computation Safety, Security, & Environmental Protection Administration Laboratory Services

  5. LLNL IT strategic directions • Engage and support communities-of-practice • Improve integration internally across Directorates, with the NNSA complex, and with external partners • Presentation (eWorkplace, portal frameworks) • End-to-end process automation • Application integration (SOA, EAI) • Information integration (data, documents, web content) • Centralized authentication and authorization • Java • Availability, scalability, maintainability, performance • Currently N tier/N+1, future utility/grid computing

  6. OAS 10g Oracle SSO: A “Fan-Out” Configuration Overview for Decentralized Implementation Presented By: Tony Macedo "This work was performed under the auspices of the U.S. Department of Energy by Lawrence Livermore National Laboratory under contract no. W-7405-Eng-48" or "This work was performed under the auspices of the U.S. DOE by LLNL under contract no.W-7405-Eng-48."

  7. Agenda • Business Problem Definition • “Fan-Out” Configuration Definition • “Fan-Out” Componentry • Centralized v. “Fan-Out” SSO Models • “Fan-Out” SSO Design Benefits • “Fan-Out” SSO Implementation Options • LLNL Implementation Overview • Implementation Details • Lessons Learned

  8. Business Problem Definition • Business Problems: • How can you implement a centralized Single Sign-on (SSO) scheme when your IT organizations are structured in a highly decentralized manner? • How can you provide infrastructure management autonomy while supporting a centralized SSO scheme?

  9. “Fan-Out” Configuration Definition • Definition: • A “Fan-Out” SSO configuration is a particular scheme for implementing OAS 10g Infrastructure instance installations. This configuration scheme supports the following: • Central repository of user information • Automatic replication to “Fan-Out” instances • Centralized or decentralized SSO, DAS and Repository Services implementations

  10. “Fan-Out” Componentry • Infrastructure Instance(s) • Single Sign-on (SSO via MOD_OSSO as a Partner Application) • Delegated Administration Services (DAS) • Oracle Internet Directory (OID - including OIDMON, OIDLDAPD, and OIDREPLD) • Metadata Repository (OASDB)

  11. Centralized Centrally managed set of OID, SSO, DAS, and Metadata Repository services All centralized & decentralized OAS application server instances install into the Central/Master Infrastructure Repository Authentication & Authorization are centrally managed Centralized SSO administrator(s) must coordinate maintenance activities with the Decentralized OAS application server administrators Repository and OID maintenance must be conducted by centralized SSO, OID and Repository administrators when required by decentralized application server administrators Fan-out Decentralized set of OID, SSO, DAS, and Metadata Repository services that are coupled to a Master via LDAP replication Decentralized OAS application server instances install into a “local” Infrastructure Repository Authentication & Authorization can be centrally or de-centrally managed depending upon requirements Centralized SSO administrator(s) are still required to coordinate maintenance activities with the Decentralized OAS application server administrators; but to a lesser extent than centralized “Local” repository and OID maintenance can be conducted by the “decentralized” application server administrators when required Centralized v. “Fan-Out” SSO Models

  12. Centralized SSO

  13. “Fan-Out” SSO

  14. “Fan-Out” SSO Design Benefits • Provides autonomous application server and metadata repository management capabilities to decentralized application server administrators (upgrades, local directory pruning, application server instance installations) • Allows for centralized or decentralized SSO and Delegated Administration Service (DAS) configurations • Provides a failure recovery configuration to help guard against the central failure point (NOTE: Requires partner application re-registration)

  15. “Fan-Out” SSO Design Benefits (#2) • Provides bi-directional password management to ensure locally managed accounts update the Central/Master repository • Enables decentralized authorization and Resource Access Descriptor (RAD) management • Enables geographically separated entities to maintain a central authentication and authorization scheme that can be implemented in a decentralized manner (NOTE: Multi-login may be required)

  16. “Fan-Out” SSO Implementation Options • Completely Autonomous “Fan-Out” • Hybrid “Fan-Out” • Metadata Repository Services “Fan-Out”

  17. Completely Autonomous “Fan-Out” • SSO, OID, DAS, & Metadata Repository services run on “Fan-Out” infrastructure instance(s) • No centralized SSO (NOTE: multi-login) • LDAP replicate accounts from Master, and password changes back to master from “Fan-Out” DAS • Application server partner applications only registered with “Fan-Out”

  18. Completely Autonomous “Fan-Out”

  19. Completely Autonomous “Fan-Out” • PRO’s • Autonomous management of “ALL” OAS services • Automatic OID synchronization • Can help alleviate SSO performance issues associated with geographic separation • CON’s • Results in multiple logins across disparate SSO realms

  20. Hybrid “Fan-Out” • DAS, OID, & Metadata Repository services run on “Fan-Out” infrastructure instance(s) • SSO runs on Centralized/Master infrastructure instance(s) • LDAP replicate accounts from Master, and password changes back to master from “Fan-Out” DAS • Application server partner applications registered with Centralized/Master infrastructure instance(s)

  21. Hybrid “Fan-Out”

  22. Hybrid “Fan-Out” • PRO’s • Autonomous management of “MOST” OAS services • Automatic OID synchronization • Supports a true SSO without multi-login • Authorization and RAD management can be conducted in the local repository • CON’s • Centralized SSO service failures will render your decentralized application server instances useless until SSO services are restored

  23. Metadata Repository Services “Fan-Out” • OID & Metadata Repository services run on “Fan-Out” infrastructure instance(s) • SSO & DAS run on Centralized/Master infrastructure instance(s) • LDAP replicate accounts and authorization from Master (i.e. no local DAS) • Application server partner applications registered with Centralized/Master infrastructure instance(s)

  24. Metadata Repository Services “Fan-Out”

  25. Metadata Repository Services “Fan-Out” • PRO’s • Autonomous management of OAS metadata repository registry information • Automatic OID synchronization • Supports a true SSO without multi-login • CON’s • Centralized SSO service failures will render your decentralized application server instances useless until SSO services are restored • All authorization and RAD management must be conducted in the central repository

  26. LLNL Implementation Overview

  27. Implementation Details • Install Centralized/Master OAS Infrastructure instance with the “Identity Management with Metadata Repository” option • Select required options

  28. Implementation Details (#2) • Install “Fan-Out” OAS Infrastructure instance with the “Identity Management with Metadata Repository” option • De-select “ALL” options • Provide OID details of Master when prompted

  29. Implementation Details (#3) • Manually start “Fan-Out” OID after installation completes • NOTE: You should now use OPMNCTL in place of OIDCTL to manage OID processes • Use the Replication Environment Management Tool (REMTOOL) to add the “Fan-Out” node to a replication agreement with the Master node as a “Partial” replica • Make sure to specify the “Master” OID and Port • Specify “*” as the naming context if you want the entire directory replicated, or create another naming context if necessary to reduce the replication scope

  30. Implementation Details (#4) • Perform LDIF dump of Master OID using the LDIFWRITE command • Dump the “cn=oraclecontext”, “cn=oracleschemaversion”, and “cn=[DEFAULT SUBSCRIBER]” entries • NOTE: You can also utilize the “Automatic Bootstrapping” option with the orclIncludedNamingcontexts and orclExcludedNamingcontexts attributes set to alleviate the need for manual LDAP intervention, and to explicitly limit what Master directory entries are replicated to the “Fan-Out”

  31. Implementation Details (#5) • Load the “Fan-Out” OID with the Master dump using the $ORACLE_HOME/ldap/bin/bulkload.sh script and LDIF files created previously • Start the LDAP Replication daemon on the “Fan-Out” instance • Synchronize the Master and Fan-Out orclLastAppliedChangeNumber attributes • Query and apply the Master ACL’s to the Fan-Out instance using the orclEntryLevelACI attribute • Configure Password Modification Plug-in on “Fan-Out” (NOTE: only if required)

  32. Implementation Details (#6) • Install SSO and/or DAS OAS Infrastructure instance with the “Identity Management” option • Select SSO and/or DAS options as required

  33. Implementation Details (#7) • Install OAS application server instances • Make note of the Centralized/Master & “Fan-Out” OID port numbers, server names and repository names so that the correct values can be supplied when requested

  34. Lessons Learned • Oracle will work with you to mature their products to better meet your business needs when requested • Make sure to select the OAS Infrastructure design that is consistent with your IT organizational structure • Make sure to analyze “ALL” OAS Infrastructure instance configuration options before you finalize your design • A “Fan-Out” SSO configuration does successfully enable decentralized IT organizations to participate in a centrally managed SSO scheme

  35. Contact Information • Tony Macedo • Macedo3@llnl.gov

More Related