In this article we will take a look how to configure The vRealize Automation plugin for ServiceNow . The Plug-in enables ServiceNow users to deploy virtual machines and perform day 2 actions on CMDB resources using vRealize Automation catalog and governance capabilities.
- Lab Environment
- PART 1: Configuring a Management, Infrastructure and Discovery (MID) Server(this article)
- PART 1: Configuring ADFS Integration with ServiceNow(this article)
- PART 2: Configuring ADFS Integration with vRealize Automation
- Final Step
This is Part 1. If you have already completed it go to Part 2.
The full lab logical design can be seen HERE.
Configuring a Management, Infrastructure and Discovery (MID) Server
This section covers how to configure a Management, Instrumentation, and Discovery (MID) Server to facilitate communication between ServiceNow and vRealize Automation.
Creating a MID Server user account in ServiceNow
Log in to your ServiceNow portal.
In the search field type System Security server.
Navigate to System Security > High Security Settings > Users and Groups and select Users.
Click New to create a new user account.
Fill in the user information and click Submit.
In the users search filed, find the user you’ve just created and select it.
Select the Roles tab and click Edit.
Select the mid_server role from the collection list and add it to the user account.
Enter a password for the user account and click Update.
Log off from the ServiceNow portal and login with the MID Server user you’ve just created to verify the credentials are working properly. .
Installing and Configuring a MID Server instance
This section covers how to install and configure a MID Server instance.
Log in to your ServiceNow portal.
In the search field type mid server and select Downloads
Select and download the MID Server for the appropriate operating system.
Create the installation directory on your MID Server
Note: In this example, I’m installing MID Server on Windows.
Create another directory within your installation directory and name it accordingly to specify your MID Server name.
Extract the downloaded MID Server archive file into your <mid_server_name> folder.
The resulting directory structure is <installation_directory>/<mid server name>/agent
Navigate to the <installation_directory>/<mid server name>/agent directoryand edit the config.xml file as follows:
Find the <parameter name="url" value="https://YOUR_INSTANCE.service-now.com"/> element and change the value to the URL of your ServiceNow instance.
Enter the MID user credentials you created earlier in the mid.instance.username and mid.instance.password parameters.
Find the <parameter name="name" value="YOUR_MIDSERVER_NAME_GOES_HERE"/> element and change the value for the MID Server name. Use the same name you’ve used form the <mid_server_name> directory earlier.
(Optional) Enter connection information for the proxy server. Remove the appropriate comment tags from the proxy configuration information. For example, you can configure the mid.proxy.use_proxy, mid.proxy.host, mid.proxy.port, mid.proxy.username, and mid.proxy.password.
Save the config.xml file.
Execute the start.bat script.
Log in to the ServiceNow instance identified in the config.xml file.
Navigate to MID Server > Servers. Alternatively, if Discovery is installed, navigate to Discovery > MID Servers.
Verify that all MID Servers connected to this instance are listed.
Select the MID Server name and under Actions on selected rows… select validate.
The MID Server should now show as validated.
Configuring ADFS Integration with ServiceNow
This section covers how to configure ADFS Integration with ServiceNow.
Configuring SAML Single-Sign On in ServiceNow
Log in to your ServiceNow portal.
Navigate to System Definition > Plugins
In the search field type SSO.
Verify that the SSO Provided by Okta, inc plugin is active.
Configure properties for the ServiceNow identity provider.
As a ServiceNow system administrator, enter SAML in your Filter to navigate to the SAML Single SignOn.
Select Properties to configure SAML sign on properties.
Select the Enable external authentication check box.
Download an instance of the ADFS federation metadata file by entering the file URL in your browser: https://ADFS hostname/federationmetadata/2007-06/federationmetadata.xml
Open the ServiceNow federation metadata file that you downloaded, and use the appropriate information from the file to populate text boxes on the SAML 2.0 Single Sign-on properties page.
ServiceNow SAML Single Sign-on Setting
The Identity Provider URL which will issue the SAML2 security token with user info.
http://ADFS host name/adfs/services/trust
The base URL to the Identity Provider’s AuthRequest service. The AuthRequest will be posted to this URL as the SAMLRequest parameter.
https://ADFS host name/adfs/ls/
The base URL to the Identity Provider’s SingleLogoutRequest service. The LogoutRequest will be posted to this URL as the SAMLRequest parameter.
https://ADFS host name/adfs/ls/?wa=wsignout1.0
The protocol binding for the Identity Provider’s SingleLogoutRequest (Values can be either "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" or "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST".)
SignLogoutRequest. Set this property to true if the Identity Provider’s SingleLogoutRequest service requires signed LogoutRequest.
Optional or leave blank.
URL to redirect users after logout, typically back to the portal that enabled the SSO (e.g. http://portal.vmware.com/logout)
Configure ServiceNow Service Provider properties.
Keep defaults for all fields not listed in the following table.
The URL for the ServiceNow instance home page.
https://ServiceNow instance name/navpage.do
The entity identification or the issuer
https://ServiceNow instance name
The audience uri that accepts SAML2 token.
https://ServiceNow instance name
The User table field to match the Subject’s NameID in the SAMLResponse.
The NameID policy to use for returning the Subject’s NameID in the SAMLResponse. The SAML identity provider must support this by declaring the policy in its metadata. The NameID value is used to match with the specified field in the User table to lookup the user.
Configuring the SAML 2.0 Certificate for ServiceNow
Navigate to the IDPSSODescriptor KeyDescriptor signing x509Data section of the FederationMetadata.xml file.
Copy the certificate content from <X509Certificate> node in Federation|Metadata.xml file
Login to ServiceNow and navigate to SAML 2 Single Sign-on > Certificate.
Click on the SAML 2.0 certificate.
Paste the certificate you copied earlier between the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– lines.
Select again the SAML 2.0 certificate.
Click the Validate link at the bottom of page to validate your certificate.
Click the Metadata link in the SAML plug-in menu and copy the metadata content to an xml file: for instance, servicenowInstanceName-metadata.xml.
Configuring an ADFS Relying Party Trust with ServiceNow
This section covers how to configure ADFS Relying Party Trust with ServiceNow
Log in to your ADFS server by opening Administrative Tools and finding the ADFS console link.
Open the ADFS 2.0 Management console and select Trust Relationships > Relying Party Trusts.
Right-click on Relying Party Trust and select Add Relying Party Trust…
Click Start on the configuration wizard.
Select Import data about the relying party from a file on the Select Data Source page.
Import the ServiceNow metadata file that you copied and saved previously from the SAML configuration metadata section.
Enter the name for your ServiceNow instance in the Display text box on the Specify Display Name page.
On the configure Multifactor Authentication Now? Page click Next.
Select Permit all users to access this relying party on the Choose Issuance Authorization Rules page.
Click Next on the Ready to Add Trust page.
Click Close on the Finish page.
Configuring Claim Rules for ADFS ServiceNow Integration
When configuring ADFS integration for ServiceNow, you must set up the appropriate claim rules to control the behavior of incoming and outgoing claims.
This section covers how to configure Claim Rules for ADFS ServiceNow integration.
Right click the relying party trust that you created for ServiceNow, and select Edit Claims Rules.
Select Add Rule on the Issuance Transform Rules tab.
Select Send LDAP Attributes as Claims as the template for the claim rule to create.
Enter the name Get Email Attribute in the Claim rule name text box on the Configure Claim Rule wizard page.
Select Active Directory as the Attribute store.
Select the email addresses for LDAP attributes and the Outgoing Claim Type using the E-Mail Addresses drop-down in the Mapping of LDAP attributes to outgoing claim types section of the page.
Select Add Rule.
You must add a rule that transforms the attributes received from LDAP in the Get Email Attribute rule into the desired SAML format.
Select Transform an Incoming Claim
Enter the name Transformation in the Claim rule name text box on the Configure Claim Rule wizard page.
Select E-Mail Address for the incoming claim type.
Select Name ID as the outgoing claim type.
Select Email as the outgoing name ID format.
Select Pass through all claim values.
This completes Part 1.
If all went well, go grab a beer.
DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.