Case Study - OTDS 162 - OKTA Integration
Case Study - OTDS 162 - OKTA Integration
Case Study - OTDS 162 - OKTA Integration
Version: 16.2
Task/Topic: Deployment
Audience: Administrators
Platform: Windows, Linux
Document ID: 500341
Updated: March 2, 2018
Case Study
Integrating OTDS 16.2 with OKTA
OpenText Customer Support
Integrating OTDS 16.2 with OKTA
Contents
Summary ...................................................................................................................... 3
Environment Details ............................................................................................... 3
OKTA Configuration .................................................................................................... 4
Service Provider (SP) Initiated ............................................................................... 4
Identity Provider (IdP) Initiated ............................................................................... 7
SAML Single Logout (SLO) ...................................................................................... 11
OTDS – Certificate Creation ................................................................................. 11
OKTA – Advanced Settings .................................................................................. 12
OTDS Configuration ................................................................................................. 14
Auto Provisioning.................................................................................................. 14
SAML 2.0 Authentication Handler......................................................................... 15
Validate the Deployment .......................................................................................... 18
Test – OTDS Auto-Provisioning ............................................................................ 18
Test – SAML Single Logout (SLO)........................................................................ 19
Summary
This Case Study provides details on integrating OTDS 16.2 with OKTA as a
Federated IdP (Identity Provider) for SAML 2.0 authentication. This document is
intended for Content Server Administrators and Infrastructure Team resources
responsible for IdP integration. Please refer to the official OTDS documentation for
any specific details regarding OTDS deployment that is not covered in this document.
DISCLAIMER:
All procedures in this Case Study are specific to the scenario
provided in the document and delivered as is, and is for proof of
concept purposes only. It is presented as a guide to supplement
official OpenText product documentation. Deployments with
different architecture, server roles, topologies, or transport
architecture may also add to the complexity.
Environment Details
Setup an existing OTDS 16.2 server with OKTA for SAML 2.0 authentication. Content
Server 16.2 will be used as the Resource but is not required for this deployment to
work. Any OpenText product that integrates with OTDS 16.2 should work.
Both SP (Service Provider) Initiated and IdP (Identity Provider) Initiated
authentication will be documented. SAML Single Logout (SLO) is optional and will be
setup with the required OTDS Server certificates.
Server Details
Content Server cs-web01.wlsupport.net (Windows 2016)
Content Server 16.2.3 (2017-12)
OKTA Configuration
Figure 1
5. Provide an App name and optionally select a logo and select Next
Figure 2
6. SAML Settings
a. Points to the sign on URL of OTDS, this URL is also used for the SP
Entity ID
b. Name ID format will be set to Unspecified
Figure 3
Figure 4
8. Select I’m a software vendor. I’d like to integrate my app with OKTA and
select Finish.
Figure 5
Figure 6
10. Assignments section, once the OKTA app has been created it must be assigned
to users
a. Assign > Assign to People > Search for created users
b. Sample user otdsuser@gmail.com has already been setup in OKTA
Figure 7
Figure 8
5. Provide an App name and optionally select a logo and select Next
Figure 9
6. SAML Settings
a. Disable any SSO related Authentication Handlers (i.e. http.negotiate,
SAML)
b. Navigate to the desired destination URL which redirects to the OTDS
sign in page
c. Example: Content Server URL was requested and redirected to OTDS
http://ds-app01.wlsupport.net:8080/otdsws/login?RFA=94C54502-0805-
5546-D395-CCD0DEBC04BD%3Ahttp%3A%2F%2Fcs-
web01%2Ewlsupport%2Enet%2FCS162%2Fcs%2Eexe%3Ffunc%3Dotd
sintegration%2Eredirect%26NextURL%3Dhttp%253A%252F%252Fcs%
252Dweb01%252Ewlsupport%252Enet%252FCS162%252Fcs%252Eex
e&PostTicket=true&PostParams=true&ux_version=1&PreserveFragment
=true
d. This URL is too long for OKTA and must be modified to the following
http://ds-app01.wlsupport.net:8080/otdsws/login?RFA=94C54502-0805-
5546-D395-CCD0DEBC04BD%3Ahttp%3A%2F%2Fcs-
web01%2Ewlsupport%2Enet%2FCS162%2Fcs%2Eexe&PostTicket=true
&PostParams=true
e. Name ID format will be set to Unspecified (see figure 10)
Figure 10
Figure 11
8. Select I’m a software vendor. I’d like to integrate my app with OKTA and
select Finish.
Figure 12
Figure 13
10. Assignments section, once the OKTA app has been created it must be assigned
to users
a. Assign > Assign to People > Search for created users
b. Sample user otdsuser@gmail.com has already been setup in OKTA
Figure 14
2. Convert private key to PKCS8 DER encoding, password entered in this step will
be required when configuring the SAML Authentication Handler in OTDS
OpenSSL> pkcs8 -topk8 -inform PEM -outform DER -in saml_key.pem -out
saml_key.pkcs8
Enter pass phrase for saml_key.pem: ********
Enter Encryption Password: ********
Verifying - Enter Encryption Password: ********
3. The previous steps have created the following files in the directory where
OpenSSL commands were run from
• saml_cert.cer
• saml_key.pem
• saml_key.pkcs8
Figure 15
OTDS Configuration
Auto Provisioning
1. From System Config set Enable Auto-Provisioning of Accounts to true
a. By default, name is Auto-Provisioned Accounts and can be changed from
Auto-Provisioned Accounts Partition
b. A Non-Synchronized User Partition must be created that matches this value
Figure 16
Figure 17
3. Add Auto-Provisioned Accounts User Partition to the Access Role of the Content
Server Resource
Figure 18
2. User Partition
a. Select Global or scoped specifically to a User Partition that has been
created i.e.) Auto Provisioning.
Figure 19
3. Parameters
a. Best Practice is to have the Identity Provider (IdP) Name set to the
same value as the Authentication Handler name
b. Upload the metadata.xml obtained from the OKTA configuration as the
IdP Metadata File
c. The IdP NameID Format must match the OKTA configuration which was
set to Unspecified
d. OTDS SP Endpoint is not required for this setup and is typically used for
proxy configurations
e. Active By Default is true (default) which prevents the user from landing
on the OTDS Login page and selecting the Authentication Handler icon.
For SP Initiated this value should be true and should be set to false for
IdP Initiated (see Figure 20).
Figure 20
f. If SAML SLO has been configured in OKTA along with the OTDS SSL
certificates upload both the saml_cert.cer and saml_key.pkcs8 and
provide the password that was previously set for the Private Key
g. SHA256 must be set for the XML Signature Algorithm to match the
Signature Algorithm of OKTA which is SHA256 by default
Figure 21
h. Claim 1 through 3 must be set to match the format of the attributes within
OKTA, these are required during the Auto-Provisioning of a user
4. Configuration
a. Authentication principal attribute is set to mail
b. OTDS will look for the email within the SAML assertion and validate against
OpenDJ during authentication or create the account during auto provisioning.
Figure 22
Figure 23
c. If this URL is blank this means there’s an issue with the configuration of the
Authentication Handler
d. Set OTDS logging to DEBUG, attempt to access the URL again and review
the otds.log file for errors
Figure 24
Figure 25
Figure 26
Figure 27
3. User is presented with an OTDS page stating they have been logged out
4. If the user selects OKTA from the OTDS login page they should be presented with an
OKTA login
a. If the user is seamlessly logged in again through OKTA, then SLO has failed
b. OKTA logging should be reviewed
Figure 28
5. Successful SLO would prompt the user for OKTA credentials if they attempted to
login again.
6. OKTA logging will display the following on successful SLO.
Figure 29
About OpenText
OpenText enables the digital world, creating a better way for organizations to work with information, on premises or in the
cloud. For more information about OpenText (NASDAQ: OTEX, TSX: OTC) visit opentext.com.
Connect with us:
20
www.opentext.com/contact
Copyright © 2018 Open Text SA or Open Text ULC (in Canada).
All rights reserved. Trademarks owned by Open Text SA or Open Text ULC (in Canada).