Cisco CloudCenter Integration Guide, Release 4.7.3
First Published: May 9, 2017
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
© 2017
Cisco Systems, Inc. All rights reserved.
1. ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. CloudHSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. SMTP Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Callout Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Resource Placement and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. Infoblox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7. Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8. SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 SSO AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 SAML SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Use Case: Shibboleth SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Use Case: ADFS SAML SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9. ServiceNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1 Release Notes for v1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Architectural Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Integration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Install and Configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
4
5
6
14
20
21
27
27
29
31
36
39
39
42
44
45
Cisco CloudCenter Documentation
ACI
Overview
ACI Fundamentals
Availability
Benefits
Integration Requirements
APIC Requirements
CloudCenter Requirements
VMware vSphere Requirements
Using Extensions
Overview
CloudCenter users can use out-of-the-box application profiles to create infrastructure-independent models of any application. Once modeled,
the Cisco CloudCenter platform and Cisco Application Centric Infrastructure (ACI) can work together to provide automated, end-to-end
provisioning of compute, storage, and network configuration of the application as well as its set of required components.
ACI Fundamentals
See the Cisco ACI Fundamentals Guide for additional details on the ACI policy model.
Availability
The CloudCenter – ACI integration is available for VMware cloud environments.
CloudCenter 4.6 supports the following APIC releases:
Cisco APIC, Release 1.0
Cisco APIC, Release 1.1
Cisco APIC, Release 1.2
Cisco APIC, Release 2.0 (only Distributed Virtual Switch – DVS mode)
Cisco APIC, Release 2.1 (effective CloudCenter 4.7)
Benefits
The CloudCenter – ACI integration provides the following benefits:
Use a fully automated creation of ACI policy objects.
Gain the security and efficiency of network microsegmentation without the need to program or modify application code, write
cloud-specific scripts, or have special network expertise.
Users get self-service/on-demand deployment and management of applications with fully integrated Cisco ACI network policy and
configuration.
Integration Requirements
The CloudCenter platform automates the end-to-end-provisioning of the overlay infrastructure and deployments of applications. On ACI, this
includes the provisioning and management of the following resources:
Ensure that the APIC tenant being configured in the CloudCenter has the privileges to create these resources.
Application Network Profiles (ANP)
Endpoint Groups (EPG)
Contracts
Subjects/Filters
As a prerequisite for the CloudCenter platform to provision and configure the applications on APIC, first complete the following requirements to
have a working Cisco ACI environment:
Leaf switch profiles, Switch Selectors, Interface Profile, and Policy Groups
VLAN Pool
VMware's Virtual Machine Manager (VMM) Domain
Routable IP subnet to a New Tenant and Bridge Domain(s) configured with L3 Out for external internet connectivity
Cisco CloudCenter Integration Guide
2
Cisco CloudCenter Documentation
Routing protocols
VRF
APIC Requirements
The Cisco Application Policy Infrastructure Controller (Cisco APIC) functions over both HTTP or HTTPS.
HTTPS: By default, Cisco APIC listens to HTTPS for both the UI and REST APIS. Ensure that the APIC is configured with a valid SSL
certificate that corresponds to the APIC host name.
HTTP: Enable the HTTP access for APIC and ensure accessibility using either the host name or IP address
To ensure the sanity of the environment, follow this procedure.
1.
2.
3.
4.
Using the APIC UI, manually add a new application network profile with one EPG.
Verify that a new VMware Virtual Distribute Switch (vDS) port group is provisioned and displayed in the APIC UI.
Using the vCenter UI, provision/clone a new VM with the network pointing to the created port group.
If operating in Strict mode, you will not have SSH/RDP access to the VM:
a. Create a Contract for Port 22/3389 with its provider being the EPG from Step 1.
b. Create a new L3 out setting to be consumed by the Contract created in Step 4a.
5. SSH/RDP into the VM launched in Step 3 and verify that you can access the CloudCenter Bundle repository and the AMQP server.
CloudCenter Requirements
The CCO being used in the ACI Extension should be able to access the corresponding APIC endpoint.
VMware vSphere Requirements
Requirement
Details
A working VMware vCenter 5.0/5.5/6.0 environment
The minimum VMware vSphere version is v5.0, but vSphere
v5.5 U2 is optimal.
The CloudCenter platform automates the provisioning of virtual machines into
the VMware private datacenter.
The CloudCenter platform requires access credentials to the
vCenter setup.
All ESX host(s) must be physically connected to the ACI leaf switches.
The prerequisite installation requirements for the datacenter
are:
A physical ESX host capable of running at least 10
medium sized instances
An ESX cluster (cluster could comprise of just the one
host)
A datastore (or datastore cluster for DRS support), at
least 100gb of free space
If the ESXi hosts are Cisco UCS based
The VLANs for the CMM must be mapped to the vNIC
template.
The uplinks from the Fabric must interconnect trunking
VLANs to the leaf switches.
Using Extensions
You can create an ACI extension to extend the capabilities of the CCO to provision networks in an ACI environment. You can then use Extensions
to configure the following CloudCenter resources:
Deployment Environment Flow: ACI Extensions are also integrated in the deployment environment and you can determine the
extension to be used by each cloud account. CCMs do not need to make the request to the cloud provider. See Deployment Environment
Defaults for additional context.
Application Deployment Level: Configure tenant and VMM domains to be populated into the application profile when Deploying an
Application. You can configure the External Routed Network field (Layer 3 out) for your APIC setup and connect to that tenant network.
Cisco CloudCenter Integration Guide
3
Cisco CloudCenter Documentation
NIC: When you select the Cisco ACI tab, you have the option to select one of the options from the Endpoint Group (EPG) Type:
Existing EPG: Uses a preconfigured EPG form the APIC setup.
New EPG: Creates a new EPG for this deployment. Optionally, you can also select contracts or interfaces that are consumed by
this new EPG.
Bridge Domain Template: Creates a new bridge domain using the selected template.
ACI as an External Service: When you Deploy an Application that contains an External Service, you can configure the ACI extension in
the Advanced section for this service tier to use the APIC Service Graph Template.
CloudHSM
Overview
Cisco CloudCenter Integration Guide
4
Cisco CloudCenter Documentation
Requirements
Other References
Overview
The CloudCenter platform supports AWS Cloud Hardware Security Module (CloudHSM), a hardware appliance that provides secure key storage
and enables cryptographic operations within a tamper-resistant hardware module.
Requirements
To use CloudHSMs, the Log in as a SysAdmin must adhere to the following requirements:
Configure the CCM for Luna Provider (lunaProvider.jar file) to ensure that you have copied this file to the CCM server in the /usr/local/tom
cat/lib directory so Tomcat can use this library. You will need to restart Tomcat so it automatically uses the lunaProvider library.
Each tenant requires a unique encryption key.
The CCM instance that interacts with the CloudHSM server must reside inside the same VPC as the CCM.
Reboot the CCM before re-establishing the connection to the CloudHSM.
Other References
1.
2.
3.
4.
5.
Safenet Luna WebHelp
AWS CloudHSM
AWS CloudHSM Getting Started Guide
AWS CloudHSM Forum
Connecting Multiple VPCs with EC2 Instances (SSL)
SMTP Mail Servers
Overview
The Mail Properties File
SMTP Configuration Process
Overview
This section explains how to set up your SMTP mail server to use CCM to send emails.
The CloudCenter platform does not support TLS ports. The CloudCenter platform only supports SSL ports to configure SMTP mail
servers.
Add the password string in encrypted format.
The Mail Properties File
The mail.properties file is available in your local Tomcat server at /usr/local/tomcat/webapps/ROOT/WEB-INF/mail.properties.
Cisco CloudCenter Integration Guide
5
Cisco CloudCenter Documentation
# The hostname or IP address of your SMTP server
# Currently mob-gen.com email domain is hosted by gmail
# Gmail requires smtp over ssl, do not modify these settings
mail.smtp.host=smtp.gmail.com
mail.smtp.auth=true
mail.smtp.port=465
mail.smtp.socketFactory.port=465
mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
mail.smtp.socketFactory.fallback=false
# Email user to authenticate to gmail
mail.user.number=1
mail.user.1=<your_osmosix_email_addr>
mail.password.1=<your_email_password>
from.mail.user.1=<your_cloudcenterrtech_email_addr>
from.mail.username.1=
SMTP Configuration Process
To configure SMTP mail servers in CCM, follow this process.
1. Open the mail.properties file.
vi /usr/local/tomcat/webapps/ROOT/WEB-INF/mail.properties
2. Modify the required settings in this file.
For example, if using Gmail, the only lines to change are:
mail.user.1=<your_osmosix_email_addr>
mail.password.1=<your_email_password>
from.mail.user.1=<your_cloudcentertech_email_addr>
from.mail.username.1=
Similarly, change the required lines in your mail.properties file to ensure that you can access you mail from the CCM
3. Restart Tomcat.
/etc/init.d/tomcat restart
Callout Scripts
Overview
Permissions
Supported Callout Topics
Supported Attributes for callout.conf Files
Environment Variables for Callout Scripts
Configure Each Callout Script
The vmNaming Callout Script
The IPAM Callout Script
Supported Properties
OS-Specific IPAM Properties
Sample IPAM Callout Script
The ipamDealloc Callout Script
Sample Callout Workflow
Overview
At various stages in the deployment lifecycle of VMs, The CloudCenter platform supports the ability to control the behavior of the provisioning
process. The different lifecycle points where the behavior can be controlled are called topics. The behavior is controlled by scripts via callouts that
are assigned to topics. A common use case for callouts is to query an IPAM tool during the IP Address Allocation (IPAM) topic to get an IP
address and during the IP shutdown topic (ipamDealloc) to de-allocate the IP address. See the Infoblox integration page for an example of
implementing this use-case.
Callouts are configured on a per-CCO basis and apply to each VM provisioned from that CCO. If different behaviors are required, use control
logic (if/then/case) from inside the callout script.
Cisco CloudCenter Integration Guide
6
Cisco CloudCenter Documentation
Each callout script:
Uses the same parameters and incoming variables.
Exposes a different variable and is mutually exclusive – you can execute any script when required.
Has access (when executed from the CloudCenter platform) to a wide variety of environment variables, including cloud type, deployment
environment, and so forth.
A full list is available in the callout script log at /usr/local/osmosix/callout/<name>/logs/<timestamp>
Consists of two key parts – a configuration file (callout.conf) and the script to be executed. Place these files in the
/usr/local/osmosix/callout/<script topic>/<files> path on the CCO. The name of the sub-folder that you use is arbitrary, but a
best-practice is to use the name of the topic for that callout. For example:
/usr/local/osmosix/callout/ipam/<files>
Permissions
Effective CloudCenter 4.7.0, all callout scripts are executed as cliqruser as part of the security hardening implementation.
Existing callout scripts continue to work without any change – if you encounter a failure, be sure to verify the following items:
Callout Access
Dependency
Workspace permission
chown –R cliqruser:cliqruser /usr/local/osmosix/callout
Scripts shebang line
Bash:
#!/bin/bash
Python:
#!/usr/bin/python2.7
cliqruser privilege
Ability to read/write to files/directories used within the scripts
Ability to issue any command used within the scripts
Supported Callout Topics
Each of these scripts are explained in the sections below.
Use the table of contents above to link directly to each script explanation.
Script
Topic
Folder
Cisco CloudCenter Integration Guide
Callout Script file
Description
Supported Clouds
7
Cisco CloudCenter Documentation
vmNaming
/usr/local/osmosix/callout/vmnaming/
/usr/local/osmosix/callout/vmnaming/callout.conf
Called before
each node is
launched.
This script is
provided (injected
into the script) all
the name
variables (name of
application, name
of tier, image
selected) for each
job.
AzureRM, OpenStack,
VMware, and AWS.
See VM (Node) Name
Config for additional details
on the supported callouts for
the supported clouds.
VMware Nuances
The Hostname Callout o
ption in the Instance
Naming Strategy dropd
own sets the osHostna
me and vmName inside
the guest OS. These
two settings are the
same:
As the vCenter
settings
For Linux
(CentOS7).
Amazon Nuances
The Hostname Callout o
ption in the Instance
Naming Strategy dropd
own sets the osHostna
me and vmName inside
the guest OS.These two
settings are the same
for both Windows and
Linux.
/usr/local/osmosix/callout/ipam/
ipam
/usr/local/osmosix/callout/ipam/callout.conf
Network and
OS-specific
configuration
OpenStack, VMware, and
AWS.
VMware Nuances
The osHostname settin
g:
Is not mandatory
for IPAM callouts.
Only works for
Windows.
The Linux setting
is overwritten by
the vmNaming set
ting.
Amazon Nuances
CloudCenter uses the I
P address, network,
and mask to set the
DHCP scope in the
specified subnet.
ipamDealloc
/usr/local/osmosix/callout/ipamDealloc/
/usr/local/osmosix/callout/ipamDealloc/callout.conf
Called just before
a node is
destroyed
OpenStack, VMware, and
AWS.
Supported Attributes for callout.conf Files
This callout script supports standard Java property file format, using <key>=<value>, each on a separate line. See the following callout.conf file
examples for all three topics:
topic=vmNaming
Cisco CloudCenter Integration Guide
8
Cisco CloudCenter Documentation
[root@centos7-base ipam]# cat ../vmnaming/callout.conf
name=vmNamingExample
type=exec
topic=vmNaming
debug=true
executable=run.sh
reinject=true
disabled=false
topic=ipam
[root@centos7-base ipam]# cat callout.conf
name=ipamExample
type=exec
topic=ipam
debug=true
executable=ipam.py
reinject=true
disabled=false
topic=ipamDealloc
[root@centos7-base ipam]# cat ../ipamDealloc/callout.conf
name=ipamDeallocExample
type=exec
topic=ipamDealloc
debug=true
executable=run.sh
reinject=true
disabled=false
Environment Variables for Callout Scripts
The Callout script accepts environment variables as input parameters. The list of variables depends on the node type. The following table
provides a sample:
Variable
Sample Values or Type
eNV_osName
Linux, Windows
eNV_vmNaming
A string passed by the vmNaming module or auto-generated by the CloudCenter platform
eNV_JOB_ID
An integer to identify the application VM (only)
eNV_launchUserId
An integer to identify the User ID of the person launching the script/module
eNV_launchUserName
A string to identify the user name of the person launching the script/module
All job application settings for application VMs are also available as eNV variables. See CloudCenter-Defined Parameters for additional
context.
Cisco CloudCenter Integration Guide
9
Cisco CloudCenter Documentation
Best Practice
Turn on the debug level and check the debug logs (see Locate Log Files) to view a list of all available input variables.
Configure Each Callout Script
Configure each script separately in a callout.conf file.
You can configure the each of these callout scripts at the region level, not at the tenant level, on a per-CCO basis. The following example
depicts the configuration procedure to add the vmNaming callout script.
If you make changes to the callouts or attributes for a Cloud Region, you must restart the CCO for the changes to take effect.
The callout scripts reside in the /usr/local/osmosix/callout/callout_name/ folder, where callout_name is the name of the corresponding callout.
To add a callout script, follow this process.
1. Create the following directory on the CCO:
/usr/local/osmosix/callout/vmnaming/
2. Create the following file in this directory:
/usr/local/osmosix/callout/vmnaming/callout.conf
3. Create a file for the script:
/usr/local/osmosix/callout/vmnaming/<script name>
4. Ensure to execute permissions:
chmod 777 <script>
5. Reference this file in the callout.conf file.
The vmNaming Callout Script
This script allows you to change the name of the VM. See VM (Node) Name Config to rename the VM using the CCM UI for Azure, OpenStack,
VMware, and AWS clouds.
The supported environment variables for the vmNaming script:
Variable
Sample value or type
eNV_JOB_ID
integer (application VM only)
eNV_launchUserId
integer
eNV_launchUserName
string
The supported key for the vmNaming script:
CloudCenter-Required Key
Description
vmNaming
Name of the VM
A sample vmNaming callout script output:
run.sh
#!/bin/bash
echo "vmName=`uuidgen`"
The IPAM Callout Script
Cisco CloudCenter Integration Guide
10
Cisco CloudCenter Documentation
Supported Clouds: AWS, VMware, and OpenStack.
You will ALSO need to enable the region for the IPAM Naming Strategy as identified in the VM Name Config > Instance IPAM Strategy
section.
As part of the integration, create a IPAM module and include the dynamically-invoked callout script when launching the CCO. The module can be
dynamically loaded/reloaded (auto-load) or loaded at CCO start-up time. By default, auto-load is disabled.
The IPAM module's callout script includes (but is not restricted to) the following parameters:
DNS server list
DNS suffix list
Number of vNIC
Number of vNIC’s IP address
Numbers of vNIC’s netmask
VM name
Once the script is executed, all deployments for that cloud discover IP addresses managed by the IPAM module.
The callout script path is /usr/local/osmosix/callout, where each module is a sub-folder under the script path.
Example
UserClusterName="cluster01"
eNV_Cloud_Setting_UserDataCenterName="dc02"
eNV_NumTasks="1" eNV_UseBatchTaskList="0"
eNV_Cloud_Setting_UserResourcePoolName="resourcepool1"
eNV_Cloud_Setting_UserClusterName="cluster01"
Supported Properties
The multiple key-value pair that is output for each callout script.
Key
Description
Required?
osHostname
The OS hostname
Yes.
Not supported for Amazon and
OpenStack.
DnsServerList
DNS server list (comma separated)
DnsSuffixList
DNS Suffix list (comma separated)
nicCount
The number of virtual NICs (vNICs)
Yes
The nicCount parameter only allows
one NIC to be used at any time.
nicIP_n
Nth vNIC’s IP address
Yes
nicNetmask_n
Nth vNIC’s netmask
Yes
nicGateway_n
Nth vNIC’s gateway (CCO) IP address
Yes
nicDnsServerList_n
Nth vNIC’s DNS server list (comma separated)
Yes
nicUseDhcp_0
As part of the IPAM script, provide dummy values for nicIP_n and
nicDnsServerList_n. However, these values are overwritten by the DHCP
settings.
Yes, if using IPAM callout and the
addressing is assigned to use DHCP.
ANY
This property is supported if the reinject setting is true
Example: myCustomParam=myValue
If the VM configuration includes multiple NICs, then the CloudCenter platform makes one IPAM call per NIC. You can also assign
multiple IPs to each NIC by using keys with _n suffix as described earlier.
Cisco CloudCenter Integration Guide
11
Cisco CloudCenter Documentation
OS-Specific IPAM Properties
The multiple key-value pair that is output for each callout script.
IPAM Properties
timezone
Linux
Windows
Required?
Supported for VMware.
Not used
Yes
The Windows Index ID for this time zone.
Yes
Not supported for Amazon and OpenStack.
timeZoneId
Not used
For Windows-specific VMware IPAM config scripts, be aware
that you may only see the changes in effect after the
deployment has been completed for an undetermined period
of time.
Amazon: No effect as instance timing is internally managed
fullName
Not required
The name of the Admin user
Yes
organization
Not required
The name of the organization (string)
Yes
productKey
Not required
The Windows product key
Yes
setAdminPassword
Not required
The Admin password
Yes
changeSid
Not used
A true or false value for the Microsoft SID
Yes
You must set the changeSid option to true.
deleteAccounts
Not used
A true or false value.
Yes
dynamicPropertyName
Not used
Reserved name holder for arbitrary property
Yes
dynamicPropertyValue
Not used
Reserved value holder for arbitrary property
Yes
custSpec
The Guest Customization Specification
name in VMware
The Guest Customization Specification name in VMware
No
hwClockUTC
Not supported for VMware and OpenStack.
Not supported for VMware and OpenStack.
Yes
Amazon: No effect, as the clock is internally
managed.
Amazon: No effect, as the clock is internally managed.
Linux domain name
Used to automatically join a domain
domainName
Yes
If you do not specify
the domainName, the
CloudCenter platform sets it to
the default value, mydomain.
Be sure to provide this value if
you do not want to use the
default mydomain value.
Not supported for Amazon and OpenStack.
domainAdminName
Not used
Used to automatically joining a domain
domainAdminPassword
Not used
Used to automatically joining a domain
workgroup
Not used
The workgroup in which to place the VM.
If any of the 3 domain values are missing, the workgroup key is
required.
If all three domain values are present, the workgroup is not required.
Windows-Specific Example
Cisco CloudCenter Integration Guide
12
Cisco CloudCenter Documentation
run.sh
#!/bin/bash
echo
echo
echo
echo
echo
echo
"setAdminPassword=abcd"
"timeZoneId=10 *"
"fullName=Enterprise ABCD"
"organization=ABCD"
"productKey=..."
"changeSid=true"
Sample IPAM Callout Script
run.sh
#!/bin/bash
echo "DnsServerList=8.8.8.8,10.0.0.100"
echo
echo
echo
echo
echo
"nicCount=2"
"nicIP_0=10.0.0.100"
"nicDnsServerList_0=1.2.3.4,5.6.7.8"
"nicGateway_0=10.0.0.1"
"nicNetmask_0=255.255.255.0"
echo
echo
echo
echo
"nicIP_1=192.1.0.100"
"nicDnsServerList_1=10.10.10.10"
"nicGateway_1=192.1.0.1"
"nicNetmask_1=255.255.255.0"
echo
echo
echo
echo
"domainName=test.org"
"hwClockUTC=true"
"timeZone=Canada/Eastern"
"osHostname=testhost1"
The ipamDealloc Callout Script
The ipamDealloc script allows you to cleanup your environment and only works with custom property supported by reinject setting.
ipamDealloc example:
run.sh
#!/bin/bash
./delete_record_by_ip.sh $IP
The CloudCenter platform does not look for any output from this script as it is just a notification.
Sample Callout Workflow
Cisco CloudCenter Integration Guide
13
Cisco CloudCenter Documentation
Sample IPAM Callout
#!/usr/local/bin/python2.7
import infoblox, sys, requests, os, random
requests.packages.urllib3.disable_warnings()
#Assign command line arguments to named variables
hostname = os.environ['vmNaming']
domain = "vm.cloudcenter.com"
fqdn = hostname + "." + domain
network = "10.49.18.0/23" #sys.argv[2]
netmask = "255.255.254.0"
gateway = "10.49.19.254"
dns_server = "10.48.112.33,10.52.112.19"
#Setup connection object for Infoblox
iba_api = infoblox.Infoblox('10.49.9.163', 'admin', 'infoblox', '1.4',
iba_dns_view='VM-view', iba_network_view='default', iba_verify_ssl=False)
try:
#Create new host record with supplied network and fqdn arguments
ip = iba_api.create_host_record(network, fqdn)
print "DnsServerList="+dns_server
print "nicCount=1"
print "nicIP_0=" + ip
print "nicDnsServerList_0="+dns_server
print "nicGateway_0="+gateway
print "nicNetmask_0="+netmask
print "domainName="+domain
print "HWClockUTC=true"
print "timeZone=Canada/Eastern"
print "osHostname="+hostname
print "infobloxFQDN="+fqdn
except Exception as e:
print e
Resource Placement and Validation
Overview
Resource Placement Flow
Resource Validation Flow
Overview
The CloudCenter platform has ability to deploy enterprise applications over public, private, or hybrid clouds by configuring user-specified cloud
settings in the CCM UI > Deployments page.
Effective CloudCenter 4.7.0, the following integration capabilities extend the CloudCenter platform capabilities:
Resource Placement allows users to define cloud settings based on third-party infrastructure tools or quota management tools using
automated scripts instead of manually-selected settings.
Resource Validation blocks new deployments, if users reach a configured threshold limit when using Cloud Resources (for example,
restricting VMs being launched only if cloud resources consume < 75% of your maximum capacity).
You can configure these integrations using an automation callout script.
Cisco CloudCenter Integration Guide
14
Cisco CloudCenter Documentation
Resource Placement Flow
The Resource Placement feature is only supported for Amazon and VMware clouds.
This script is executed for each Node launch. For example, if you have a single-tier application with the minimum number of nodes set to 2,
then this script is executed twice – 1 tier x 2 nodes = 2 executions.
1. Define Resource Callout by enabling the Resource Callout feature on the CCM UI > Deployments > Environments tab > Add a new or
edit an existing deployment environment > Define Deployment Environment Defaults (see Deployment Environment Defaults for
additional context).
2. Toggle the switch to YES in the Resource Placement section.
If this feature is enabled, the Cloud Settings form in the Deployment Environments > Cloud Defaults page will be disabled.
3. Identify the script location and the specific script for the Resource Placement Configuration.
4. Be aware of the customizable options for AWS and VMware:
AWS Options
Amazon-specific cloud settings for the resource placement callout script:
AWS Setting
Description
vpdId
The VPC for the node to be deployed
subnetId
The subnet where the node should be deployed in the above VPC
securityGroupList
The security groups where the node should be associated in the above VPC
vmTagsList
The AWS tags to associate with the node
assignPublicIp
Identifies if the node should be assigned with a public IP
nodeInfo
Customizable node Information detail that is displayed in the CCM UI Job Details Page for
each node. If not provided CloudCenter generates the default nodeInfo based on the
provided values.
Sample Amazon Resource Placement Callout Script
#!/bin/bash
. /utils.sh
content="{\"vpcId\":\"vpc-1234abcd\",
\"subnetId\":\"subnet-1234abcd\",
\"securityGroupList\":\"sg-1234abcd\",
\"vmTagsList\":\"Name:MyVm,PayProfile:Dev,BU:Engineering,User:DemoU
ser\",
\"assignPublicIp\":\"true\", \"nodeInfo\":\"VpcID:
vpc-1234abcd, subnetId:
subnet-1234abcd,securityGroupList:sg-1234abcd \"}"
print_ext_service_result "$content"
VMware Options
Cisco CloudCenter Integration Guide
15
Cisco CloudCenter Documentation
VMware-specific cloud settings for the resource placement callout script:
VMware Setting
Description
vmTagsList
The AWS tags to associate with the node
UserDataCenterName
The datacenter to deploy the node
UserClusterName
The cluster to deploy the node in the above datacenter
UserResourcePoolName
The resource pool used to deploy the node
UserDatastoreCluster
The datastore cluster to associate with the node
UserFolderName
The user folder used for the node deployment
RootDiskResizable
Identifies if the the root disk is resizable (Boolean: true/false)
FullClone
Identifies if the node to be launched is with full clone (Boolean: true/false)
VmRelocationEnabled
Identifies if node relocation is enabled (Boolean: true/false)
LocalDataStoreEnabled
Boolean if local datastore is enabled (Boolean: true/false)
SystemFolderName
The folder from which the template is selected
networkList
The list of networks to attach to the node
UserHost
The ESX host to which the node is launched
nodeInfo
Customizable node Information detail that is displayed in the CCM UI Job Details
Page for each node. If not provided CloudCenter generates the default nodeInfo
based on the provided values.
Sample VMware Resource Placement Callout Script
#!/bin/bash
. /utils.sh
content="{\"UserDataCenterName\":\"SDC-01\",\"UserClusterName\":\"C
loudCenter-Cluster\",\"UserResourcePoolName\":\"\",\"vmTagsList\":\
"cloud:center\",\"UserDatastoreCluster\":\"CloudCenter-DS-Cluster\"
,
\"RootFolderName\":\"vm\",
\"UserFolderName\":\"CliqrUser-2\",
\"RootDiskResizable\":\"false\”,
\"FullClone\":\"true\",
\"VmRelocationEnabled\":\"true\",
\"LocalDataStoreEnabled\":\"true\",
\"SystemFolderName\":\"CliqrTemplates\",
\"networkList\":\"VLAN-ENG-NET (CC-DSwitch)\",
\"UserHost\":\"sc2-esx02.abc.private\",\"nodeInfo\":\"UserDataCente
rName:
SDC-01, UserClusterName: CloudCenter-Cluster,
UserDatastoreCluster:CloudCenter-DS-Cluster, networkList
VLAN-ENG-NET
(CC-DSwitch)\"}"
print_ext_service_result "$content"
a. Available environment variables for the Resource Placement script:
Cisco CloudCenter Integration Guide
16
Cisco CloudCenter Documentation
a.
Environment Variable
Description
eNV_cliqrAppTierName
The tier name
CliqrTier_<tierName>_instanceType
The Instance Type of the tier
eNV_imageName
The image Name (for example: CentOS 6.x)
serviceName
The service name to identify settings like private subnet for a database
service
eNV_parentJobName
The unique Job Name for the deployment
CliqrCloudAccountId
The CloudCenter cloud account ID
CliqrCloudAccountPwd
The CloudCenter cloud account secret key
CliqrCloudAccountName
The CloudCenter cloud account access key and username
Sample VMTurbo Integration Script for Resource Placement for
Vmware
#!/bin/bash
. /utils.sh
export VMTURBO_URL="<VM_TURBO_HOST>"
export VMTURBO_USER="<User>"
export VMTURBO_PASSWORD="<pwd>"
export
VMTURBO_RESOURCE="http://$VMTURBO_USER:$VMTURBO_PASSWORD@$VMTURBO_U
RL"
. /utils.sh
#pre fixing a datacenter in the sample
if [ -z $dcName ];
then
export dcName="SCL2"
fi
export
export
export
export
export
export
export
export
export
export
export
export
vmTagsList="Name:myVm"
UserDataCenterName="$dcName"
UserClusterName="CliQr"
UserResourcePoolName="Eng"
RootFolderName="vm"
UserFolderName="CliqrUser-id"
RootDiskResizable="false"
FullClone="true"
VmRelocationEnabled="true"
LocalDataStoreEnabled="true"
SystemFolderName="CliqrTemplates"
networkList="10-DEV (DSwitch)"
export instanceNameVar=`echo
CliqrTier_"$eNV_cliqrAppTierName"_instanceType`
eval instanceName='$'$instanceNameVar
getProfileId() {
result=`curl -s -X GET $VMTURBO_RESOURCE/vmturbo/api/templates
| grep $instanceName`
Cisco CloudCenter Integration Guide
17
Cisco CloudCenter Documentation
export profileId=`echo $result | awk -F uuid=\" '{printf $2}' |
awk -F \" '{printf $1}'`
}
getProfileId
getDatacenterId() {
DATACENTER=$1
result=`curl -s -X GET
$VMTURBO_RESOURCE/vmturbo/api/markets/Market/entities | grep
\"DataCenter\" | grep $DATACENTER`
export dcId=`echo $result | awk -F
uuid=\" '{printf $2}' | awk -F \" '{printf $1}'`
}
getDatacenterId "$dcName"
#echo "dcId=$dcId"
getReservation() {
reservationName="reserve-$RANDOM"
export reserveId=`curl -s -X POST
$VMTURBO_RESOURCE/vmturbo/api/reservations -d
"reservationName=$reservationName&templateName=$profileId&count=1&s
egmentationUuid[]=$dcId"`
}
getReservation
sleep 3
getHostAndDS() {
result=`curl -s -X GET
$VMTURBO_RESOURCE/vmturbo/api/deployitems/$reserveId`
export datastore=`echo $result | awk -F datastore=\" '{printf
$2}' | awk -F \" '{printf $1}'`-cluster
export host=`echo $result | awk -F host=\" '{printf $2}' | awk
-F
\" '{printf $1}'`
}
getHostAndDS
export UserDatastoreCluster="$datastore"
export UserHost="$host"
content="{\"UserDataCenterName\":\"$dcName\",\"UserClusterName\":\"
$UserClusterName\",\"UserResourcePoolName\":\"$UserResourcePoolName
\",\"vmTagsList\":\"$vmTagsList\",\"UserDatastoreCluster\":\"$UserD
atastoreCluster\",
\"RootFolderName\":\"$RootFolderName\",
\"UserFolderName\":\"$UserFolderName\",
\"RootDiskResizable\":\"$RootDiskResizable\”,
\"FullClone\":\"$FullClone\",
\"VmRelocationEnabled\":\"$VmRelocationEnabled\",
\"LocalDataStoreEnabled\":\"$LocalDataStoreEnabled\",
\"SystemFolderName\":\"$SystemFolderName\",
\"networkList\":\"$networkList\",
\"UserHost\":\"$UserHost\",\"nodeInfo\":\"UserDataCenterName:
$dcName, UserClusterName: $UserClusterName, UserDatastoreCluster:
Cisco CloudCenter Integration Guide
18
Cisco CloudCenter Documentation
$UserDatastoreCluster, networkList: $networkList \"}"
print_ext_service_result "$content"
Resource Validation Flow
The Resource Placement feature is supported for all CloudCenter supported clouds.
To configure the Resource Validation feature, follow this procedure.
1. Define Resource Callout by enabling the Resource Validation feature on the CCM UI > Deployments > Environments tab > Add a new
or edit an existing deployment environment > Define Deployment Environment Defaults (see Deployment Environment Defaults for
additional context).
2. Toggle the switch to YES in the Resource Validation section.
3. Identify the script location and the specific script for the Validation Configuration.
Sample Resource Validation Callout Script
#!/bin/bash
. /utils.sh
content="{\"validated\":\"false\",\"comment\":\"Not Enough Resources to
Launch the nodes\"}"
print_ext_service_result "$content"
Available environment variables for the Resource Validation script:
Environment Variable
Description
CliqrCloudAccountId
The CloudCenter cloud account ID
CliqrCloudAccountPwd
The CloudCenter cloud account secret key
CliqrCloudAccountName
The CloudCenter cloud account access key and username
CliqrTier_NameList
The comma separated list of all tiers in the application – loop this variable for each
tier in the script
CliqrTier_Total_NumCpus
The total vCpus required to launch the complete App
CliqrTier_Total_Memory
The total memory required to launch the complete App
CliqrTier_Total_Local_Storage
The total local storage required to launch the complete App.
CliqrTier_<tierName>_instanceType
The Instance Type for the tier
CliqrTier_<tierName>_instanceName
The Instance Type name (logical name) for the tier
CliqrTier_<tierName>_cloudType
The Cloud Type for the tier.
CliqrTier_<tierName>_numOfCPUs
The number of CPU’s required for the tier
Cisco CloudCenter Integration Guide
19
Cisco CloudCenter Documentation
CliqrTier_<tierName>_memorySize
The memory required for the tier
CliqrTier_<tierName>_localStorageSize
The local storage required for the tier
CliqrTier_<tierName>_minClusterSize
The cluster size of the tier that is launched – Total vCPUs required for a tier would
be minClusterSize x numOfCPUs
Infoblox
Overview
Prerequisites for IPAM Integrations
Setup the IPAM Module
The Infoblox API
The Callout Configuration File
Overview
The CloudCenter platform supports IP Address Management (IPAM) integration to manage IP address for deployments.
This section provides information on integration with Infoblox, an IPAM provider, by executing multiple callout scripts on the CCO. See Callout
Scripts for additional information on each callout script.
See the InfloBlox Integration video for a short demonstration of how the CloudCenter platform supports Infoblox for IP address and DNS name
assignment.
Prerequisites for IPAM Integrations
See Callout Scripts for cloud support details.
If you make changes to the callouts or attributes for a Cloud Region, you must restart the CCO for the changes to take effect.
Setup the IPAM Module
1. Contact CloudCenter Support to obtain the module templates and save it to /usr/local/osmosix/callout.
2. Make changes to callout scripts according to your test environment.
3. Model a sleep job, add some environment variables, run the job and check the callout log, and verify that the variables are exported
correctly.
4. Model a multi-tier web app, add some environment variables, run the job, check the callout log, and verify that the variables are exported
correctly.
The Infoblox API
Use the Infoblox-API-Python module to integrate with Infoblox.
The following example displays a script that uses the Infoblox-API-Python module. This script requires python-requests 2.5 and can be called
directly from the callout:
Cisco CloudCenter Integration Guide
20
Cisco CloudCenter Documentation
createHost.py
#!/usr/local/bin/python2.7
import infoblox, sys
#Check to see if command line included enough arguments.
if (len(sys.argv) < 3):
print "Usage: createHost.py <fqdn> <network CIDR>"
quit()
#Assign command line arguments to named variables
fqdn = sys.argv[1]
network = sys.argv[2]
#Setup connection object for Infoblox
iba_api = infoblox.Infoblox('10.110.1.45', 'admin', 'infoblox', '1.6', 'default',
'default', False)
try:
#Create new host record with supplied network and fqdn arguments
ip = iba_api.create_host_record(network, fqdn)
print "nicCount=1"
print "nicIP_1=" + ip
except Exception as e:
print e
The Callout Configuration File
This is an example of integrating callout with the Infoblox application.
callout.conf
name=infoblox
type=exec
topic=ipam
debug=true
executable=createHost.py
reinject=true
disabled=false
Jenkins
Overview
The CloudCenter Jenkins Plugin
Prerequisites
Install the CloudCenter Jenkins Plugin
The jenkinsBuildId Macro
Create a New Deployment on Every Build
Update an Existing Deployment
Overview
For pre-modeled Jenkins projects (for example, Maven, to fetch the source code from Git/SVN), you can integrate with CloudCenter using the Clo
udCenter Jenkins plugin.
You do not need to manually copy this file, CloudCenter provides a download URL to make this plugin available to Jenkins users. Contact CloudC
enter Support to obtain the download location.
Cisco CloudCenter Integration Guide
21
Cisco CloudCenter Documentation
The CloudCenter Jenkins Plugin
The CloudCenter Jenkins plugin provides complete integration between Jenkins and CloudCenter by allowing users to directly launch
deployments on any Supported Cloud from a Jenkins server.
Additionally, users can upgrade an existing deployment by specifying upgrade scripts for each tier.
Prerequisites
If you are new to Jenkins, setup a maven project on Jenkins with Github as its source repository. See http://www.youtube.com/watch?v=l
TQGi5jzjvo for additional details.
The supported Jenkins versions value must be >=1.624 to use the CloudCenter Jenkins plugin.
The required Java version for the Jenkins server must be Java 7.
You must set the default cloud settings in the Deployment Environments so the Jenkins Plugin can fetch and use those cloud settings
when you deploy the application.
The Jenkins plugin for CloudCenter 4.6.x requires the APIs associated with CloudCenter 4.6.x (for example, the Jenkins plugin uses v2
CloudCenter APIs for job deployment and the v2 APIs are only available in CloudCenter 4.6.x).
To ensure a successful connection between the Jenkins server and the CCM, be sure to import the certificate from the CCM into the
Jenkins trusted Java key store (see Certificate Authentication for additional context).
Install the CloudCenter Jenkins Plugin
To install the CloudCenter Jenkins plugin, follow this procedure:
1. Contact CloudCenter Support to obtain the download link for the CloudCenter Jenkins plugin.
2. Log into CCM using your admin credentials.
3. Generate the API Management (Access) Key for the Jenkins user.
4. Model the Application so this user can access artifacts from the Jenkins build server.
5. In Jenkins, go to Manage Jenkins > Manage Plugins > Advanced > Upload Plugin to upload and install the CloudCenter Jenkins
Plugin.
Cisco CloudCenter Integration Guide
22
Cisco CloudCenter Documentation
Cisco CloudCenter Integration Guide
23
Cisco CloudCenter Documentation
6. After you install theCliQrJenkinsPlugin, go to your existing/new project to configure post-build step and fetch the source code from the
Git/SVN using a Maven project into the Jenkins Build.
Cisco CloudCenter Integration Guide
24
Cisco CloudCenter Documentation
Configure the CloudCenter Application Deployment Client in Jenkins for continuous integration from build system and deployment (new
or upgrade on an existing node).
The parameters for the CloudCenter Application Deployment Client page are listed in the following table:
Parameter
Description
Cisco CloudCenter Integration Guide
25
Cisco CloudCenter Documentation
Cisco
CloudCenter
CCM URL
The the IP address of the CCM server. Verify that trusted certificates (see Certificate Authentication for additional
context), are added to the CCM server (not self-signed certificates).
Username
Username listed in the Manage Access Key section (see API Authentication for additional context).
AccessKey
The API Management Key for the user listed in the he Manage Access Key section (see API Management Key for
additional context).
Deploy to
Project
Use this flag to deploy to a project, instead of a general deployment environment (see Projects and Phases for
additional context).
Project Name
If you select the Deploy to Project flag, this parameter is displayed and the list of projects are fetched from the CCM
server. Based on this parameter value, only applications associated with this project are filtered out in the Applicatio
n Version field.
Project Phase
Based on the project name, a dropdown list of all Phases in that project are displayed. Use this value in the
Deployment Environment field to filter the project.
Application
Name
From the dropdown list of applications listed in the CCM UI, select the required application to deploy.
After entering your credentials, be prepare to wait for some time as the Application Management APIs API
s may take a while to load.
Application
Version
Based on your application, select the application version from this dropdown list.
Deployment
Environment
Select the required deployment environment to deploy your application. Be sure to verify and check all default
settings like default cloud, default instance type, and so forth as CloudCenter uses these default settings for each
deployment.
Cloud Type
Select one cloud type from this dropdown list of cloud types that are present in your deployment environment.
Cloud Account
The cloud account with which you deploy the application.
Instance Type
Select a single instance type as the default instance type.
Tags
A comma-separated list of tags associated with this job.
AppParameters
A comma-separated list of key-value pairs to pass as global parameters. For example:
abcd=wow, cdef=cliqrRocks
CloudCenter includes the $BUILD_ID, $BUILD_NUMBER, $BUILD_TAG, $JOB_NAME, and if available,
$BUILD_TIMESTAMP from other plugins.
You can add a variable in this section to fetch parameters that are shared by other jobs. For example:
abc=${BUILD_PARENT_NUMBER} or abc=$BUILD_PARENT_NUMBER
You also have the option to retrieve parameters from the $WORKSPACE/appParams file that contains multiple lines
of key-value parameter pairs. You can then uses these parameters to pass passwords or other sensitive information
without displaying them in the CCM UI.
Choose the
binaries to be
Copied
Identifies if the files must be copied to an external location
Copy Binaries to External Location – all your binaries will be available under /tmp/app1/latest
Don't copy Binaries – the binaries will not be copied to any other location
Cisco CloudCenter Integration Guide
26
Cisco CloudCenter Documentation
Choose the
Deployment
Behavior
You can only do this once for deployments.
Create a new Deployment on every Build: This option creates a brand new deployment for every build.
Stop Old Deployment if exists: This option creates a brand new deployment for every build and stops the
older deployment if it exisits.
Update Existing Deployment (Create new if doesn't Exist):
Updates a previous deployment that was launched from the CloudCenter Jenkins plugin during a previous
build for the same project.
If the previous deployment is still in progress (job) and is not yet in the Running state, the CloudCenter Jen
kins plugin waits till the deployment is in the running state before triggering an update (see Deployment and
VM States for additional context).
If the previous deployments ends up as an error or if that deployment is stopped or cancelled from the
CCM server, the CloudCenter Jenkins plugin launches a new deployment as part of the Update process.
If this is the first build, the CloudCenter Jenkins plugin creates a new Deployment and from the next
successful build it uses the existing deployment.
UpdateScripts: A comma separated list of tierName:scriptToExecute scripts that are executed in the order
mentioned here. For example:
AppCluster:/shared/app/petclinic/update.sh,Database:/shared/app/updatemysql.sh, AppCluster:/shared/ap
p/startServer.sh
Wait For Deployment And Export Details: Waits for Deployment to enter the Running state and exports the
Job Details to the $WORKSPACE/userenv file
The jenkinsBuildId Macro
In Update Scripts, $BUILD_ID or %jenkinsBuildId% can be passed as an argument to point the Binaries to be Copied during an update
deployment.
The %jenkinsBuildId% macro is not an applications-specific macro. This CloudCenter-defined macro applies to deployments that are
launched using the Jenkins plugin.
The jenkinsBuildId macro is mainly used to pass the Jenkins Build ID to the userenv of the app deployment. Any deployment triggered by the
Jenkins plugin will automatically have jenkinsBuildId in the userenv and will be used to point to the right binaries in repo/storage. For example, if a
web server has a previous war file path set to /shared/app/petclinic/latest/, then this war file (petclinic.war) can now use this macro to point to
/shared/app/petclinic/%jenkinsBuildId%/petclinic.war.
In update deployment scenarios, the jenkinsBuildId macro changes the value that should be passed to existing deployments as userenv has old
the jenkinsBuildId value during the deployment.
The folder name that CloudCenter creates in the target location will now use the jenkinsBuildId value instead of the random timestamp value.
Create a New Deployment on Every Build
This option creates a Brand new deployment on every build.
Update an Existing Deployment
When you update an existing deployment:
It updates a previous deployment that is launched from the Jenkins plugin during the previous builds of the same project.
If the previous deployment job is still in progress and is not in the Running state, the plugin waits till it enters the running state and then
triggers an update.
If the previous deployments ends in an error or if that deployment is stopped/cancelled from the CCM, the plugin launches a fresh
deployment as part of update.
If it is the first build, this plugin creates a new deployment and for the next successful build it uses the existing deployment.
If you receive a security group error, be sure to verify if more than one system is accessing the same account.
SSO
SSO AD
SAML SSO
Use Case: Shibboleth SSO
Use Case: ADFS SAML SSO
Cisco CloudCenter Integration Guide
27
Cisco CloudCenter Documentation
SSO AD Integration
Overview
User Authentication
Handling Deleted Users
Overview
Some enterprises have their own Active Directory (AD) or other similar setup and prefer to use those credentials to login into the external
applications and platforms. CloudCenter does not support direct AD authentication, and instead supports integration using Single Sign-On (SSO)
between the CloudCenter as a Service Provider (SP) and a customer's Identity Provider (IDP) such as ADFS.
CloudCenter supports a multi-tenant model where each vendor is modeled as a tenant. The tenants have a single root hierarchical tree structure.
Each tenant has its' own set of users. One of the users is a tenant admin (also referred to as the root admin or platform admin) that has special
administrative permissions.
CloudCenter does not authenticate directly to LDAP or AD.
CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping
Identity, ADFS, Shibboleth, and so forth).
To implement SSO using CloudCenter:
1. You must then configure the CCM to re-direct the authentication to the SSO IDP.
2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.
3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and
additional roles and permissions.
CloudCenter 4.7.2.1 Change
On Mar. 3, 2017 a certificate used by Single Sign On (SSO) users expired and caused logins to the CCM UI to fail with an invalid
username/password error. CloudCenter 4.7.2.1 includes the updated certificate.
If you Upgrade to CloudCenter 4.7.2.1, you must still follow the procedure provided the CloudCenter 4.7.2x Release Notes > Integration
s section.
User Authentication
Despite a user (User X) being authenticated by an external Identify Provider (IDP), User X also requires a corresponding presence in the CCM
VM's user database. In the SSO environment, after User X is authenticated by IDP and uses the CCM VM for the first time, a User X
authentication is automatically created in the CCM user database as long as the platform admin has created the tenants and tenant admins.
Each tenant can point to it's own SSO:
You can configure each tenant to have a dedicated alias hostname and use an external IDP to authenticate its users.
Each tenant and user has an externalId to associate with an external organization and user.
Cisco CloudCenter Integration Guide
28
Cisco CloudCenter Documentation
Handling Deleted Users
If you delete a user from the IDP database, the deleted user cannot log into CloudCenter but any configuration and associated dependencies
continue to remain in the CloudCenter platform.
SAML SSO Integration
Overview
CloudCenter Support
SAML Authentication Configuration
Other References
Overview
CloudCenter does not authenticate directly to LDAP or AD.
CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping
Identity, ADFS, Shibboleth, and so forth).
To implement SSO using CloudCenter:
1. You must then configure the CCM to re-direct the authentication to the SSO IDP.
2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.
3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and
additional roles and permissions.
A CCM instance supports Security Assertion Markup Language (SAML) 2.0 SSO through Spring Security SAML Extension.
The SysAdmin can set up SAML integration at the root level or the tenant level. To accurately configure this integration, you must have the
following information for the root tenant or sub-tenant (as applicable to your deployment):
Tenant configuration information
Activation profile information
CloudCenter 4.7.2.1 Change
On Mar. 3, 2017 a certificate used by Single Sign On (SSO) users expired and caused logins to the CCM UI to fail with an invalid
username/password error. CloudCenter 4.7.2.1 includes the updated certificate.
If you Upgrade to CloudCenter 4.7.2.1, you must still follow the procedure provided the CloudCenter 4.7.2x Release Notes > Integration
s section.
CloudCenter Support
Contact CloudCenter Support for additional information.
SAML Authentication Configuration
To configure a tenant to use SSO, follow this procedure:
1. Create a tenant (see Sub-Tenant Configuration)
a. Short Name – give a string without white spaces and special characters.
b. External Id – enter the ID of the organization in the external system with which the tenant is associated.
c. Tenant – the CCM server domain name alias for the tenant. This will serve as the end point of the Service Provider (SP) from the
SSO perspective.
2. Login as the newly created tenant admin and create an Activation Profiles.
3. Click the Tenant Info tab and select the newly created activation profile as Default Activation Profile.
4. Gather the IDP information to see what Subject Attribute the IDP will provide and create a IDP Subject Attribute to the User Property
mapping plan.
5. Login as SysAdmin (see Admin Users > Login as a System Admin), click the Manage Vendor Admins tab and select the Authenticatio
Cisco CloudCenter Integration Guide
29
Cisco CloudCenter Documentation
5.
n Settings action item.
6. Enter the information in the IDP Settings, SP Settings and Attribute Mappings sections and click Submit.
IDP Metadata: To establish the mutual trust between the CloudCenter platform and the IDP.
Entity ID: The target domain name for this authentication
Logout URL: If you are logging into your company's SAML page, you must specify the URL of the page that you want the logged
in users to be redirected to when they log out of the SAML page.
Attribute Mapping Section: These are the fields from the IDP that will be mapped to user attributes within the CloudCenter
platform. If you are unsure about these fields, please contact your IDP administrator. At a minimum, you need to provide the first
name, last name, email address, and external User ID.
User Group: Specify the field name from the IDP that will be used to determine the group to which the user belongs.
Activation Profiles Reference: Identify an attribute in your metadata to pick an associated activation profile instead of the
Cisco CloudCenter Integration Guide
30
Cisco CloudCenter Documentation
default profile.
1st/2nd Level Vendor External ID: Used to automate the placement of the SSO self signup users in the correct tenant.
Used in conjunction with setting an External ID when creating a sub-tenant to automate SSO user placement in the right
tenants. For example:
If an organization has a 3-level hierarchy with :
The top level organization = the root organization
Each user has a unique User ID (UID) regardless of their organization.
The 1st-level organization (sub-tenant)= Company1
Each Company1 user has an unique external identifier = Company1_uid.
The 2nd-level organization (sub-tenant) = Company1_c (each Company can have zero or more
departments or customers within)
Each department or customer user has a unique external identifier = Company1_c_uid
The combination of Company1_uid and Company1_c_uid is used to locate the organization for a user:
A user without Company1_uid and Company1_c_uid is placed in the root organization
A user with only Company1_uid is placed in the:
1st-level sub-tenant
External ID matches the user's Company1_uid
A user with both a Company1_uid and Company1_c_uid is placed in the:
2nd-level sub-tenant
External ID
2nd-level sub-tenant matches the user's Company1_c_uid
1st-level sub-tenant matches the user's Company1_uid
The default behavior is that if the value of the field mapped to Vendor IDs is blank then users are placed in the root tena
nt.
You can configure the default mapping and block users by providing a value in the Vendor ID fields, but it doesn't match
the value set for the tenant(s)
If you map values for the 1st and 2nd level vendor and the External IDs that don't match the External IDs of
any tenant, then these users are not granted access.
7. Download the SP Metadata and send it to the IDP administrator to register the SP.
Other References
See the Ping Identity knowledge Base for an example of mapping IDP groups to SP groups.
Cisco CloudCenter Integration Guide
31
Cisco CloudCenter Documentation
Shibboleth SSO Integration Use Case
CloudCenter Support
Install Shibboleth
Configure Shibboleth
CloudCenter Support
Contact CloudCenter Support for additional information.
CloudCenter does not authenticate directly to LDAP or AD.
CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping
Identity, ADFS, Shibboleth, and so forth).
To implement SSO using CloudCenter:
1. You must then configure the CCM to re-direct the authentication to the SSO IDP.
2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.
3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and
additional roles and permissions.
Install Shibboleth
1. Prepare Ubuntu base image with Tomcat 6.
The following instructions are for Tomcat6 (as Tomcat 7 has limitations).
You can also use Jetty 7, however, the following instruction will differ if you use Jetty.
2. Download the latest Shibboleth IDP software from here http://shibboleth.net/downloads/identity-provider/latest/ to /shib-distro/.
3. Unzip the archive :
sudo unzip /opt/shib-disto/shibboleth.zip
4. Copy files from the endorsed directory to Tomcat.
sudo cp /shib-disto/shibboleth/endorsed/* /usr/local/tomcat6/endorsed/".
You may need to make this the endorsed directory:
sudo mkdir /usr/local/tomcat6/endorsed
5. Download tomcat6-dta-ssl-1.0.0.jar and copy to TOMCAT_HOME/lib:
sudo cp /tmp/tomcat6-dta-ssl-1.0.0.jar /usr/local/tomcat6/lib
6. Install Shibboleth:
a. cd /shib-distro/shibboleth/
b. sudo ./install.sh
c. Press Enter to accept default install path of /opt/shibboleth-idp.
d. Press Enter to accept the Fully Qualified Domain Name (FQDN) of server (for example, idp01.cloudcenter.com).
e. Enter a password to create the keystone.
7. Turn Off Certificate checking for Attribute requests (see Disabling Web Server CA Validation for Attribute Requests for additional
information). The alternative is to make sure certs from your SP (service provider) in our case the CCM server are trusted by Shibboleth.
a. As root copy the Shibboleth-AnyCert.jar file, which is a security provider for java, to your JRE lib/ext directory.
wget http://www.switch.ch/aai/downloads/Shibboleth-AnyCert.jar
cp Shibboleth-AnyCert.jar ${JAVA_HOME}/jre/lib/ext/Shibboleth-AnyCert.jar
b. Add the following security provider to ${JAVA_HOME}/jre/lib/security/java.security by adding a line to the security.provider
section:
security.provider.7=edu.internet2.middleware.shibboleth.quickInstallIdp.
AnyCertProvider
Step c. is included in Step 8 below when you configure the whole connector. If you do not have an existing
truststore, you must create a truststore first.
c. In your ${CATALINA_HOME}/conf/server.xml file, configure the Attribute Authority Connector that needs client
authentication to use the AnyCert truststore algorithm as displayed in the following example:
Cisco CloudCenter Integration Guide
32
Cisco CloudCenter Documentation
<Connector [... other settings ...]
truststoreFile="/etc/shibboleth/truststore.jks"
truststorePass="$TRUSTSTORE_PASSWORD$"
truststoreAlgorithm="AnyCert"
/>
Although Tomcat should never use the truststore for this connector, it is also essential to specify a truststore that contains at
least one certificate, even if it is a dummy certificate.
8. Add connectors to Tomcat server.xml.
a. sudo vi /usr/local/tomcat6/conf/server.xml
b. Add the connector as below. Replace "PASSWORD" with the password you entered for the IDP key during installation. If you
install shibboleth to a different location make sure you update the path in red.
<Connector port="443"
protocol="org.apache.coyote.http11.Http11Protocol"
SSLImplementation="edu.internet2.middleware.security.tomcat6.
DelegateToApplicationJSSEImplementation"
scheme="https"
SSLEnabled="true"
clientAuth="want"
keystoreFile="/opt/shibboleth-idp/credentials/idp.jks"
keystorePass="PASSWORD"
truststoreFile="/opt/shibboleth-idp/credentials/trustore.jks"
truststorePass="osmosix"
truststoreAlgorithm="AnyCert"
/>
9. Instead of copying the WAR file to the ...webapps/ROOT/ location which will expand the WAR file Shibboleth recommends using a
context deployment fragment.
a. Create the file TOMCAT_HOME/conf/Catalina/localhost/idp.xml "sudo vi /usr/local/tomcat6/conf/Catalina/localhost/idp,xml
b. Add the context information below. If you install to a different location update the path in red.
<Context docBase="/opt/shibboleth-idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
antiJARLocking="false"
unpackWAR="false"
swallowOutput="true" />
Configure Shibboleth
There are basically four configuration files for Shibboleth. All reside in /opt/shibboleth-idp/conf/. See IdPAuthUserPass for additional information.
attribute-resolver.xml is where we define our authentication sources (in this case Active Directory) and what attributes to pull for users.
attribute-filter.xml is where we define what user attributes to release to what SPs.
handler.xml we define how we are going to handle user authentication/sessions.
login.config is where we define how to authenticate users.
1. cd /opt/shibboleth-idp/conf
2. Add the following to login.config. Update items in red, so they are correct for your active directory setup:
a. Host is the Active Directory Global Catalog. You can enter multiple servers separated with a space to provide
failover/redundancy. If you use multiple hosts for authentication use need to use the same set of multiple servers for attribute
resolving
b. Base is your search base. Update to reflect your domain name. If all users reside under the default Users folder in AD you could
use cn=Users,dc=cloudcentertech,dc=local. If user accounts reside in different areas of the domain you may need to use the root
or the directory.
c. Contact CloudCenter Support for the username\password for this account.
d. If you need to authenticate against multiple LDAP (AD) directories or disjunctive search bases in the same directory, configure
you login.config. See IdPAuthUserPass for additional information.
e. A sample login page is located, in the IdP distribution, at src/main/webapp/login.jsp. For information on how to customize the
login page, see IdPAuthUserPassLoginPage.
Cisco CloudCenter Integration Guide
33
Cisco CloudCenter Documentation
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="ad01.cloudcenter.com"
port="3268"
base="dc=cloudcentertech,dc=local"
ssl="false"
userFilter="sAMAccountName={0}"
serviceUser="[email protected]"
serviceCredential="CloudCenterWin2day!"
subtreeSearch="true"
referral=”follow”;
};
3. Modify handler.xml
a. Find and enable the UsernamePassword LoginHandler. Remove the <!-- before the section and the --> after the section to
enable the LoginHandler.
<LoginHandler xsi:type="UsernamePassword"
jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">
<AuthenticationMethod>rn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport</AuthenticationMethod>
</LoginHandler>
b. Find and disable the RemoteUser Login Handler. To comment out put <!-- in front and -->at the end of the following section:
<LoginHandler xsi:type="RemoteUser"
</LoginHandler>
4. Edit attribute-resolver.xml
a. Add an LDAP Data Connector to point to Active Directory used to resolve users and their attributes. Enter the following
information into the file below
<!-- LDAP Connector -->.
The DataConnecter ID your choice, but must be unique to ensure user authentication against multiple sources so you can add
more Connectors. You must also reference the ID when you add attributes to resolve users.
<resolver:DataConnector id="cloudcenterLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://10.100.1.220:3268" baseDN="dc=cloudcentertech,dc=local"
principal="[email protected]"
principalCredential="CloudCenterWin2day!">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>
b. See ResolverLDAPDataConnector for advance configuration information (using redundant LDAP servers for a connector,
filtering, and so forth).
c. Add the Name Identifier attribute. The file has an attribute already set to use the transientId. You must set a persistent ID
(mapping to the sAMAccountName) as the CloudCenter platform maps the external ID to this attribute (may cause problems if
this ID is transient).
d. Ensure to reference the connector you created under Dependency ref:
<resolver:AttributeDefinition id="sAMAccountName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="sAMAccountName">
<resolver:Dependency ref="cloudcenterLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIden
tifier"/>
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-for
mat:persistent"/>
</resolver:AttributeDefinition>
e. Add Attribute Definition resolvers for all applicable user attributes:
Cisco CloudCenter Integration Guide
34
Cisco CloudCenter Documentation
e.
The CloudCenter platform requires the four attributes: the user's first name, last name, email, and User ID (UID).
If you want to setup SSO at the root tenant-level and have it also work for first-level sub-tenants, you need an attribute to
mark the tenant to which a user should belong.
If you want SSO to work for the second-level sub-tenants, you need one more attribute.
f. Add this under the Data Connector you created to pull the four required attributes.
Reference the connector created under Dependency ref=. If you use multiple connectors, you will have multiple copies
of the attribute resolvers changing the Dependency ref.
<resolver:AttributeDefinition id="mail" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="mail">
<resolver:Dependency ref="cloudcenterLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:mail" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="givenName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="givenName">
<resolver:Dependency ref="cloudcenterLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:givenName" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="givenName" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="sn" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="sn">
<resolver:Dependency ref="cloudcenterLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:sn" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="sn" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="uid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="uid">
<resolver:Dependency ref="cloudcenterLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:uid" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="uid" />
</resolver:AttributeDefinition>
g. All the required attributes (at a minimum, the four required CloudCenter attributes) are published to the Global Catalog. Not all
attributes are published automatically. If you use additional attributes, make sure that these attributes are also published to the
Global Catalog.
h. See the default attributes inside AD and include a Global Catalog column, so you can verify if it in the Global Catalog by default.
i. To change attribute replicate, see Global Catalogs and the Partial Attribute Set.
j. Add a new schema class or attribute definition.
k. If you want to configure SSO to authenticate users from multiple AD domains, see IdPMultipleLDAP.
5. Edit attribute-filter.xml:
a. Add the following AttributeRules to release the attributes we are going to resolve to the SP (in this case, CloudCenter). Add
these after the AttributeFilterPolicy to Release the transient ID to anyone
b. If you pulled any other attributes add a rule to release them as well.
Cisco CloudCenter Integration Guide
35
Cisco CloudCenter Documentation
<afp:AttributeRule attributeID="sAMAccountName">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="mail">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="sn">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="givenName">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="description">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
6. Restart Tomcat :
cd /usr/local/tomcat6/bin ./shutdown.sh
./startup.sh
ADFS SAML SSO Integration
Overview
Domain and Portal Verification
CloudCenter Support
SAML Authentication Configuration
ADFS Trust Settings
Overview
CloudCenter does not authenticate directly to LDAP or AD.
CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping
Identity, ADFS, Shibboleth, and so forth).
To implement SSO using CloudCenter:
1. You must then configure the CCM to re-direct the authentication to the SSO IDP.
2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.
3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and
additional roles and permissions.
A CCM instance supports Security Assertion Markup Language (SAML) 2.0 SSO through Spring Security SAML Extension.
The SysAdmin can be set up SAML integration at the root level or the tenant level. To accurately configure this integration, you must have the
following information for the root tenant or sub-tenant (as applicable to your deployment):
Tenant Information
Activation Profile information
Domain and Portal Verification
Verify and ensure that the following information is accurate:
The timezone and time of the CCM (and by association all other appliances) matches the AD Domain Controllers.
The logon for the FQDN portal page (for example, https://cloud.core.enterpise.com) is accurate.
CloudCenter Support
Contact CloudCenter Support for additional information.
Cisco CloudCenter Integration Guide
36
Cisco CloudCenter Documentation
SAML Authentication Configuration
To configure a tenant to use SSO, follow this procedure:
1. Create a tenant (see Sub-Tenant Configuration)
a. Short Name – give a string without white spaces and special characters.
b. External Id – enter the ID of the organization in the external system with which the tenant is associated.
c. Tenant – the CCM server domain name alias for the tenant. This will serve as the end point of the Service Provider (SP) from the
SSO perspective.
2. Login as the newly created tenant admin and create an Activation Profile.
3. Click the Vendor Info tab and select the newly created activation profile as Default Activation Profile.
4. Login as Sys Admin (see Admin Users > Login as a System Admin), click the Manage Vendor Admins tab and select the Authenticatio
n Settings action dropdown for this tenant.
5. Enter the information in the IDP Settings:
a. IDP Name (sample name is indicative of supporting AD domain)
b. IDP Metadata URL – to establish the mutual trust between the CloudCenter platform and the IDP (currently, this does not
support HTTPS, so use HTTP).
c. IDP Metadata File (if applicable)
6. Enter the information in the SP Settings:
a. Entity ID – the target domain name for this authentication (should be DNS name of logon page)
b. Default SSO Binding should be left at post
c. Logout Target URL – If logging into your company's SAML page, you must specify the URL of the page that you want the
logged in users to be redirected to when they log out of the SAML page (could be same as Entity ID)
7. Enter the information in the Attribute Mappings sections – These are the fields from the IDP that will be mapped to user attributes within
the CloudCenter platform. If you are unsure about these fields, please contact your IDP administrator. At a minimum, you need to provide
the first name, last name, email address, and external User ID.
a. Enter the First Name Mapping (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname)
b. Enter the Last Name Mapping (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname)
c. Enter the Email Mapping (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)
d. Enter the User Group Mapping (http://schemas.xmlsoap.org/claims/Group)
e. Download the Metadata file.
8. Click Submit.
ADFS Trust Settings
To configure the ADFS trust settings and to edit the corresponding claim rules, follow this procedure.
1. In the AD FS Manager, under AD FS > Trust Relationships > Relying Party Trusts, click Add Relying Party Trust to open the Add
Relying Party Trust Wizard.
2. On the Welcome page, click Start.
3. On the Select Import Data from a file page, browse for and select the sp-xxxxx.xml file.
4. Click Next.
5. Provide a Display name.
6. Click Next.
7. On the Configure Multi-factor Authentication Now? page, select I do not want to configure multi-factor authentication settings for
this relying party trust at this time.
8. Click Next.
9. On the Choose Issuance Authorization Rules page, select either Permit all users to access this relying party.
10. Click Next.
11. On the Ready to Add Trust page, enter the properties of the new Relaying Party Trust and click Next to save your relying party trust
information.
12. On the Finish page, click Close. This action automatically displays the Edit Claim Rules box.
13. Click Properties.
14. On the Advanced tab, in the Secure hash algorithm list, select SHA-1, and then click OK.
15. Click the trust in the list where you want to create a claim rule.
16. Right-click the selected trust, and then click Edit Claim Rules.
17. On the Select Rule Template page, under Claim rule template, select Send LDAP Attributes as Claims from the list, and then click N
Cisco CloudCenter Integration Guide
37
Cisco CloudCenter Documentation
17.
ext.
18. On the Configure Rule page under Claim rule name type Get Attributes in the display name field.
19. Under the Mapping of LDAP attributes to outgoing claim types select the following LDAP Attribute and corresponding Outgoing
Claim Type types from the drop-down lists.
a. Given-Name = Given Name
b. Surname = Surname
c. E-Mail-Addresses = E-Mail Address
d. Token-Groups - Unqualified Names = Group
20. Click OK.
21. Add another rule, to the Transform an Incoming Claim template – on the Select Rule Template page, under Claim rule template, select
Transform an Incoming Claim from the list, and then click Next.
22. Name the rule as SAM to NameID and map the following values:
a. Incoming claim type = E-Mail Address
b. Outgoing claim type = Name ID
c. Outgoing name ID format = Email
Cisco CloudCenter Integration Guide
38
Cisco CloudCenter Documentation
23. Click OK.
You have now configured the ADFS SAML SSO integration.
ServiceNow
Release Notes for v1.3
Architectural Overview
Integration Overview
Install and Configure
Release Notes for CloudCenter/ServiceNow v1.3 Integration
Release date
Architecture
Installation
Upgrades
Security
Supported CloudCenter Platforms
Supported ServiceNow Platforms
New Features
Enhancements
Other Updates
Deprecated items
Resolved Issues
Release date
Cisco CloudCenter Integration Guide
39
Cisco CloudCenter Documentation
March 29, 2017
Architecture
Converted Saved Quote, Order History, and Approval detail web pages to Angular.
Installation
No updates
Upgrades
Upgrade from ServiceNow v1.2 to v1.3 requires running the CM: v1.2 - 1.3: Fix script that is provided along with the upgrade file.
Security
Two additional user groups related to multi-tenancy (Cloud Marketplace Global Tenant Admin and Cloud Marketplace Tenant Admins) are now
available. See the New Features section below for additional details.
Supported CloudCenter Platforms
Cisco CloudCenter 4.6.x
Cisco CloudCenter 4.7.1.1
Supported ServiceNow Platforms
ServiceNow Geneva
ServiceNow Helsinki
New Features
Feature
Description
Manage
Global
Parameters
During the Cloud Marketplace ordering process, you can view and update the following Global Parameters for applications:
Additional
Deployment
Scheduling
Options
During the checkout process, you can select the following check boxes to:
Multi-Tenancy
Support
Cloud Marketplace supports a single-tier tenancy model that works in conjunction with the CloudCenter's tenancy concept. The
multi-tenancy feature enables Global Tenant Admins to import tenant information from CloudCenter and assign Cloud
Marketplace users to a specific tenant. This support allows tenant-specific application publishing from CloudCenter to
ServiceNow's service catalog, cloud mappings, and logo.
string
list
number
password
Deploy Now, as well as manually select the start date and time of an order.
Fixed Duration, to select the deployment duration in days based on a predefined property.
Additional multi-tenancy user groups:
1. Cloud Marketplace Global Tenant Admin - Members of this group are permitted to configure Tenant API credentials
and perform tenant instance mappings.
2. Cloud Marketplace Tenant Admins - Members of this group are permitted to configure Tenant API credentials and
perform tenant instance mappings for their own tenant.
Extend
service
instance
You can Extend the end date of the service instance. An estimated quotation is provided for the extension period. Cloud
Marketplace administrators can determine the approval process required to extend a service instance.
Enhancements
Cisco CloudCenter Integration Guide
40
Cisco CloudCenter Documentation
Enhancement
Description
My Overview S
ection
Dynamic scroll bar added to Cloud Status dashboard.
New status based color-coding added to Cloud Status dashboard.
Graphs updated to display deployments per cloud and deployments approaching termination date.
Service
Instances Secti
on
Updated user interface.
New option to Extend a service instance.
New section to view Global Parameters for a deployment.
Additional deployment information, including current running cost, displayed.
Order History
Section
New color-coded order status.
Green: Closed Complete
Orange: Closed Cancelled, Requested, Deployment In Progress
Red: Closed Incomplete
Updated user interface.
Additional deployment information displayed under the Basic Details section.
New sections to view:
Global Parameters of a deployment.
User and Group approval details with a status indicator.
Approvals Sect
ion
Updated user interface.
Additional deployment information displayed under the Basic Details section.
New sections to view:
Global parameters of a deployment.
User and Group approval details with a status indicator.
Store
Updated user interface.
Using quick search instead of filters to search for applications.
Updated logic prevents applications from being displayed in the Store if the application is not shared in CloudCenter.
Application name, Description, and Name are auto published with the CloudCenter during Publish to ServiceNow custom
action.
Order Process
Selection of Application Version is now a drop-down, instead of a checkbox.
New section to view and update Global Parameters. Parameters are either hidden, required, or read-only as configured
in CloudCenter.
Checkout
Process
Updated user interface.
New option to Deploy Now and/or select a fixed deployment duration.
Ability to restrict deployment duration based on environment selection (sample script provided).
Get Quote feature does a dynamic lookup of various costs specified in CloudCenter.
Removed and replaced the selection of a Service Instance Owner with an approval workflow that can be customized by
an admin.
Removed checkbox requiring user to agree to data classification requirement.
Renamed Submit Quote to Submit Order.
CMDB
Updates
Deployments performed directly from CloudCenter stored in ServiceNow CMDB under the tables CliQr Deployments,
CliQr Jobs and CliQr Nodes.
Disable
Purchase
Order
Administrators have the ability to enable or disable the Purchase Order feature from the Cloud Marketplace configuration
page. Disabling this feature removes the Purchase Order selection during the checkout process and does not require
any financial approvals prior to a service instance deployment.
To install the Cloud Marketplace application, you must enable the Procurement plugin.
Other Updates
Added support to use another CloudCenter admin user, other than cliqradmin, to establish connection with CloudCenter.
Replaced the group Cloud Marketplace Service Instance Owners with Cloud Marketplace Approvers.
Updated dashboard notifications.
Wave spinners added during page loading.
Reduced loading time for Quote Details modal.
Saved Quotes, Order History, and Approval details pages converted to Angular.
The Order confirmation page now contains a link to the order details for quick access after submission.
Name Changes in this release:
Old
New
Location
Test CliQr Connection
Test CloudCenter Connection
Integration - CloudCenter
Cisco CloudCenter Integration Guide
41
Cisco CloudCenter Documentation
Data Classification
System Tag
The order form
Specify the size of your service
Select Instance Type
The order form
Deprecated items
Removed the following filters from the Store:
Data Classification
Cloud Type
Price
Availability
Environment
Removed Price and Availability from the Service Catalog item.
Resolved Issues
The following issues were resolved/addressed in Cloud Marketplace v1.3:
Issue: Clicking the Submit Order button multiple times generated multiple requests.
Resolution: The Submit Order button is disabled after the initial submission.
Issue: Pending count on the dashboard was inaccurate.
Resolution: Pending count now displays the correct number of pending approval requests for a service instance.
Issue: Application publishing was unsuccessful if an apostrophe character was used in the application description.
Resolution: Added validation prevents the apostrophe character from failing the application publishing process.
Issue: Environment value on the Approval details page was incorrect.
Resolution: The correct Environment value is now displayed.
Issue: The Service name was not visible in the Saved Quote details page.
Resolution: The Service name is now shown in the appropriate section.
CloudCenter – ServiceNow Integration Architectural Overview
Overview
Architecture
Integration Requirements
Capabilities
Overview
Cisco CloudCenter has an integration application that is certified by ServiceNow and is available for download from ServiceNow’s App Store. The
integration app is developed within ServiceNow’s CMS and within the ‘Private application scope’ space. Although this limits the availability of its
resources to other parts of the ServiceNow environment, but it ensures that the integration app does not impact the global scope and maintains
the overall integrity of the customer’s ServiceNow environment.
Architecture
The following image illustrates the communication between Cisco CloudCenter and ServiceNow. All communication is through REST API calls.
Cisco CloudCenter Integration Guide
42
Cisco CloudCenter Documentation
User creation – ServiceNow user records are added to groups that are configured during the setup process. When a user is added to
the group, an outbound REST call is made to create and activate a corresponding user record in CloudCenter, and the ServiceNow user
is assigned an API key that is used to authenticate subsequent calls to the CloudCenter API.
Publishing – When an application is published from CloudCenter to ServiceNow, an inbound REST call is made to ServiceNow to create
an application profile. After the initial publishing to ServiceNow, if an application is updated in CloudCenter, an administrator must
republish the application to ServiceNow.
Ordering – When an application is requested through the catalog, an associated deployment Configuration Item (CI) and a logical group
CI is created. Outbound REST calls are then made to update the deployment CI and create its associated node and job CIs.
Deployment Management – When there are deployment-related updates in CloudCenter, inbound REST calls are made to push those
updates to the associated CIs.
Integration Requirements
Component
Requirement
Details
ServiceNow
Version support
The integration application requires the ServiceNow environment to be on Geneva or Helsinki.
Helsinki support began as of Version 1.2 of the integration app.
Ports
The CloudCenter Manager must be able to reach ServiceNow directly over SSL and vice versa if a
MID server is not in use.
MID Server (optional)
MID Server support is available for inbound traffic, from ServiceNow to the CCM. Outbound traffic
from the CCM to ServiceNow needs to be available directly.
A working
CloudCenter
environment
See Manual Installation.
Version support
The integration application supports Cisco CloudCenter 4.6.0 or above.
Policy definitions
Defined in the implementation guide, action policies need to be created in Cisco CloudCenter for
application publishing.
Tenant admin API key
For API communication from ServiceNow to CloudCenter
Cisco
CloudCenter
Capabilities
MID Server – The integration supports ServiceNow environments with or without a MID server.
Application Security – All API keys are encrypted using the Password (2 Way Encrypted) internal type. Calls to CloudCenter require
basic authentication using an API key associated with the user.
Application Components – The integration app creates a number of Script Incudes, Business Rules and Tables, including extension of
some ServiceNow tables.
Modified Components – The integration modifies the Purchase Orders component within ServiceNow.
Cisco CloudCenter Integration Guide
43
Cisco CloudCenter Documentation
Application Customization – The integration application is customizable. It is advised that if Customers make modifications to their local
installation, that those changes be maintained in an Update Set in the event the local modifications are overwritten by a future product
update.
Product (Application) Catalog – The integration adds a new product catalog that is developed using Angular. The integration app does
not use the OOB ServiceNow catalog.
Quote generation – The integration relies on the image or cloud costs data stored in CloudCenter to provide quotes on the checkout
form. Use quotes as estimates to determine the deployment cost.
Deployment Running Cost – The integration maintains the running cost of each deployment based on the cost data obtained during the
initial quotation process.
CloudCenter-ServiceNow Integration Overview
Overview
Integration Details
Benefits
Features
Overview
Using Cisco CloudCenter, service managers and application owners can easily create model once, deploy anywhere application profiles and
publish them to ServiceNow.
Using ServiceNow, users can then request deployment to any supported datacenter or cloud with side-by-side cost comparison for each option.
The Cisco CloudCenter-ServiceNow integration extends IT Service Management (ITSM), IT Operations Management (ITOM), and IT Business
Management (ITBM) processes to include application deployment and management, while adding enterprise-class management and governance
features.
Integration Details
Cisco CloudCenter provides an integration application that is certified by ServiceNow and is available for download from ServiceNow’s App Store.
This integration allows applications and services created in CloudCenter to be published into a custom catalog in ServiceNow for consumption by
specified ServiceNow users. These users can browse the catalog, configure and add applications to cart, compare deployment cost across clouds
and deploy applications to their preferred cloud.
Once an application is submitted for deployment, its status can be tracked within the integration app. In addition, lifecycle actions such as Suspen
d, Resume, or Terminate can be taken on active deployments with real-time updates from CloudCenter. Users can also SSH or RDP into the
virtual machines they have deployed without ever leaving ServiceNow.
All of these functions are made possible by providing a set of sample UI pages that are fully functional and developed within ServiceNow’s CMS.
The user-interface is easy to understand, customizable and abstracts much of the complexity of cloud deployment and management. As part of
the integration app setup wizard, each ServiceNow environment is easily linked to a CloudCenter environment and all communication between
ServiceNow and Cisco CloudCenter is secure and performed through REST API calls.
Benefits
The CloudCenter-ServiceNow integration application has the following benefits:
Cisco CloudCenter Integration Guide
44
Cisco CloudCenter Documentation
Certified by ServiceNow: The integration application is certified by ServiceNow and is available for download by ServiceNow customers
from the app store. The application is developed within the ServiceNow application scope, instead of the global scope, in order to
minimize impact on existing ServiceNow implementation.
Promotes DevOps: Encourages DevOps operations by improving efficiency of obtaining new infrastructure and application deployments.
Easy to Use: Simple yet effective user-interface abstracts cloud deployment complexities. Provides a single location for ServiceNow end
users that reduces the need to train on an additional tool.
Reduces Cost: Scheduled deployments and termination helps reduce cost and optimize infrastructure resources.
Improved Compatibility: The integration application is compatible with ServiceNow environments utilizing a MID server.
Application Publishing: A service manager can easily model a cloud-independent application profile in the Cisco CloudCenter profile
modeler with out-of-the-box or imported images, application services, and containers and then publish it to ServiceNow for consumption.
Service Requests: In ServiceNow, specified users can select applications and services, add them to the shopping cart, enter start and
end dates, and select the deployment location based on a side-by-side cost comparison that is presented for each available cloud.
Workflow Approval: Route the request to approvers with projected costs to help guide their decisions.
Automated Deployment: ServiceNow calls the Cisco CloudCenter solution to provision cloud infrastructure resources through direct
communication with the target cloud API. It then deploys and configures application images, services and data.
Status Updates: ServiceNow receives status and ongoing infrastructure performance updates from the Cisco CloudCenter solution.
Using information from third-party application performance monitoring and service assurance tools, ServiceNow can log an incident or
start a new remediation workflow.
Features
One-click publishing of applications from Cisco CloudCenter to ServiceNow.
Provision and manages a single virtual machine or a full application stack.
Provides a product (application) catalog that is developed in Angular for easy customization and is not linked to the OOB ServiceNow
catalog.
Shopping cart experience.
Side-by-side deployment cost comparison of configured clouds during ordering.
Save quotes for future use or download it for financial processing.
Approval workflows and email notifications.
Uses tags in Cisco CloudCenter for governance.
Scheduled deployment and termination.
Lifecycle actions such as Suspend, Resume and Termination of active deployments.
Remotely connect to deployed virtual machines.
Uses REST API to communicate between ServiceNow and Cisco CloudCenter.
Install and Configure ServiceNow and CloudCenter
Availability
Configure Cisco CloudCenter
1. Create Custom Action
2. Create Policies
Configure ServiceNow
1. Download and Install the CloudCenter-ServiceNow Integration Application
2. Configure the CloudCenter-ServiceNow Integration Application
Validate the CloudCenter-ServiceNow Integration
Additional Notes
Availability
CloudCenter 4.6 supports the following ServiceNow releases:
ServiceNow, Geneva
ServiceNow, Helsinki
CloudCenter 4.6 supports the following Integration–CloudCenter releases:
Intergration–CloudCenter, Release 1.0
Intergration–CloudCenter, Release 1.1
Intergration–CloudCenter, Release 1.2
Configure Cisco CloudCenter
To configure the CloudCenter for the ServiceNow Integration, you must follow a multi-step process.
Cisco CloudCenter Integration Guide
45
Cisco CloudCenter Documentation
1. Create Custom Action
You must create a custom action to publish application profiles from Cisco CloudCenter to ServiceNow.
To create a custom action, perform the following procedure in Cisco CloudCenter.
1.
2.
3.
4.
Log into Cisco CloudCenter using administrative privileges.
Select Policies from the left navigation.
Select the Custom Actions tab.
Click Add Custom Action and define the fields as follows:
Field
Value
Name
Publish to ServiceNow
Visible to User
Enabled
Object
Application
Action Type
Invoke a web service
Protocol
HTTPS
Web Service URL
<yourServiceNowInstance.com>/api/now/table/x_cqt_cliqr_publish_app_trigger
Username
rest.admin (this user will be created in ServiceNow at a later point)
Password
Enter the password for the rest.admin user.
Http Request Type
POST
Content Type
JSON
Body
{
"app_id": "%appId%",
"app_name": "%appName%",
"latest_app_version": "%latestAppVersion%",
"owner_id": "%ownerId%",
"owner": "%owner%"
}
2. Create Policies
You must create 3 action policies to propagate the status of the application deployments back to ServiceNow. For each policy, use the common
settings and individual policy settings listed below.
To create each new policy, perform the following steps in Cisco CloudCenter.
1. Select Policies from the left navigation.
2. Select the Policies tab.
3. Click on Add Action Policy and define the fields as follows:
Common Settings
Field
Value
Name
See the Individual Policy Settings section below.
Execute For
Application Deployment
On Event
See the Individual Policy Settings section below.
Action Type
Invoke a web service
Protocol
HTTPS
Web Service URL
<yourServiceNowInstance.com>/api/now/table/x_cqt_cliqr_job_status_trigger
Cisco CloudCenter Integration Guide
46
Cisco CloudCenter Documentation
Username
rest.admin (this user will be created in ServiceNow at a later point)
Password
Enter the password for the rest.admin user.
Http Request Type
POST
Content Type
JSON
Body
See the Individual Policy Settings section below.
Auto Enabled for shared users
Enabled
Restrict users from disabling this Policy
Enabled
Individual Policy Settings
Policy
On Event
1. SNOW_job_status_changed
Status Changed
Body
{
"job_id": "%jobId%",
"job_name": "%jobName%",
"job_type": "%jobType%",
"app_name": "%appName%",
"owner": "%owner%",
"status": "%status%",
"changed_on": "%ChangedOn%",
"new_status": "%NewStatus%"
}
2. SNOW_job_deployed
Deployed
{
"job_id": "%jobId%",
"job_name": "%jobName%",
"job_type": "%jobType%",
"app_name": "%appName%",
"owner": "%owner%",
"status": "%status%",
"deployed_on": "%DeployedOn%"
}
3. SNOW_job_canceled
Canceled
{
"job_id": "%jobId%",
"job_name": "%jobName%",
"job_type": "%jobType%",
"app_name": "%appName%",
"owner": "%owner%",
"status": "%status%",
"cancelled_on": "%CancelledOn%"
}
Cisco CloudCenter Integration Guide
47
Cisco CloudCenter Documentation
Configure ServiceNow
To configure the CloudCenter-ServiceNow Integration application, you must follow a multi-step process.
1. Download and Install the CloudCenter-ServiceNow Integration Application
To download and install the CloudCenter-ServiceNow Integration application, follow this procedure.
1. Submit a request to download the CloudCenter-ServiceNow Integration application.
a. Go to the https://store.servicenow.com website.
b. Search for Integration - CloudCenter.
c. Select the Integration - CloudCenter application from the catalog.
d. Select Contact Seller to obtain approval to download the application.
2. Install the CloudCenter application in ServiceNow:
a. Once the application has been approved, using the left filter option, navigate to System Applications > Applications > Downlo
ads > Integration - CloudCenter.
b. Click All versions.
c. Select and install the appropriate version.
2. Configure the CloudCenter-ServiceNow Integration Application
To configure the CloudCenter-ServiceNow Integration application, follow this procedure.
1. Enable the Procurement plugin.
a. Using the filter and navigate to Plugins.
b. Search for Procurement within the Plugins module.
c. Locate and activate Procurement - com.snc.procurement.
d. Once completed, click on Close and Reload Form.
2. Install the certificate:
If a self-signed certificate is used in Cisco CloudCenter, the certificate must be added in ServiceNow to enable communication
a. Using the filter and navigate to System Definition > Certificates.
b. Add a new X.509 certificate using the Trust Store Cert type.
3. Setup the connection with Cisco CloudCenter:
This step assumes that you have a CloudCenter Manager (CCM) that can communicate with the ServiceNow environment over
the network.
a. Using the filter and navigate to Cloud Marketplace Configuration.
b. Complete the following required fields under the General Settings section in order to establish a connection with Cisco
CloudCenter.
General
Settings
Additional information
CCM URL
Enter the URL of Cisco CloudCenter using the format https://<ciscoCloudCenterURL>.com.
Username
Enter the default username cliqradmin or another administrator account from Cisco CloudCenter.
API Key
Enter the API key of the administrator account used above. To obtain the API key, login to Cisco CloudCenter.
Then navigate to Admin > Users and click on Manage API Key for the account being used.
Cisco CloudCenter Integration Guide
48
Cisco CloudCenter Documentation
c. Once you complete the General Settings section, click Submit. The Cloud Marketplace configuration page will reload and a new
section called Cloud and Instance Mapping becomes accessible. Stay on the same page and follow the steps in the next section.
This step is important – If the Cloud and Instance Mapping section is not visible, ServiceNow cannot communicate with
Cisco CloudCenter.
4. Setup Clouds and Instance Mapping.
a. Complete the following required fields under the Cloud and Instance Mapping section. See screenshot below for reference.
Cloud
and
Instance
Mapping
Additional information
Cloud
Use the dropdown to select a Cloud. Only Clouds that are enabled in Cisco CloudCenter are selectable.
Region
Use the dropdown to select the Region that is enabled in Cisco CloudCenter.
Instance
Mapping
The order form in the integration application utilizes a simplified approach for users to select an instance size.
Use this dropdown to associate an appropriate instance type value for sizes Small, Medium, Large and Extra
Large. Additional Clouds can be configured by clicking the plus
icon.
b. After the Cloud and Instance Mapping section is completed, click the Submit button to save the settings.
5. Verify Connectivity.
a. Using the filter to navigate to the Integration: CloudCenter > Test CliQr Connection.
b. Click Test CliQr Connectivity.
c. All 3 tests should be successful – as displayed in the following image.
Cisco CloudCenter Integration Guide
49
5.
Cisco CloudCenter Documentation
c.
6. Create the Integration User.
a. In ServiceNow, create a new user as follows:
Field
Value
User ID
rest.admin
First Name
Rest
Last Name
Admin
Email
Not required
Password
<enter a secure password>
Web service access only
Enabled
Internal integration user
Enabled
Roles
Add the following roles: u_cliqr_admin, procurement_admin, rest_service
7. Create a Purchase Order (PO).
To complete the order form within the integration application, a valid PO is required.
a. Using the filter, navigate to Purchase Orders under Procurement > Orders > Purchase Orders.
b. Create a new Purchase Order as follows:
Field
Additional information
PO Number
Enter the auto generated number from the Number field.
Value
Enter an appropriate value for the Purchase Order.
Assigned To
Select any user. We will update this field later to validate the configuration.
Type
Select Cloud Marketplace.
8. Verify your integration by following the items listed in the post configuration checklist
a. Confirm the following Groups and Roles exist under System Security > Users and Group.
Group
Name
Roles
Additional information
Cloud
Marketplace
Service
Instance
Owners
x_cqt_cliqr.service_instance_owner
Users part to this group can be owners of the service instance and will
also see the Approvals tab on the dashboard. At least one user should
belong to this group.
Cisco CloudCenter Integration Guide
50
Cisco CloudCenter Documentation
Cloud
Marketplace
Consumers
u_cliqr_requester
Users must be a part of this group to browse the catalog and
accept/reject approval requests. Adding users to this group (along with
the CliQr group) creates a user account in Cisco CloudCenter and
generates an API key for this user. Confirmed this requirement by
navigating to Integration - CloudCenter > User Properties and Integrat
ion - CloudCenter > User API Keys.
CliQr
rest_service
procurement_user
Create a separate group for each Cisco CloudCenter Activation Profile
that used for this integration. The first group should be called CliQr.
Additional groups (if needed), should be given the name CliQr <activatio
n profile tag>.
b. Confirm the following Group Properties exists under Integration - CloudCenter > Group Properties.
Group
Name
Value
Additional information
CliQr
activiation_profile
1
Use the following format to create additional Group Properties as needed:
Group: CliQr <activation profile tag>
Name: activation_profile
Value: <cliqr_profile_id}>
The cliqr_profile_id is the ID of the activation profile in Cisco CloudCenter. This is a numeric value
such as 1 or 2. The groups associated activation profile defines the options that group members can
see for items in the order guide. Use the API View Activation Profiles to retrieve the ID. If an
Activation Profile is not present in Cisco CloudCenter, you will need to create one, as per the
instructions in the link provided above.
9. Confirm the following properties exist under Integration - CloudCenter > Settings > Properties.
Property Name
Description
default_published_app_group
The default value of this property is Cloud Marketplace Consumers. This is the default group to which
the applications published from Cisco CloudCenter will be associated with. If there is no requirement to
filter the applications based on user groups, this group should always be set to the default value.
max_order_quantity
The order form in the integration application allows users to select the quantity of each application
through a dropdown list. Use this comma separated list to configure the dropdown values for the
quantity selection. The default value is 1,2,3,4,5.
10. Confirm the Instance Specs table under Integration - CloudCenter > Data Tables > Instance Specs contains sample data. This data is
presented to the user on the order form when selecting an instance size (small, medium, large or extra large).
11. Optional configuration procedure to enable emails and support MID servers.
a. Email needs to be enabled for the approval workflow email notifications. Existing ServiceNow installations may already have this
configured.
i. Using the filter, navigate to System Properties > Email Properties (or Email depending on the ServiceNow version)
ii.
Cisco CloudCenter Integration Guide
51
11.
Cisco CloudCenter
a. Documentation
ii. Confirm that outbound and inbound email sending is enabled.
b. Support for MID server:
i. Navigate to MID Server > Capabilities and confirm that the REST, SSH, and SOAP capabilities have been added.
ii. Create the following property under Integration - CloudCenter > Settings > Properties.
Property name
Value
Mid_server_name
<configured_rest_server_name>
Validate the CloudCenter-ServiceNow Integration
To validate the CloudCenter-ServiceNow Integration application, follow this procedure.
1. Create Test Users
a. To verify the installation, create the following test user accounts in ServiceNow. An email address is required to create a user
account.
User Name
Group Membership
Description
consumer.user
i. Cloud Marketplace Consumers
ii. CliQr
This test user is used to submit orders.
serviceOwner.user
i. Cloud Marketplace Consumers
ii. Cloud Marketplace Service
Instance Owners
This test user is used to approve/reject order requests from an
owner perspective.
financeOwner.user
i. Cloud Marketplace Consumers
ii. Cloud Marketplace Service
Instance Owners
This test user is used to approve/reject order requests from a
finance perspective.
b. A new purchase order was created in the Create a Purchase Order section above. For that purchase order, update the Assigned
To field to the user financeOwner.user.
2. Publish an Application Profile to ServiceNow
a. In Cisco CloudCenter, locate an Application Profile under the Applications tab.
b. Click the dropdown for the application and Share it with all users in the Tenant.
c. Click the dropdown for the application and select Publish to ServiceNow.
d. In ServiceNow, navigate to Integration - CloudCenter > Data Tables > Application Profiles. There should be a record that
contains the published application.
3. Place an order:
a. Navigate to https://<yourServiceNowInstance>.com/cloud-marketplace.
b. Login as the user consumer.user.
c. Click on Store.
d. Select an application from the catalog, configure and submit the order. Make sure to choose serviceOwner.user as the Service
Instance Owner and select the PO that is assigned to financeOwner.user.
e. Login as serviceOwner.user and then as financeOwner.user to approve the request.
f. Once the order is approved, the order should be deployed based on the provided deployment start date and time.
g. Browse to the Service Instances tab and confirm the order is in Deployed status.
Additional Notes
Installing the Integration app adds extra fields to the task table. As this is a linear operation, the load time could take a while depending on the
existing data in the environment.
Cisco CloudCenter Integration Guide
52