Oracle Identity Cloud Service


Deep Dive Series: Multitenant Provisioning, FedSSO with Custom App Templates and Just-In-Time Provisioning


By Ricardo Gutierrez


March 2017

Overview

Oracle Identity Cloud Service (IDCS) is an Identity-as-a-Service (IDaaS) solution available in Oracle Public Cloud (OPC). It is designed to extend enterprise controls by automating PaaS and SaaS account provisioning and deprovisioning, simplifying the user experience for accessing cloud applications by providing seamless integration with enterprise identity stores and authentication services, and facilitating compliance activities by clearly reporting on cloud application usage.

IDCS is built on a microservices, multitenant architecture involving small services running on their own processes and exposing RESTful service endpoints. Microservices can scale independently based on their role in the overall component. Because microservices are restricted to specific functionality, they are easier to understand, integrate and maintain.

IDCS adheres to cloud design principles (scalability, elasticity, resilience, ease of deployment, functional agility, technical adoption, and organization alignment), leveraging standards-based HTTP protocols for authentication (OpenID Connect 1.0), coarse-grained authorization (OAuth 2.0), identity federation (SAML 2.0), and user/role profile (SCIM). By leveraging HTTP-only protocols, IDCS ensures proper decoupling between the identity service and its consumers, freeing OPC services and infrastructure of the need for awareness of the physical location and internal characteristics of the identity service.

 

 

guiterrez-oics-fig01
Figure 1. IDCS Architecture Conceptual Design

 

Integration with Oracle Identity Manager in Hybrid Environments

Oracle Identity Manager (OIM) is an on-premise solution for managing accounts and access privileges across business applications and platforms. It can be easily integrated with IDCS in a hybrid environment (on-premise and cloud) as a viable path for cloud adoption. The inherent synergies between IDCS and OIM provide several benefits:

  • Control, management and insight across both on-premise and cloud environments.
  • A comprehensive set of identity management capabilities (by leveraging a combination of on-premise and cloud stack).
  • The ability for customers to smoothly move identity management workloads to the cloud.
  • Bi-modal identity management capabilities to facilitate bi-modal IT.

One key component of the integration is the OIM connector for IDCS (aka IDCS Connector) that provides provisioning and reconciliation capabilities for management of identity data. This integration can be further enhanced with Oracle Identity Governance Suite (in which OIM is a main component), adding identity governance capabilities like certification, segregation of duties and more to both on-premise and cloud applications.

 

guiterrez-oics-fig02
Figure 2. OIM Integration with IDCS

The IDCS Connector

The OIM Connector for IDCS, henceforth referred to in this article as IDCS Connector, enables the use of IDCS as a managed source of identity data for Oracle Identity Manager. The IDCS Connector is based on the Identity Connector Framework (ICF) and leverages REST APIs to communicate with IDCS as an SCIM target supporting provisioning and reconciliation operations.

For those familiar with the OIM connector architecture, the IDCS connector pretty much follows the same deployment patterns, with one small difference: Prior to its operation, a client application must be defined in IDCS in order to establish communication.  A few highlights:

  • Certified to work with Oracle Identity Manager 11gR2 PS3 plus latest bundle patch.
  • Can be installed in the OIM Server or Connector Server 11.1.2.1.0 plus JDK 1.6 or higher.
  • The IDCS root certificate must be installed in the OIM keystore to enable secure communications.
  • The connector supports multi-tenant provisioning or provisioning to multiple IDCS tenants.

Further information about the IDCS Connector can be found in the online documentation.

 

guiterrez-oics-fig03
Figure 3. IDCS Connector Provisioning and Reconciliation

IDCS Connector Deployment Models

The IDCS Connector supports two deployment models for provisioning identity data with IDCS.

  1. Single-tenant provisioning: With single-tenant provisioning you deploy the connector in the typical manner, creating a client application and a user account in the target IDCS tenant for provisioning (e.g. using OAuth 2.0 Resource Owner Password).
  2. Multitenant provisioning: With multi-tenant provisioning you have two options: (a) deploy one connector with multiple IT resource definitions, one for each IDCS tenant, or (b) deploy multiple copies of the connector (clones), each copy having one IT resource definition per IDCS tenant. In both cases you create a client application and a user account on each target tenant. The main difference between the two options, is that with multiples copies of the connector you have a different set of resources and processes per connector that you can customize as needed.

Federation Made Easy with Custom Application Templates

New in IDCS are the application templates used to define the identity, access, and configuration information needed by IDCS to integrate with third-party cloud applications, such as mobile, client, or server applications.

Available through the user interface are three main categories of applications that can be customized via an easy to use application wizard:

  • SAML Application - intended to define applications supporting the SAML standard for single sign-on.
  • Mobile Application - used to define mobile applications using the OAuth 2.0 specification.
  • Trusted Application - for web applications using OAuth 2.0.

Along with the definition, IDCS provides access control capabilities, so administrators can grant access to applications directly (assigning users) or indirectly (via group membership). Furthermore, entitlements can be granted to users or groups to, for example, enable delegated administration.

 

guiterrez-oics-fig
Figure 4. IDCS Application Wizard

Just-in-Time Provisioning with Cloud Applications

Federation in identity management enables two or more partners to work together, exchanging identity information securely across internet domains, providing secure single sign-on (SSO). Common to a SAML federation are the concepts of identity provider (IdP) and service provider (SP). The IdP is the authoritative entity responsible for authenticating an end user and asserting a trusted identity for that user to a trusted partner or SP, who offers application services but does not act as identity provider.

To share information about a user, partners must be able to identify the user, even though they may use different identifiers for the same user. This usually requires that user identities be created at the service provider before a user can actually perform federation to access the services. This is where just-in-time (JIT) provisioning can help by allowing an end user identity be provisioned (created or updated) at the service provider the first time the end user tries to access the service provider's services, without the need for prior identity provisioning activity between the identity provider and service provider.

With JIT provisioning, the identity provider includes user attributes in the SAML assertion needed by the service provider for provisioning the end user. The identity provider sends the SAML assertion to the service provider when the end user accesses the service provider as part of a single sign-on operation. If no match exists for the presented user name, the service provider creates a new account with the end user attributes included in the SAML assertion. The service provider also immediately grants access to the requested service to the end user. If a match is found, the service provider updates the account according to the attribute information in the SAML assertion.

 

guiterrez-oics-fig
Figure 5. IDCS and JIT Provisioning with Cloud Applications

A Sample Use Case: Acme Corp

This section focus on a sample use case demonstrating multitenant provisioning with the IDCS connector and federated single sign-on with JIT provisioning using IDCS custom application templates.

Background

Acme Corp (a fictitious company) includes subsidiaries Wanderlust and Greenenergy. Each has its own tenant service in Oracle Identity Cloud Service (IDCS). The company has recently installed on-premise Oracle Identity Manager (OIM), and wants to configure OIM to integrate all the IDCS tenants. As part of the integration they want to:

  • Automate the on-boarding process of new users with Wanderlust and Greenenergy IDCS tenants, so that when a new user is provisioned in OIM, a corresponding account is also provisioned in the target tenant.
  • Automatically provide employees with access to the Salesforce application via single sign-on, without requiring prior account provisioning in Salesforce.
  • Automatically provide contractors with access to the ServiceNow application via single sign-on without requiring prior account provisioning in ServiceNow.
  • Maintain centralization of identity management and access control while integrating the two solutions in a hybrid environment.

 

guiterrez-oics-fig06
Figure 6. Acme Corp Desired State Configuration

Solution Overview

The following is a summary of the functions that make up the solution:

  • Use IDCS connector capabilities to provision accounts on multiple tenants within IDCS.
  • Use OIM access policies and membership rules to automate the provisioning of user accounts and entitlements.
  • Use IDCS SAML application wizard and custom application templates to set up federation with Salesforce and ServiceNow applications, where the IDCS tenants will act as identity providers.
  • Use application grants and IDCS groups to enable access control.
  • Configure JIT provisioning on Salesforce and ServiceNow applications.

 

guiterrez-oics-fig07
Figure 7. Solution Overview

Assumptions and Prerequisites

The following configuration steps assume that Acme Corp has installed on-premise Oracle Identity Manager or Oracle Identity Governance Suite 11gR2 PS3 in a Linux server, and that two tenant services exist for Wanderlust and Greenenergy in Oracle Identity Cloud Service. Also, an email infrastructure for the tenant domains (wanderlust.com and greenenergy.com) has been configured, so users in Wanderlust and Greenenergy subsidiaries can receive email notifications. The versions of SaaS applications used in this demonstration are Salesforce - Developer Edition and ServiceNow - Fuji Release. Please keep in mind that some configuration options may be slightly different between these versions.

Summary of Configuration Steps

Configuring Multitenant Provisioning
  1. Walk-through of Acme Corp Configuration in OIM
  2. Creating Employees and Contractors Groups
  3. Creating Connector Application and User Account
  4. Installing and Configuring IDCS Connector
  5. Creating Access Policies
  6. Creating Role Membership Rules
Configuring Federation with Application Templates
  1. Configuring Federation with Salesforce
  2. Configuring Federation with ServiceNow
  3. Configuring Application Grants
Configuring JIT Provisioning
  1. Configuring JIT Provisioning with Salesforce
  2. Configuring JIT Provisioning with ServiceNow
Testing the Solution
  1. On-boarding Users in OIM
  2. Notification and User Account Activation
  3. Sign-In to IDCS and Access Cloud Applications

Configuring Multitenant Provisioning

1. Walk-through of Acme Corp Configuration in OIM

  • Acme Corp has already installed OIM and configured the Wanderlust and Greenenergy subsidiaries  as child organizations. This approach facilitates delegated administration while keeping centralized the management of identities across the organization (Figure 8).

     

    guiterrez-oics-fig08
    Figure 8. Acme Corp Child Organizations

  • Using the new Administration Roles capability in OIM, three admin roles have been defined (Figure 9), along with delegated administrators. These will be used later to test the provisioning of new users in OIM.

     

    guiterrez-oics-fig09
    Figure 9. Acme Corp Administration Roles

2. Creating Employees and Contractors Groups

  • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for Wanderlust tenant.
  • Click on Groups tab, then click on Add to crate a new group.
  • Enter a name for the new group, e.g. Employees, then click Finish (Figure 10).

     

    guiterrez-oics-fig10
    Figure 10. Creating a Group

  • Repeat the previous steps to create a group for Contractors
  • Login as administrator (e.g. admin@greenenergy.com) to the IDCS Admin Console for Greenenergy tenant.
  • Repeat the previous steps to create groups for Employees and Contractors

3. Creating Connector Application and User Account

  • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for the Wanderlust tenant.
  • Click the Applications tab, then click Add to create a new application.
  • In the Add Application wizard, click Trusted Application and enter the application details as needed.

    E.g. enter the following values for the Wanderlust connector application:

    Name            : IDCS-Connector  
    Description : My IDCS Connector Application
  • Click Next, then, in the Authorization step, select Configure this application as a client now.
  • In the Authorization section, select Resource Owner as the Allowed Grant Types.
  • In the Accessing APIs from Other Applications section, select Grant the client access to Identity Cloud Service Admin APIs check-box and select the Identity Domain Administrator and Me roles.
  • Click Next, then Finish.
  • Write down the Client ID and Client Secret values from the Application Added window, then click Close. You will need these values later to configure the connector in OIM.
  • On the application details page, click Activate to activate the application, then click Activate Application to confirm (Figure 11).

     

    guiterrez-oics-fig
    Figure 11. Activate Connector Application

  • Click the Users tab, then click Add to create a new user account.

    E.g. enter the following values for the new user account:

     First Name      : idcs
    Last Name : connector
    User Name/Email : idcs@wanderlust.com
  • Click Finish to create the new account.
  • Click the Settings tab, then, from the left-toolbar, click Delegated Administration to open the Delegated Administration page.
  • Expand the User Administrator role, click Add to open the Add Users to the Administrator Role window.
  • Search for the user created in the previous step, e.g. idcs. Select it and click Add to add the user to the role.
  • Using an email client, open the notification sent to the user email address and follow the instructions to activate the account and set the password (e.g. Oracle123). You will need this value later to configure the connector in OIM. Note: when a new user account is created via the Admin Console, IDCS sends an email notification to the user email address to activate the account.
  • Repeat the previous steps to create an application and user account for the Greenenergy tenant.

4. Installing and Configuring IDCS Connector

  • Download the IDCS Connector file IDCS-11.1.1.5.0.zip, then proceed to install the connector in the OIM server by unpacking the file into the ConnectorDefaultDirectory.

    E.g.: run the following command in the OIM server as the same user who owns the OIM installation files:

    unzip /tmp/IDCS-11.1.1.5.0.zip /home/oracle/oim-oam-omss/products/identity/
    iam/server/ConnectorDefaultDirectory

     

    Note: unpacking the connector files in the above directory will make the connector available in the user interface (OIM Admin Console) for installation.

  • Login as xelsysadm to the Admin Console in OIM. In the left-side menu, click Manage Connector, then click Install and select Oracle Identity Cloud Service 11.1.1.5.0 from the connector list.
  • Click on Load to install the connector, then click on Continue and then on Exit once the installation is completed (Figure 12)

     

    guiterrez-oics-fig
    Figure 12. Installing IDCS Connector

  • As per OIM documentation, you must clear the cache each time a new connector is installed.

    E.g.: open a terminal session in the OIM server and run the following commands:

     export CLASSPATH=$MW_HOME/oracle_common/modules/oracle.jrf_11.1.1/jrf-api.jar:
    $MW_HOME/oracle_common/modules/oracle.odl_11.1.1/ojdl.jar
    export JAVA_HOME=/usr/java/jdk1.7.0_80
    export OIM_ORACLE_HOME=/home/oracle/oim-oam-omss/products/identity/iam
    export MW_HOME=/home/oracle/oim-oam-omss/products/identity
    export WL_HOME=/home/oracle/oim-oam-omss/products/identity/wlserver_10.3
    export APP_SERVER=weblogic
    export DOMAIN_HOME=/home/oracle/oim-oam-omss/config/domains/IAMGovernanceDomain
    cd $OIM_ORACLE_HOME/server/bin
    ./PurgeCache.sh All

     

    Note: the PurgeCache.sh script will prompt for the OIM admin user/password and server URL (e.g. t3://ora-iambox.local:14000)

  • Create a Base64 encoded string using the Client ID and Client Secret generated by IDCS during the creation of the connector application in the target tenant. This encoded string will be used in the next steps to configure the IDCS connector.

    E.g.: run the following command using the Client ID and Client Secret generated in the Wanderlust tenant:

    echo -n "6939393047e241b08269d2c475a0e90c:39d89f20-76b6-4cdf-b4b8-989afca446bf" | base64

     

    Note: in the above command the values between double quotes must be separated by a semicolon "<client_id>:<client_secret>". Use the resulting value in the next steps.

  • This configuration will use the multi-tenant provisioning model for deploying the IDCS connector with multiple IT resources, one for each tenant. The connector installation by default creates an IT resource, so we will create two new IT resources and then optionally delete the default which is not needed for this configuration. Login as xelsysadm to the admin console in OIM.
  • From the left-side menu, click on IT Resource, then click on Create IT Resource. Provide the IT resource information as needed.

    E.g.: enter the following values:

    IT Resource Name : Wanderlust IDCS
    IT Resource Type : Identity Cloud Services
  • Click on Continue and proceed to enter the resource parameter values according to your target IDCS tenant.

    E.g. enter the following values for the Wanderlust tenant:

     acceptType              = application/json
    authenticationServerUrl = https://wanderlust.idcs.internal.oracle.com:8943/oauth2/v1/token
    baseURI = /admin/v1
    Configuration Lookup = Lookup.IDCS.Configuration
    Connector Server Name = [empty]
    contentType = application/json
    customAuthHeaders = Authorization=Basic <base64_string_for_connector_app_wanderlust>
    grantType = password
    host = wanderlust.idcs.internal.oracle.com
    password = Oracle123
    port = 8943
    scope = urn:opc:idm:__myscopes__
    sslEnable = true
    username = idcs@wanderlust.com

Note: the value for the parameter customAuthHeaders is a string containing the value "Authorization=Basic " plus a Base64 encoded string created using the Client ID and Client Secret from the connector application. The username and password parameters correspond to the user account created in IDCS for the target tenant.

  • Click Continue to set the access permissions, accept the default roles and permissions and click Continue.
  • Verify the IT resource details (Figure 13) and click Continue.

     

    guiterrez-oics-fig13
    Figure 13. IT Resource Details

  • In the IT resource connection result page, click Continue to create the IT resource and then click Finish to close the window.
  • Proceed to repeat the previous steps to create an IT resource for Greenenergy.

    E.g.: use the following values for the IT resource information:

    IT Resource Name : Greenenergy IDCS
    IT Resource Type : Identity Cloud Services

     

    E.g. use the following values for the resource parameters:

      acceptType              = application/json
    authenticationServerUrl = https://greenenergy.idcs.internal.oracle.com:8943/oauth2/v1/token
    baseURI = /admin/v1
    Configuration Lookup = Lookup.IDCS.Configuration
    Connector Server Name = [empty]
    contentType = application/json
    customAuthHeaders = Authorization=Basic <base64_string_for_connector_app_greenenergy>
    grantType = password
    host = greenenergy.idcs.internal.oracle.com
    password = Oracle123
    port = 8943
    scope = urn:opc:idm:__myscopes__
    sslEnable = true
    username = idcs@greenenergy.com
  • Once the two resources for Wanderlust and Greenenergy are created, you can optionally delete the default IT resource (Identity Cloud Service) created during the connector installation as this is not needed in this configuration.
  • Proceed to create the IDCS user forms and application instances, to do so click Sandboxes at the top right-corner of the Admin Console in OIM. In the Manage Sandboxes tab, click Create Sandbox and enter a name, e.g. IDCS, click Save and Close and then click OK to confirm.
  • From the left-side menu, click Form Designer to open the form designer page, then click Create and enter the form details as needed.

    E.g.: enter the following values to create a user form for Wanderlust:

      Resource Type   : IDCS User
    Name : WanderlustUserForm
  • Click Create to create the user form.
  • Repeat the previous steps to create a user form for Greenenergy.

    E.g.: use the following values:

      Resource Type   : IDCS User
    Name : GreenenergyUserForm
  • Once the user forms are created, click Application Instances to open the application instances page, then click Create and proceed to enter the application details as needed.

    E.g.: enter the following values to create an application instance for Wanderlust:

      Name                    : WanderlustIDCS
    Display Name : Wanderlust Identity Cloud Service
    Description : Wanderlust Application Instance for Identity Cloud Service
    Resource Object : IDCS User
    IT Resource Instance : Wanderlust IDCS
    Form : WanderlustUserForm
  • Click Save to create the application instance. Once the application instance is created, make sure to edit the instance to assign the corresponding organization. E.g. assign organization Wanderlust to the application instance Wanderlust Identity Cloud Service.
  • Repeat the previous steps to create an application instance for Greenenergy.

    E.g. use the following values for the instance details:

      Name                    : GreenenergyIDCS
    Display Name : Greenenergy Identity Cloud Service
    Description : Greenenergy Application Instance for Identity Cloud Service
    Resource Object : IDCS User
    IT Resource Instance : Greenenergy IDCS
    Form : GreenenergyUserForm
  • Go back to the Manage Sandboxes tab, select the active sandbox (e.g. IDCS) and click Publish Sandbox, then click OK if you are prompted to confirm the action.
  • Proceed to harvest entitlements and synchronize the OIM catalog. Login as xelsysadm to the Admin Console in OIM. From the left-side menu click on Scheduler, in the open window select the Scheduler tab and search for IDCS Group Lookup Reconciliation. Edit the job and update the corresponding parameters as needed for the target tenant.

    E.g. enter the following value for Wanderlust:

     IT Resource Name    : Wanderlust IDCS
  • Click Run Now (Figure 14) to run the job and wait until the execution is completed.

     

    guiterrez-oics-fig
    Figure 14. Scheduled Jobs

  • Proceed the run the same job again but this time for the Greenenergy tenant.

    E.g. use the following value for Greenenergy:

     IT Resource Name    : Greenenergy IDCS
  • In the Scheduler tab, search for IDCS Manager Lookup Reconciliation. As you did in the previous steps, run this job for each target tenant, updating the IT Resource Name parameter accordingly.
  • Then, proceed to search and run the following jobs: Entitlement List and Catalog Synchronization Job, for these jobs there is not need to update the parameters.

5. Creating Access Policies

  • Login as xelsysadm to the Admin Console in OIM.
  • From the left-side menu, click Access Policies, then click Create Access Policy
  • In the create access policy window, enter the parameters as needed to create a new policy.

    E.g. enter the following values for the Wanderlust Employees policy:

      Access Policy Name          : Wanderlust Employees
    Access Policy Description : Access Policy for Employees
    Policy Owner : User
    Policy Owner's Value : XELSYSADMIN
  • Click Continue to open the Select Resources page, select IDCS User and click Add to move it to the selected window, then click Continue.
  • In the next page make sure IDCS User is listed, then click Continue again.
  • Search for and select Wanderlust IDCS in the IDCS Server field, then click Set Additional Data.
  • Search for group Wanderlust IDCS~Employees and click Add to add the group as a selected group value, then click Continue.
  • In the Revoke or Disable Flag page, check Revoke if not longer applies for IDCS User and click Continue, and then Continue again.
  • In Verify Access Policy Information page, make sure everything is correct and click on Create Access Policy (Figure 15).

     

    guiterrez-oics-fig15
    Figure 15. Access Policy

  • Repeat the previous steps to create the remaining access policies for Wanderlust and Greenenergy.

    E.g. use the following values for the remaining policies:

      Access Policy Name          : Wanderlust Contractors
    Access Policy Description : Access Policy for Contractors
    IDCS Server : Wanderlust IDCS
    Group : Wanderlust IDCS~Contractors

    Access Policy Name : Greenenergy Employees
    Access Policy Description : Access Policy for Employees
    IDCS Server : Greenenergy IDCS
    Group : Greenenergy IDCS~Employees

    Access Policy Name : Greenenergy Contractors
    Access Policy Description : Access Policy for Contractors
    IDCS Server : Greenenergy IDCS
    Group : Greenenergy IDCS~Contractors
  • Once all the policies are created proceed to logout from the OIM Admin Console

6. Creating Role Membership Rules

  • Login as xelsysadm to the Self Service Console in OIM.
  • Click on Manage tab, then click on Roles tile to open the roles page, click on Create.
  • In the Create Role tab, enter the values to create a new role.

    E.g. enter the following values for the Wanderlust Employees role:

      Name                : Wanderlust Employees
    Display Name : Wanderlust Employees
    Role Description : Employees role for all Wanderlust users
    Risk Level : Low Risk
  • Click on Next to open the Define Roles Hierarchies page, click on Next.
  • In the Select Access Policy page, click on Add Access Policies, in the Add Access Policies window search and select Wanderlust Employees, click on Add Selected and then Select.
  • Make sure the policy is listed, click on Next.
  • In the Add Role Membership page, click on Create Membership Rule, in the Build Expression tab make sure to create the following rule: ((User Type = "Emp") AND (Organization = "Wanderlust")), then click on Save.
  • Verify the new rule is listed, click on Next (Figure 16).

     

    guiterrez-oics-fig16
    Figure 16. Membership Rule

  • In the Publish Role to Organizations page, click on Add Organizations, in the Add Organizations window search and select Wanderlust, click on Add Selected and then Select.
  • Make sure the organization is listed, click on Next.
  • In the Role Definition Summary page, verify all the information and click on Finish.
  • Repeat the previous steps to create the remaining roles and membership rules for Wanderlust and Greenenergy.

    E.g. use the following values for the remaining roles:

      Name                : Wanderlust Contractors
    Role Description : Contractors role for all Wanderlust users
    Risk Level : Low Risk
    Access Policy : Wanderlust Contractors
    Membership Rule : ((User Type = "Contractor") AND (Organization = "Wanderlust"))
    Organization : Wanderlust

    Name : Greenenergy Employees
    Role Description : Employees role for all Greenenergy users
    Risk Level : Low Risk
    Access Policy : Greenenergy Employees
    Membership Rule : ((User Type = "Emp") AND (Organization = "Greenenergy"))
    Organization : Greenenergy


    Name : Greenenergy Contractors
    Role Description : Contractors role for all Greenenergy users
    Risk Level : Low Risk
    Access Policy : Greenenergy Contractors
    Membership Rule : (User Type = "Contractor") AND (Organization = "Greenenergy"))
    Organization : Greenenergy
  • Proceed to logout from the OIM Self Service Console

Configuring Federation with Application Templates

1. Configuring Federation with Salesforce

IDCS Configuration Settings
  • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for Wanderlust tenant.
  • Click on Applications tab, then click on Add to create a new application.
  • In the Add Application wizard, click on SAML Application and proceed the enter the application details as needed.

    E.g. enter the following values for the Salesforce application:

      Name                : Salesforce
    Description : Federated SSO and JIT Provisioning with Salesforce Application
    Upload icon : [optional]
    Application URL : https://login.salesforce.com?so=00D41670000ePKP
    Display in My Apps : [checked]

     

    Note: the value for the Application URL parameter is the Salesforce Login URL that is generated during the configuration of the Single Sign-On Settings in the Salesforce application. You can enter a temporary value for this parameter and later update the value once the configuration in Salesforce is completed.

  • Click on Next, then expand the General section to provide the required details.

    E.g. enter the following general details:

      Entity ID               : https://saml.salesforce.com
    Assertion Consumer URL : https://login.salesforce.com?so=00D41670000ePKP
    NameID format : Unspecified
    NameID Value : Primary Email

    Note: the value for the Assertion Consumer URL parameter is the same as the Application URL.

  • Expand the Advance Settings section to provide the required settings.

    E.g. enter the following advance settings:

      Signed SSO                                  : Assertion
    Include Signing Certificate in Signature : [unchecked]
    Signature Hashing Algorithm : SHA-1


    Enable Single Logout : [checked]
    Logout Binding : Redirect
    Single Logout URL : https://na35.salesforce.com/secur/logout.jsp
    Logout Response URL : https://na35.salesforce.com/secur/logout.jsp

    Encrypt Assertion : [unchecked]

     

    Note: the value for the Single Logout URL and Logout Response URL parameters can be obtained from the URL address in your Salesforce application. Replace only the host name part (e.g. na35.salesforce.com).

  • Expand the Attribute Configuration section to add the user attributes as needed.

    E.g. add the following user attributes:

       Name                        Format          User Attribute (IDCS)
    -------------------------- -------------- ---------------------
    User.FirstName Unspecified First Name
    User.LastName Unspecified Last Name
    User.Email Unspecified Primary Email
    User.Username Unspecified Primary Email
    User.FederationIdentifier Unspecified User Name
    federationId Unspecified User Name

     

    Note: these attributes are the minimum required and will be included in the SAML assertion to enable JIT provisioning with Salesforce.

  • Click on Download IDCS Certificate to download the IDCS tenant certificate. E.g. save the file as IDCS-Wanderlust-Certificate.pem
  • Click on Finish and then on Activate to activate the application (Figure 17).

     

    guiterrez-oics-fig
    Figure 17. Activate Salesforce Application

  • Repeat the previous steps to create the Salesforce application for the Greenenergy tenant.
Salesforce Configuration Settings
  • Login as administrator (e.g. admin@acme.com) to Salesforce Admin Console.
  • From the left-side Administer menu, expand Security Controls and click on Single Sign-On Settings.
  • In the Single Sign-On Settings page make sure SAML Enabled is checked under section Federated Single Sign-On using SAML.
  • Click New to add a new identity provider, enter the details as needed.

    E.g. enter the following details to define an IdP for Wanderlust tenant:

     Name                                : WANDERLUST
    SAML Version : 2.0
    Issuer : https://wanderlust.idcs.internal.oracle.com:8943/fed

    Identity Provider Certificate : IDCS-Wanderlust-Certificate.pem
    Request Signing Certificate : [SelfSignedCert...]
    Request Signature Method : [RSA-SHA1]
    Assertion Decryption Certificate : [Assertion not encrypted]


    SAML Identity Type : [Assertion contains the User's Salesforce username]
    SAML Identity Location : [Identity is in the NameIdentifier element of the
    Subject statement]

    Identity Provider Login URL : [empty]
    Identity Provider Logout URL : https://wanderlust.idcs.internal.oracle.com:8943/oauth2/v1/
    userlogout

    API Name : WANDERLUST
    Entity ID : https://saml.salesforce.com

     

    Note: for the parameter Identity Provider Certificate provide the file name of the IDCS certificate downloaded in the previous configuration.

  • Click Save to create the new definition (Figure 18).

     

    guiterrez-oics-fig
    Figure 18. Salesforce SAML SSO Settings

  • Once the new definition is listed in the Single Sign-On Settings page, click on the name, e.g. WANDERLUST to display the configuration settings.
  • Write down the Salesforce Login URL value from the Endpoints section. You will need this value to configure the Salesforce application in the IDCS tenant.
  • Note that we have not yet enabled or configured JIT provisioning, this task will be described in the next paragraphs.
  • Repeat the previous steps to create an identity provider for the Greenenergy tenant.

2. Configuring Federation with ServiceNow

IDCS Configuration Settings
  • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for Wanderlust tenant.
  • Click on Applications tab, then click on Add to create a new application.
  • In the Add Application wizard, click on SAML Application and proceed the enter the application details as needed.

    E.g. enter the following values for the ServiceNow application:

       Name                : ServiceNow
    Description : Federated SSO and JIT Provisioning with ServiceNow Application
    Upload icon : [optional]
    Application URL : https://dev16759.service-now.com
    Display in My Apps : [checked]

     

    Note: the value for the Application URL parameter can be obtained from the URL address in your ServiceNow application.

  • Click on Next, then expand the General section to provide the required details.

    E.g. enter the following general details:

       Entity ID               : https://dev16759.service-now.com
    Assertion Consumer URL : https://dev16759.service-now.com/navpage.do
    NameID format : Unspecified
    NameID Value : User Name

     

    Note: replace the host name in the Entity ID and Assertion Consumer URL parameters with the value obtained from the URL address in your ServiceNow application.

  • Expand the Advance Settings section to provide the required settings.

    E.g. enter the following advance settings:

       Signed SSO                                  : Assertion
    Include Signing Certificate in Signature : [unchecked]
    Signature Hashing Algorithm : SHA-1


    Enable Single Logout : [checked]
    Logout Binding : Redirect
    Single Logout URL : https://dev16759.service-now.com/logout.do
    Logout Response URL : https://dev16759.service-now.com/logout.do

    Encrypt Assertion : [unchecked]

     

    Note: replace the host name in the Single Logout URL and Logout Response URL parameters with the value obtained from the URL address in your ServiceNow application.

  • Expand the Attribute Configuration section to add the user attributes as needed.

    E.g. add the following user attributes:

       Name                Format      User Attribute (IDCS)
    ----------------- ---------- ---------------------
    First Name Basic First Name
    Last Name Basic Last Name
    Email Basic Primary Email
    User Name Basic User Name

     

    Note: these attributes are the minimum required and will be included in the SAML assertion to enable JIT provisioning with ServiceNow.

  • Click on Download IDCS Metadata to download the metadata file needed to setup the federation with ServiceNow. E.g. save the file as IDCS-Wanderlust-Metadata.xml
  • Click on Finish and then on Activate to activate the application (Figure 19).

     

    guiterrez-oics-fig
    Figure 19. Activate ServiceNow Application

  • Repeat the previous steps to create the ServiceNow application for the Greenenergy tenant.
ServiceNow Configuration Settings
  • Login as administrator (e.g. admin) to ServiceNow Admin Console.
  • From the left-side menu, expand Multi-Provider SSO and click on Identity Providers. Note: this step assumes that Multi-Provider SSO Plugin is enabled in ServiceNow otherwise this menu option is not available (see Activate multiple provider single sign-on for instructions in how to activate the plugin)
  • Click New and select SAML2 Update1 to the question What kind of SSO are you trying to create?
  • In the Import Identity Provide Metadata window, click on XML and paste the content of the IDCS-Wanderlust-Metadata.xml file downloaded previously from the IDCS tenant.
  • Click on Import. The import task will fill-in some of the properties values, proceed to review and update the values as needed.

    E.g. update the following properties:

       Name                                    : WANDERLUST
    Active : [checked]
    Default : [checked]
    User field : user_name


    Protocol Binding for the IDP's
    SingleLogoutRequest : urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
    NameID Policy : urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

    Note: the Default parameter can be checked only once if multiple providers are defined.

    E.g. review the remaining properties:

     Identity Provider URL                   : https://wanderlust.idcs.internal.oracle.com:8943/fed
    Identity Provider's AuthnRequest : https://wanderlust.idcs.internal.oracle.com:8943/fed/
    v1/idp/sso
    Identity Provider's SingleLogoutRequest : https://wanderlust.idcs.internal.oracle.com:8943/oauth2/
    v1/userlogout
    Failed Requirement Redirect : [empty]
    ServiceNow Homepage : https://dev16759.service-now.com/navpage.do
    Entity ID / Issuer : https://dev16759.service-now.com
    Audience URI : https://dev16759.service-now.com

    Protocol Binding for the IDP's
    SingleLogoutRequest : urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
    NameID Policy : urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    NameID Attribute : [empty]
    Create AuthnContextClass : [unchecked]
    AuthnContextClassRef Method : urn:oasis:names:tc:SAML:2.0:ac:classes:
    PasswordProtectedTransport
    External logout redirect : https://wanderlust.idcs.internal.oracle.com:8943/ui/
    v1/myconsole
    ...

    Signing Signature Algorithm : http://www.w3.org/2000/09/xmldsig#rsa-sha1
    Single Sign-On Script : MultiSSO_SAML2_Update1
    x509 Certificate : https://wanderlust.idcs.internal.oracle.com:8943/fed_1

     

     

    Note: the ServiceNow Homepage, Entity ID / Issuer and Audience URI are specific to your ServiceNow application and are automatically populated by ServiceNow.

    • Click on Update to update the configuration (Figure 20). Note: there is not need to import the IDCS certificate as the property x509 Certificate has been updated with the IDCS URL address to import the certificate automatically.

       

      guiterrez-oics-fig
      Figure 20. ServiceNow SAML2 Configuration

    • Note that we have not yet configured JIT provisioning, this task will be described in the next paragraphs.
    • Repeat the previous steps to create a configuration for the Greenenergy tenant. Use the metadata file IDCS-Greenenergy-Metadata.xml.

    3. Configuring Application Grants

    • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for Wanderlust tenant.
    • Click on Applications tab, then click on Salesforce application to open the application details page.
    • Click on Groups tab and click on Assign to open the assign groups window, search and select the Employees group and click OK.
    • Click on Applications tab again and proceed to assign the group Contractors to the ServiceNow application.
    • Proceed to logout from the IDCS Admin Console
    • Repeat the previous steps for the Greenenergy tenant.

    Configuring JIT Provisioning

    1. Configuring JIT Provisioning with Salesforce

    • Login as administrator (e.g. admin@acme.com) to Salesforce Admin Console.
    • From the left-side Administer menu, expand Security Controls and click on Single Sign-On Settings.
    • Click on Edit to edit the identity provider configuration (e.g. WANDERLUST) for Wanderlust tenant and proceed to update the required properties for JIT provisioning.

      E.g. update the following properties:

       SAML Identity Type             : [Assertion contains the Federation ID from the User object]
      SAML Identity Location : [Identity is in an Attribute element]
      Attribute Name : federationId
    • Select the User Provisioning Enabled check-box under the Just-in-time User Provisioning section.
    • When prompted to select the provisioning type, select Custom SAML JIT with Apex handler and click on Automatically create a SAML JIT handler template, choose to execute the handler as a Salesforce user with administrator privileges.
    • Click on Save to save the updates.
    • Proceed to customize the auto-generated SAML JIT Handler, to do so go back to Security Controls and click on Single Sign-On Settings.
    • Click on Edit to edit the identity provider configuration for Wanderlust tenant, then click on the auto-generated name for the SAML JIT Handler property, e.g. AutocreatedRegHandler1485929908670.
    • In the Apex Class Detail page, click on Edit to edit the class handler. Note: Salesforce requires that when provisioning a new user you set the default profile and user license, so the following code changes will do just that.

      E.g. Find the following piece of code:

        if(attributes.containsKey('User.ProfileId')) {
      String profileId = attributes.get('User.ProfileId');
      Profile p = [SELECT Id FROM Profile WHERE Id=:profileId];
      u.ProfileId = p.Id;
      }

       

      And replace it with the following code:

        /*** My changes begin here***/
      if(attributes.containsKey('User.ProfileId')) {
      String profileId = attributes.get('User.ProfileId');
      Profile p = [SELECT Id FROM Profile WHERE Id=:profileId];
      u.ProfileId = p.Id;
      } else {
      String profileName = 'Standard User';
      Profile p = [SELECT Id, Name FROM Profile WHERE Name=:profileName];
      String licenseName = 'Salesforce';
      p.UserLicense = [SELECT Id, Name FROM UserLicense WHERE Name=:licenseName];
      u.Profile = p;
      u.ProfileId = p.Id;
      }
      /*** My changes end here***/

       

      Note: be aware that the developer edition of Salesforce only allows one standard user per Salesforce license, so trying to create more than one standard user will trigger an error. This should not be the case with non-developer editions of Salesforce. Alternatively, you can use Chatter Free User for the profile name and Chatter Free for the license.

      • Click on Save to save the changes.
      • Go back to Security Controls and click on Single Sign-On Settings, then repeat the previous steps to enable JIT provisioning for Greenenergy tenant. Note: this time do not choose to auto-generate a SAML JIT Handler but instead select the one generated in the previous steps.

      2. Configuring JIT Provisioning with ServiceNow

      • Login as administrator (e.g. admin) to ServiceNow Admin Console.
      • From the left-side menu, expand Multi-Provider SSO and click on Single Sign-On Scripts.
      • Proceed to create two scripts (click on New each time to create a new script).

        E.g. use the following values for the script names and scope:

           Name    : MultiSSO_SAML2_UserProvisioning
        Scope : All application scopes


        Name : MultiSSO_SAML2_ImportSetUtilExtended
        Scope : All application scopes

         

        E.g. Copy the following code for MultiSSO_SAML2_UserProvisioning script:

           var MultiSSO_SAML2_UserProvisioning = Class.create();
        MultiSSO_SAML2_UserProvisioning.prototype = {

        initialize: function(samlResponse) {
        this.saml = new XMLDocument(samlResponse, false);
        this.tableName = "u_imp_saml_user";
        //hardcoded since import set table and transform are already pointing to this table
        this.attributeStatementNode = "//Response/Assertion/AttributeStatement";
        this.attributeNodeName = gs.getProperty
        ("glide.authenticate.sso.saml2.attribute_node_name", "Name");

        //XML doc used for building XML as expected
        //format for loading into Import Set
        this.xmldoc = new XMLDocument();
        this.xmldoc.setCurrent(this.xmldoc.createElement(this.tableName));
        },
        //Process the XML and extract/prepare the attribute-value pairs
        //in the right format to be able to load into import set
        process: function() {
        var attributes = this.saml.getNodes(this.attributeStatementNode + "/*");

        for (i=0; i < attributes.getLength(); i++) {
        var attributeNum = i + 1;
        //Default position where the "Name" attribute is normally found, just in case...
        var attributeNamePosition = 0;
        var AttributeStatement =
        this.attributeStatementNode + "/Attribute[" + attributeNum +
        "]";
        //Some IdPs provide the AttributeStatement in a different non-standard format
        //use this line instead of the above.
        //var AttributeStatement = attributeStatementNode + "[" + attributeNum +
        "]/Attribute";

        //Lookup the attribute name and get its position in the element, if found
        var attributeNode = this.saml.getNode(AttributeStatement).getAttributes();
        for (j=0; j < attributeNode.getLength(); j++) {
        if(attributeNode.item(j).getNodeName() == this.attributeNodeName) {
        attributeNamePosition = j;
        break;
        }
        }
        var attributeName = this.saml.getNode(AttributeStatement).getAttributes().item
        (attributeNamePosition).getNodeValue() + "";
        var attributeValue = this.saml.getNodeText(AttributeStatement +
        "/AttributeValue");
        //Build elements
        this.xmldoc.createElement("u_" + this._escapeAttribute(attributeName),
        attributeValue);
        }
        //Use the saml:issuer element to set the source
        this.xmldoc.createElement("source", "saml:" + this.saml.getNodeText
        ("//Response/Issuer"));
        },

        //Load the XML into an Import Set
        loadImportSet: function() {
        var isetUtil = new MultiSSO_SAML2_ImportSetUtilExtended();
        var recordID = isetUtil.loadImportSetFromXML("//" + this.tableName +
        "/*", this.xmldoc,
        this.tableName);
        return recordID;
        },

        //Return the value for a given Attribute found in the AttributeStatement
        getAttributeValue: function(attributeName) {
        return this.xmldoc.getNodeText("//" + this.tableName + "/u_" +
        this._escapeAttribute(attributeName));
        },

        //Escape the attributes in a format that ServiceNow can
        //create columns - some attributes contain space, colons and dots
        _escapeAttribute : function (attribute) {
        var _attribute = attribute;
        //if using claims, sometimes the name may contain a url
        //example: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
        if(_attribute.indexOf("/")) {
        var name = _attribute.split("/");
        _attribute = name.pop() + '';
        }
        return _attribute.replace(/[ :.]/g,"_");
        },

        type: 'MultiSSO_SAML2_UserProvisioning' };

         

        E.g. Copy the following code for MultiSSO_SAML2_ImportSetUtilExtended script:

          var MultiSSO_SAML2_ImportSetUtilExtended = Class.create();
        MultiSSO_SAML2_ImportSetUtilExtended.prototype = Object.extendsObject(ImportSetUtil, {

        initialize : function() {
        },

        loadImportSetFromXML : function (xpath_root_node, xmlDoc, tableName) {
        var attrs = new Packages.java.util.HashMap();
        var nodeList = xmlDoc.getNodes(xpath_root_node);
        this._iterateNodeList(nodeList, null, attrs);

        // create or update the table schema
        var tc = new GlideTableCreator(tableName, tableName);
        tc.setExtends("sys_import_set_row");
        tc.setColumnAttributes(attrs);
        tc.update();

        // second pass insert row
        var gr = new GlideRecord(tableName);
        gr.initialize();
        var nodeList = xmlDoc.getNodes(xpath_root_node);
        this._iterateNodeList(nodeList, null, null, gr);
        gr.setWorkflow(true); //Important, otherwise Import SET will not be created!
        return gr.insert();
        },

        type: 'MultiSSO_SAML2_ImportSetUtilExtended'
        });
      • Go back to Multi-Provider SSO and click on Single Sign-On Scripts. Edit script MultiSSO_SAML2_Update1 to make some changes in three different sections. Note: this is an out-of-box script that comes with the Fuji release, the script name may be different in previous releases.

        E.g. Section 1: Find the following piece of code:

        initialize: function() {
        },

         

        And replace it with the following code:

         initialize: function() { 
        /*Auto Provisioning changes */
        this.nameIdOverride =
        gs.getProperty("glide.authenticate.sso.saml2.nameid_policy_override", "");
        /*Auto Provisioning changes */
        },

         

        E.g. Section 2: Find the following piece of code:

         SNC.SecurityEventSender.sendSAMLRedirectReceivedEventData("", eventLogParm2);
        if (!this.SAML2.validateLoginResponse(samlResponseObject, inResponseTo)) {
        this.logError("Could not validate SAMLResponse");
        SNC.SecurityEventSender.sendSAMLLoginFailureEventData("", eventLogParm2);
        return "failed_authentication";
        }

         

        And replace it with the following code:

        SNC.SecurityEventSender.sendSAMLRedirectReceivedEventData("", eventLogParm2);
        if (!this.SAML2.validateLoginResponse(samlResponseObject, inResponseTo)) {
        this.logError("Could not validate SAMLResponse");
        SNC.SecurityEventSender.sendSAMLLoginFailureEventData("", eventLogParm2);
        return "failed_authentication";
        }

        /*Auto Provisioning changes */
        var sup = new MultiSSO_SAML2_UserProvisioning
        (this.SAML2.getDecodedSAMLResponse(request) + "");
        //If NameID override is set, then use it
        var nameId = this.nameIdOverride == "" ? this.SAML2.getSubjectNameID() :
        sup.getAttributeValue(this.nameIdOverride);
        /*Auto Provisioning changes */

         

        E.g. Section 3: Find the following piece of code:

        if(!SSO_Helper.isTestSAMLConnection()) {   request.getSession().setAttribute
        ("glide.saml2.session_index", sessionIndex);
        request.getSession().setAttribute("glide.saml2.session_id", nameId);
        request.getSession().setAttribute("glide.multiSSO.logout_url", this.logoutURL);
        request.getSession().setAttribute("glide.multiSSO.service_url", this.serviceURL);
        }

         

        And replace it with the following code:

        if(!SSO_Helper.isTestSAMLConnection()) {
        request.getSession().setAttribute("glide.saml2.session_index", sessionIndex);
        request.getSession().setAttribute("glide.saml2.session_id", nameId);
        request.getSession().setAttribute("glide.multiSSO.logout_url", this.logoutURL);
        request.getSession().setAttribute("glide.multiSSO.service_url", this.serviceURL);
        }

        /*Auto Provisioning changes */
        this._action = action;
        sup.loadImportSet(); action = this._action;
        /*Auto Provisioning changes */
      • Click on Update to save the changes.
      • Due to the nature of these scripts, a SAML authentication with an existing ServiceNow user must be done in order to create an import set table in ServiceNow, this is needed only once and is valid for both tenants. To do the SAML authentication, create a user in Wanderlust tenant and ServiceNow.

        E.g. use the following values for each user:

        Wanderlust tenant
        First Name : John
        Last Name : Thomas
        User Name : JTHOMAS
        Email : john.thomas@wanderlust.com

        ServiceNow
        User ID : JTHOMAS
        First name : John
        Last name : Thomas
        Email : john.thomas@wanderlust.com
      • Once the users are created, proceed to activate the Wanderlust user account by following the instructions in the email notification sent to john.thomas@wanderlust.com.
      • Login as administrator (e.g. admin@wanderlust.com) to the IDCS Admin Console for Wanderlust tenant.
      • Click on Applications tab, then click on ServiceNow to open the application details page, click on Users tab and proceed to assign user John Thomas.
      • Now, login as user JTHOMAS to the IDCS User Console for Wanderlust tenant. The ServiceNow application should be listed in My Apps portal page, click on the application icon to initiate the SAML authentication with ServiceNow. If you are able to access the ServiceNow application, then proceed with the next steps, otherwise check your configuration.
      • Proceed to logout from the IDCS User Console.
      • Login as administrator (e.g. admin) to the ServiceNow Admin Console. Note: if the SAML authentication was successful the import set table should have been created, we will use this table to define a transformation map.
      • From the left-side menu, expand System Import Sets and click on Create Transform Map, enter the values as needed to create a transform map.

        E.g. enter the following values:

        Name                : Import SAML User
        Source Table : Imp Saml User (u_imp_saml_user)

        Active : [checked]
        Run Business Rules : [unchecked]
        Enforce Man Field : No
        Copy Empty Fields : [unchecked]
        Target Table : User (sys_user)
        Order : 100
        Run Script : [checked]

         

        Note: for the parameter Source Table, you should be able to select the Imp Saml User table which is the import set table.

        E.g. copy the following code in the Script field:

         //This is important for the first ever login, otherwise an empty user may be created until
        //a Field Map is defined below
        //It's recommended to use the same field for coalescing
        //as defined in System Property: glide.authenticate.sso.saml2.user_field

        if(action == "insert") {
        //if no coalesce is set, then ignore insert
        if(!coalesceIsSet()) {
        ignore = true;

        } else {
        //Set random password for new users
        var newPass = Math.random().toString(36).substr(2,16);
        target.user_password = newPass;
        }
        }

        //Returns true is coalesce field has been set for this transform map, false otherwise
        function coalesceIsSet() {
        var fieldMap = new GlideRecord("sys_transform_entry");
        fieldMap.addQuery("map.name", "Import SAML User");
        fieldMap.addQuery("coalesce", true);
        fieldMap.query();
        return fieldMap.hasNext();
        }
      • Click on Submit to create the transform map. Go back to System Import Sets and edit the transform map, e.g. Import SAML User to add the field maps.

        E.g. add the following field mappings:

        Source Field    Target Field    Coalesce
        -------------- -------------- ------------
        u_First_Name First Name
        u_Last_Name Last Name
        u_Email Email
        u_User_Name User ID [checked]
      • Click on Update to save the changes.
      • Proceed to logout from the ServiceNow Admin Console.

      Testing the Solution

      To test the solution we are going to on-board two new Acme users, one as an employee who works in the Wanderlust subsidiary, and the second as a contractor assigned to Greenenergy. Later, these new users will sign-in to IDCS testing their access to the corresponding cloud applications via federated single sign-on.

      1. On-boarding Users in OIM

      • Login to the Self Service Console in OIM as delegated administrator for the Wanderlust subsidiary (e.g. wanderlustadmin).
      • Click on Manage tab, then click on Users tile to open the users page, click on Create, enter the details to create a new user.

        E.g. enter the following values to on-board a new employee:

        First Name      : Peter
        Last Name : Collins
        Email : peter.collins@wanderlust.com
        Organization : Wanderlust
        User Type : Employee
        Display Name : Peter Collins
        User Login : PCOLLINS
        Password : Oracle123
      • Click on Submit to create the new user (Figure 21). Then, proceed to logout from the Self Service Console.

         

        guiterrez-oics-fig
        Figure 21. On-boarding New User

      • Login to the Self Service Console in OIM as delegated administrator for the Greenenergy subsidiary (e.g. greenenergyadmin).
      • Click on Manage tab, then click on Users tile to open the users page, click on Create, enter the details to create a new user.

        E.g. enter the following values to on-board a new contractor:

        First Name      : Olivia 
        Last Name : Jackson
        Email : olivia.jackson@greenenergy.com
        Organization : Greenenergy
        User Type : Contractor
        Display Name : Olivia Jackson
        User Login : OJACKSON
        Password : Oracle123
      • Click on Submit to create the new user.
      • Proceed to logout from the Self Service Console

      2. Notification and User Account Activation

      • The on-boarding of two OIM users in the previous steps should had trigger the provisioning of user accounts on each IDCS tenant respectively.
      • Using an email client, open the notifications sent to each user email address and follow the instructions to activate the accounts and set a password (Figure 22).

         

        guiterrez-oics-fig
        Figure 22. Notification and Account Activation

      3. Sign-In to IDCS and Access Cloud Applications

      • Login as user PCOLLINS to the IDCS User Console for Wanderlust
      • Since user Peter Collins is an employee, he has been added to the Employees group in IDCS as part of the auto-provisioning in the on-boarding process, and consequently has access to the Salesforce application (Figure 23).

         

        guiterrez-oics-fig
        Figure 23. Applications Access

      • In My Apps page, click on Salesforce to access the application. By virtue of SAML federation and JIT provisioning, he can access the application without being prompted to enter his credentials and without having to create an account in Salesforce previously (Figure 24). Proceed to logout from the IDCS User Console, this also will log you out from Salesforce.

         

        guiterrez-oics-fig
        Figure 24. Accessing Salesforce Application

      • Login as user OJACKSON to the IDCS User Console for Greenenergy
      • Since user Olivia Jackson is a contractor, she has been added to the Contractors group in IDCS as part of the auto-provisioning in the on-boarding process, and consequently has access to the ServiceNow application.
      • In My Apps page, click on ServiceNow to access the application. By virtue of SAML federation and JIT provisioning, she can access the application without being prompted to enter her credentials and without having to create an account in ServiceNow previously (Figure 25).

         

        guiterrez-oics-fig
        Figure 25. Accessing ServiceNow Application

      • Proceed to logout from the IDCS User Console, this also will log you out from ServiceNow.

      Conclusion

      Oracle Identity Cloud Service is a solution based on multi-tenant, microservices architecture that implements core identity and access management capabilities delivered as cloud identity services using open standards like OpenID Connect, OAuth 2.0, SAML and SCIM. In this article we have learned about some of the provisioning capabilities for a hybrid environment and integration with cloud applications.

      In future articles, I will review additional features that make IDCS a versatile and powerful identity solution for customers looking to enable scalable business while supporting innovation in the adoption path to the cloud.

      Additional references to the products and features mentioned in this article can be found in the following links:

      About the Author

      Ricardo Gutierrez, a Senior IT Consultant with Oracle, specializes in IDaaS, CASB, Identity and Access Management, Identity Analytics, Identity Governance, Enterprise SSO, Federation, Privileged Account Management, Database and Application Security. With over 25 years of experience working with several technologies, Ricardo has spent the last 12 years working with the full suite of security products from IBM, Microsoft and Oracle. He is also a PMP, CCSP and VMware Certified Professional, and has published several white papers, articles, and training materials covering security and cloud computing.