Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Case Study - OTDS 162 - OKTA Integration

Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

Product: OpenText Directory Services (OTDS)

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

The Information Company™ 2


Integrating OTDS 16.2 with OKTA

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)

OTDS  ds-app01.wlsupport.net (RHEL 7)


 OTDS 16.2.3
 Auto Provisioning enabled
OKTA  Development instance has been created
 Service Provided (SP) Initiated
 Identity Provider (IdP) Initiated
 Single Log Out (SLO) configured

The Information Company™ 3


Integrating OTDS 16.2 with OKTA

OKTA Configuration

NOTE: This section has a few options based on deployment


requirements. For example, IdP vs SP Initiated login and SAML
Single Logout.

Service Provider (SP) Initiated


1. Login to Development instance of OKTA, if you see < > Developer in the top left,
click it and select Classic UI
2. Select Add Applications
3. Select Create New App
4. From the drop down select Web as the Platform and SAML 2.0 as the Sign on
method and select Create

Figure 1

The Information Company™ 4


Integrating OTDS 16.2 with OKTA

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

The Information Company™ 5


Integrating OTDS 16.2 with OKTA

7. Attribute Statements section, add three attribute statements.

Figure 4

8. Select I’m a software vendor. I’d like to integrate my app with OKTA and
select Finish.

Figure 5

9. Sign On section select Identity Provider metadata and save as an XML


formatted file to be uploaded in the OTDS Authentication Handler.

Figure 6

The Information Company™ 6


Integrating OTDS 16.2 with OKTA

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

Identity Provider (IdP) Initiated


1. Login to Development instance of OKTA, if you see < > Developer in the top left,
click it and select Classic UI
2. Select Add Applications
3. Select Create New App
4. From the drop down select Web as the Platform and SAML 2.0 as the Sign on
method and select Create

Figure 8

The Information Company™ 7


Integrating OTDS 16.2 with OKTA

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)

The Information Company™ 8


Integrating OTDS 16.2 with OKTA

Figure 10

7. Attribute Statements section, add three attribute statements.

Figure 11

8. Select I’m a software vendor. I’d like to integrate my app with OKTA and
select Finish.

Figure 12

The Information Company™ 9


Integrating OTDS 16.2 with OKTA

9. Sign On section select Identity Provider metadata and save as an XML


formatted file to be uploaded in the OTDS Authentication Handler.

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

The Information Company™ 10


Integrating OTDS 16.2 with OKTA

SAML Single Logout (SLO)

NOTE: This is an optional configuration, if SAML Single Logout


(SLO) is required OTDS must have an X509 (PEM) certificate and
PKCS#8 DER encoded private key created.

OTDS – Certificate Creation


1. Using OpenSSL generate private key and certificate
OpenSSL> req -x509 -days 365 -newkey rsa:2048 -keyout saml_key.pem -out
saml_cert.cer

Generating a 2048-bit RSA private key


.........................+++
..............................................................................................................+++
writing new private key to 'saml_key.pem'
Enter PEM pass phrase: ********
Verifying - Enter PEM pass phrase: ********
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CA
State or Province Name (full name) []:Ontario
Locality Name (eg, city) [Default City]:Waterloo
Organization Name (eg, company) [Default Company Ltd]:OpenText
Organizational Unit Name (eg, section) []:Customer Support
Common Name (eg, your name or your server's hostname) []:ds-app01.wlsupport.net
Email Address []:lnxadmin@wlsupport.net

The Information Company™ 11


Integrating OTDS 16.2 with OKTA

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

OKTA – Advanced Settings


1. Setup OKTA depending on business requirements, SP or IdP Initiated
2. Modify OKTA configuration, from SAML Settings page select Advanced
Settings
3. Check Allow application to initiate Single Logout
4. Single Logout URL is set to the OTDS logout endpoint
5. http://ds-app01.wlsupport.net:8080/otdsws/login?logout
6. SP Issuer is set to the http://ds-app01.wlsupport.net:8080/otdsws/login
7. If SP Issuer is incorrectly set SLO will fail and an error will be present in the
OKTA logs “failure: Issuer does not match”
8. Upload the saml_cert.cer previously created for the OTDS Server in Signature
Certificate.

The Information Company™ 12


Integrating OTDS 16.2 with OKTA

Figure 15

9. Select Next and then on the next page select Finish


10. Sign On section select Identity Provider metadata and save as an XML
formatted file to be uploaded in the OTDS Authentication Handler
a. If the metadata was previously downloaded and SLO was setup
afterwards, a new metadata.xml must be downloaded for OTDS
configuration as the SLO endpoint for OKTA has been added

The Information Company™ 13


Integrating OTDS 16.2 with OKTA

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

2. Non-Synchronized User Partition Auto-Provisioned Accounts has been created


and contains no users\groups

Figure 17

3. Add Auto-Provisioned Accounts User Partition to the Access Role of the Content
Server Resource

The Information Company™ 14


Integrating OTDS 16.2 with OKTA

SAML 2.0 Authentication Handler


1. Create a new SAML 2.0 Authentication Handler, the handler name will be OKTA.

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).

The Information Company™ 15


Integrating OTDS 16.2 with OKTA

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

The Information Company™ 16


Integrating OTDS 16.2 with OKTA

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

c. Save the Authentication Handler


5. Validate Authentication Handler was successfully created
a. Access the following URL that exports the SP (Service Provider) Metadata
b. http://ds-app01.wlsupport.net/otdsws/login?SAMLMetadata=OKTA

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

The Information Company™ 17


Integrating OTDS 16.2 with OKTA

Validate the Deployment

Test – OTDS Auto-Provisioning


1. Access http://cs-web01.wlsupport.net/CS162/cs.exe
a. Browser is redirected to OTDS
b. OTDS SAML Authentication Handler sends browser request to OKTA IdP
for authentication
c. User provides OKTA credentials in the presented form based popup
d. Once user has authenticated with OKTA they are returned to OTDS with
a SAML Assertion, OTDS determines that this user does not exist and
creates them
e. The user is pushed to Content Server and the Enterprise Workspace is
displayed to the user
2. OTDS after user has been created.

Figure 24

3. User Properties from the Auto-Provisioned Accounts partition

Figure 25

4. User is created with the following attributes

Figure 26

The Information Company™ 18


Integrating OTDS 16.2 with OKTA

Test – SAML Single Logout (SLO)


1. Access http://cs-web01.wlsupport.opentext.net/CS162/cs.exe
2. Once authenticated and Enterprise Workspace is accessed, selected Logout

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

The Information Company™ 19


Integrating OTDS 16.2 with OKTA

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:

OpenText CEO Mark Barrenechea’s blog


Twitter | LinkedIn | Facebook

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).

You might also like