End-to-End Cloud Access (ServiceNow) Utilizing Oracle Identity and Access Management

The biggest benefit of using cloud based applications and resources such as ServiceNow is that it’s quick to setup, access, and requires little to no on-premise resources. That works in principle, but once you get working with a cloud based application, you need to start answering the questions:

1) How do we get users set up so they can access the application?
2) How do we define what level of access users have in the cloud application?
3) How do we allow users to login securely and simply using common login credentials?
4) How do we remove user access once they no longer require the access (terminated, job change, etc…)?

Most cloud-based applications provide local servers and tools to be able to answer these questions via simple sync to directory servers and file-based exports. But, this starts to chip away at the principle of not requiring local resources or management, especially when you start using multiple cloud providers for different services. Additionally, with the requirement of the local resources, now you need to maintain additional servers and applications which will also require patching, security, and other operational requirements.

Enter Identity & Access Management strategies, Enterprise Roles, rule based provisioning, and cross-domain (federated) authentication. A solution like Oracle Identity & Access Management can handle these activities providing automated user provisioning, secure sign-on, and de-provisioning within hours (not days) with little to no human intervention. This post is going to go through the different components / configurations to get you up and going so that as part of an employee onboard, you can set up the user to:
1) have Active Directory/Exchange;
2) have a ServiceNow account; and,
3) be able to login using their common credentials without requiring a local Mid-Server / LDAP login provider.

The basic flow of what this looks like is as follows:

I won’t cover the details of the Active Directory / Exchange here, but will go through some of the different components and deployments to get ServiceNow up and running so you can do the same in your environment.

NOTE: all configurations done in this post are in my demo / development environment and are not customer specific.

Oracle Identity Manager (OIM) Connector / ServiceNow Access Setup
The OIM Connector guide for ServiceNow (https://docs.oracle.com/cd/E22999_01/doc.111/e73592/toc.htm) goes through most of the steps for setting up the connector in OIM. But, there are a few things that are not covered and cause some issues that I’ll go through here.

To setup the user / OAuth access for the connector, in the ServiceNow dashboard go to System Security > Users. Create a new user like the below (or using your username formatting).

Once the user is setup, under the Roles tab, assign the user to the user_admin and oauth_usr roles.

Once this is done, go to System OAuth > Application Registry. Click New to create a new oauth application registry.

By default, the ‘Token URL’ above is not visible / available when you create new (and this is needed for the connector). You need to go to View and change to the OAuth Provider view.

Once you change views, you’ll see the Token URL that is needed for the OAuth login in the connector.

Once the connector artifacts, application instance, form, and IT resources have been configured and deployed, open the IT Resource definition for ServiceNow and update the information with the below.

A few key notes / mappings here from the OAuth client registry setup in ServiceNow:

• authenticationServerURL = Token URL
• authenticationType = always password
• clientID = Client ID
• clientSecret = Client Secret
• password = service account password setup before
• port = always going to be 443
• host = your ServiceNow main URL (without the http info)
• username = your service account username setup before.

Once all this is done / setup, you can do a sample reconciliation to make sure this is working by running the ServiceNow Group Lookup Recon scheduled task.

If you get a successful run, you’re connected to ServiceNow and can start defining Access Policies / Rules for creating the users.

For this environment, I have a simple access policy that just defines the user creation / account setup.

In the form details for ServiceNow, you only need to specify the server details.

Once this is done, you can create a role with associated rules in OIM to add users and provision access as they are on boarded.

Associated rule for membership defines that the users 1) are active, 2) are an employee, and 3) have a valid email address (for SSO covered later).

The user will be auto-provisioned into ServiceNow once the conditions are met. It will now show a ServiceNow application instance for their ServiceNow account.

NOTE / CAVEAT: the user is provisioned into ServiceNow with system (ServiceNow) defined password since the password field is not accessible via the OOTB REST API. This is not needed since the user will be using their enterprise credentials to login (see next step).

NOTE: you probably noticed the ‘hatmid’ account here (which is contrary to this post), but this is due to the custom dashboard integration in a previous post (see Bridging the Gap )

Oracle Access Manager (OAM) Federation / ServiceNow SSO

Once the OIM configuration and the users are provisioned into the ServiceNow platform, now you need to provide a secure, simplified login experience for the users. OOTB, ServiceNow allows users to login with a username / password, but this requires users to 1) remember a separate password (if not using LDAP login) or 2) requires multiple logins to be able to access the ServiceNow platform. By using a cross-domain (federation) authentication, you can allow users to login using their local trusted credentials and be securely logged into the ServiceNow platform.

To begin, you need to make sure OAM has the Identity Federation service enabled under Configuration > Available Services.

Ensure you have the main Federation configuration settings configured under Configuration > Settings > Federation.

NOTE: Ensure you have signed certificates setup for signing and encryption in OAM federation. The default certificates will work but is not best practice for the setup or using other partners with OAM.

Once OAM is setup and configured, download the IdP (Identity Provider) metadata by going to the URL https://[youroamlburl]/oamfed/idp/metadata.

Once you have the IdP metadata downloaded, go to the ServiceNow admin console. Under System Definition > Plugins enable the plugin ‘Integration – Multiple Provider Single Sign-On Installer’.

Once this is enabled, you’ll now see the ‘Multi-Provider SSO’ menu option.

Go to the Multi-Provider SSO > Administration > Properties and make sure the option to ‘Enable multiple provider SSO’ is set to Yes and save the page.

Once this is done, go to Multiple-Provider SSO > Identity Providers. Click New to create a new provider and in the new provider screen paste the IdP metadata downloaded from OAM. Once uploaded, you’ll see the below screen.

A few things to update / validate here:

1. Signing / Encryption Key Alias: set to saml2sp with the same password (this is the OOTB keys provided by ServiceNow) or can upload custom signed keystores.
2. Check the box to Sign AuthnRequest.
3. On the Advanced tab, make sure to update the User Field to ‘email’ and NameID Attribute to ‘SubjectEmailID’.

Once this is done, you can click the button to generate the metadata.

Take the xml snippet and save it as an xml file. With this file downloaded, go to the OAM console and go to Federation > Identity Provider Management.

Click the button to ‘Create Service Provider Partner’ to add the ServiceNow Metadata. On the create screen, upload the metadata xml snippet from ServiceNow.

When the metadata is imported, update the settings for NameID Format to be ‘Transient’, under Advanced update the settings to the below, and update the attribute mapping / query to your user store / email attribute.

Additionally, update the Attribute Profile for the federation to use a custom (not the default sp-attribute-profile) attribute profile to pass in the email address as a named attribute for mapping user access.

Once this has been completed on the OAM side, back in the ServiceNow console, click on Test Connection to validate the configuration.

NOTE: since my OAM is not publicly exposed, the logout is failing here for validation.

Once the validation has been completed, you can click the button to Active the Identity Provider and will see the provider activated.

The last option here, to force authentication redirect is to choose the link / option for Auto Redirect IdP which will redirect to OAM each time you access the page. Having this enabled, when you access ServiceNow the next time, you will see the below flow for login / access to the portal.

NOTE: Once its enabled, your default ‘admin’ login is not accessible. To use this credential / login, you need to use the URL https://[yoursninstance]/side_door.do.

Closing Thoughts / Notes

The above information gives a high-level flow and example configuration to do end-to-end user provisioning and login to ServiceNow. I used this as an example (since I did this at a customer and they have a free developer version) but you can do a similar flow / architecture for most cloud-based applications. This allows you (as the customer) to have minimal local resources, have a central repository of all cloud access, and enforce secure login and access to all your cloud applications. If you are looking at a cloud deployment, or are looking to simplify and secure your existing cloud applications, make sure you integrate this into your existing identity management program from both a user provisioning and single sign-on.

Helpful Reference Docs

OIM ServiceNow Connector Documentation: https://docs.oracle.com/cd/E22999_01/doc.111/e73592/toc.htm
ServiceNow Kingston Multiple Provider SSO Documentation / Steps: https://docs.servicenow.com/bundle/jakarta-platform-administration/page/integrate/single-sign-on/concept/c_MultipleProviderSingleSignOn.html

Bonus Information: Okta OIN is a set of prebuilt cloud integrations used for Provisioning, Authentication, and Access Management. Thanks to its broadness and depth OIN integrations simplify configuration, speed up adoption, and streamlines the integration process.