PDF(2.1 MB) View with Adobe Reader on a variety of devices
ePub(2.2 MB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(1.4 MB) View on Kindle device or Kindle app on multiple devices
Updated:October 5, 2018
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to integrate Identity Services Engine (ISE) with OKTA, to provide Security Assertion Markup Language Single Sign-On (SAML SSO) authentication for the guest portal.
Cisco recommends that you have knowledge of these topics:
Cisco Identity Services Engine guest services.
(optional) Wireless LAN Controller (WLC) configuration.
The information in this document is based on these software and hardware versions:
Identity Services Engine 184.108.40.2068
OKTA SAML SSO application
Cisco 5500 wireless controller version 220.127.116.11
Lenovo Windows 7
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
A user within organization can authenticate once and then have access to multiple resources. This identity used across organisations is called federated identity.
The concept of federation:
Principle: End-user (the one, who requests a service), web browser, in this case, is the endpoint.
Service provider (SP): sometimes called relying party (RP), which is the system that provides a service, in this case, ISE.
Identity provider (IdP): which manages the authentication, authorization result and attributes that are sent back to SP, in this case, OKTA.
Assertion: the user information sent by IdP to SP.
Several protocols implement SSO such as OAuth2 and OpenID. ISE uses SAML.
SAML is an XML-based framework that describes the use and exchange of SAML assertions in a secure way between business entities. The standard describes the syntax and rules to request, create, use, and exchange these assertions.
ISE uses SP initiated mode. The user is redirected to the Guest portal, then ISE redirects it to IdP to authenticate. After that, it redirects back to ISE. The request is validated, the user proceeds with guest access or on-boarding, depending on the portal configuration.
The user connects to the SSID, and the authentication is mac filtering (mab).
ISE responds back with access-accept that contains Redirect-URL and Redirect-ACL attributes
Step 1. Configure SAML Identity Provider and Guest portal on ISE.
1. Prepare External Identity Source.
Step 1. Navigate to Administration > External Identity Sources > SAML id Providers.
Step 2. Assign a name to the id provider and submit the configuration.
2. Create Portal for SSO.
Step 1. Create the portal which is assigned to OKTA as identity source. Any other configuration for BYOD, device registration, Guest ..etc, is exactly the same as for normal portal. In this document, the portal is mapped to the guest portal as an alternative login for Employee.
Step 2. Navigate to Work Centers > Guest Access > Portals & Components and create the portal.
Step 3. Choose the authentication method to point to the identity provider configured previously.
Step 4. Choose OKTA identity source as an authentication method.
(optional) choose the BYOD settings.
Step 5. Save the portal configuration, with BYOD the flow looks like this:
3. Configure Alternative Login.
Note: You can skip this part if you are not using the Alternative login.
Navigate to self-registration Guest Portal or any other portal customized for guest access.
On login page settings add the alternative login portal: OKTA_SSO.
This is the portal flow now.
Step 2. Configure OKTA Application and SAML Identity Provider Settings.
1. Create OKTA Application.
Step 1. Login to OKTA website with an admin account.
Step 2. Click on Add Application.
Step 3. Create New App, choose it to be SAML2.0
Step 4. Download the certificate and install it in ISE Trusted Certificates.
2. Export SP Information from SAML Identity Provider.
Navigate to the previously configured Identity Provider. Click on Service Provider Info and export it, as shown in the image.
The exported zip folder contains XML file and readme.txt
For some Identity providers you can import the XML directly, but in this case, it needs to import manually.
Now check again the application perhaps there are changes made.
The SSO URL is using IP address, however, guest is sending FQDN as we can see in the request above the last line contains SEMI_DELIMITER<FQDN> to fix this issue change the IP address to FQDN on OKTA settings.
Scenario 2. "There was a problem accessing the site. Please contact helpdesk for assistance".
2018-09-30 02:25:00,595 ERROR [https-jsse-nio-10.48.17.71-8443-exec-1] guestaccess.flowmanager.step.guest.SSOLoginStepExecutor -::- SSO Authentication failed or unknown user, authentication result=FAILED, isFailedLogin=true, reason=24823 Assertion does not contain ma
tching service provider identifier in the audience restriction conditions
2018-09-30 02:25:00,609 ERROR [https-jsse-nio-10.48.17.71-8443-exec-1] guestaccess.flowmanager.step.guest.SSOLoginStepExecutor -::- Login error with idp
From the logs, ISE reports that the Assertion is not correct. Check OKTA Audience URI ensure that it matches the SP to resolve it.
Scenario 3. Redirected to the Blank page, or the login option does not show.
It depends on the environment and the portal configuration. In this kind of issue you need to check the OKTA application and what URL's it require to authenticate. Click on the portal test then inspect element to check what websites must be reachable.
In this scenario only two URLs: application and login.okta.com - those should be permitted on the WLC.