Blog

What's happening? What's new? What can I do? Find answers to these questions in the blog.

Archive Results

Blog

Administration: How to setup a Generic OpenID Namespace against Auth0 with Cognos Analytics 11

The purpose of this blog is to extend the capabilities of the number of supported OpenID Connect Providers with Cognos Analytics to now include the Generic OpenID Identity Provider. This allows the ability to “customize” the configuration based on the Identity Provider of choice not listed. Here we have a real lab example of configuring a Generic OpenID against Auth0: Environment: Windows 2016 Single Installation Cognos Analytics 11.0.11+ Identity Provider: Auth0 Section 1: Steps to creating and configuring an Auth0 application: 1. Create an Auth0 Application by clicking on “CREATE APPLICATION” button 2. Give the application a name e.g. IBMSUPPORT in this case 3. Click on the “Settings” where the ClientID, Client Secret are shown: 4. Scroll down to “Allowed Callback URLs” and add the Cognos Analytics URL 5. Click Save 6. Access the https://manage.auth0.com/#/tenant 7. Set the “Default Directory” to “Username-Password-Authentication” and click “Save” Section 2: Collect all the information required and create a Generic Namespace The following information is required: ClientID Client Secret Redirect URL 8. Download the Issuer Certificate by accessing http://auth0.com   9. Save and transfer over to the Cognos Analytics <install>/bin64 directory 10. Import the certificate using the following command line: <install>\bin>ThirdPartyCertificateTool.bat -i -T -r <certificate> -p NoPassWordSet 11. Launch Cognos Configuration and create a new Generic Namespace:     12. Update only the following details Customize from default values and the following are only required in this case: Discovery Endpoint URL Scope for Authorized Endpoints (default is openid): openid profile email name given_name family_name offline_access Password Grant – Strategy: UserInfo endpoint Username: nickname NB: The settings required for a Generic Template may vary depending on the IdP (Id Provider) and the supported Grant Types and Claims. Also ensuring all URI’s are SSL enabled i.e. switch from http to httpS including the redirect url. 13. Test the Connection   When the “Testing ‘IBMSUPPORT’ namespace” is successful then the imported certificate is trusted. However, the userID/password to test the connection may fail with Status 403 error. To resolve this, disable the “OIDC Conformant” setting as follows: 14. Application - <Application> - Advanced Settings – Oath and Disable the “OIDC Conformant”   15. From that same page select “Grant Types” and unselect “Client Credentials” and select “Passwords” 16. Now, test the connection again and it should succeed 17. Save and start the CA Service 18. Select the Generic Namespace which redirects to the Auth0 Log-In Page:   19. Log in using your email address and then it will redirect back to CA and login seamlessly:   Optional: Check the Namespace is active (IBMSUPPORT) from Manage – Administration - Security Additional Information Create Additional Users: From the Dashboard Select “Users” and then “CREATE USER” button Populate the Email, Password and Repeat Password fields. References: Auth0 Documentation Cognos Analytics OpenID Connect authentication providers Other OpenID Blogs Administration: How to setup #Cognos Analytics OpenID Authentication Proxy federating with Active Directory and LDAP over AD Administration : How to setup ADFS OIDC with #Cognos Analytics Release R9+ Administration: How to setup and authenticate via OIDC OKTA integration with AD on-premise and Cognos Analytics 11 R9+ Administration – How to Setup OpenID Connect using OKTA Identity Provider with #Cognos Analytics Release 8+  

Blog

Administration: How to setup #Cognos Analytics OpenID Authentication Proxy federating with Active Directory and LDAP over AD

The purpose of this document is to walk through step-by-step in setting up OpenID Authentication Proxy Federation with Active Directory and with LDAP over Active Directory Namespaces. The following is an actual lab setup: Environment: Active Directory: Windows 2016 Domain: CASUPPORT Cognos Analytics 11 R10+ OS: Windows 2016 Identity Provider: OKTA Before we start, it’s important to assume that users can successfully authentication independently with OKTA, AD or LDAP over AD configured with their Cognos Analytics environment (See Appendix A) via SSO (if enabled) Below is a list of the preconfigured namespaces that will be federated using OpenID Authentication Proxy: Environment: Gateway URL NB: Gateway Configuration in this scenario must be setup successfully. OKTA: OKTA-DEV AD: AD2016 LDAP: ADLDAP Configuration for OpenID Authentication Proxy and LDAP over AD Namespace Steps are as follows: Open Cognos Configuration and Create a new Namespace Fill in the same details as for the OKTA Namespace i.e. Discovery Endpoint, ClientID, Client Secret and Return URL. The important parts are: Identity claim name Trusted environment name: REMOTE_USER (Default) Redirect namespace ID: <Federating to the LDAP over AD Namespace> So here are how those 3 fields are mapped: Identity claim name: sAMAccountName Trusted environment name: REMOTE_USER Redirect namespace ID: ADLDAP REMOTE_USER variable is required for SSO via Gateway Configuration for OpenID Authentication Proxy and AD Namespace 1.Open Cognos Configuration and Create a new Namespace 2. Fill in the same details as for the OKTA Namespace i.e. Discovery Endpoint, ClientID, Client Secret and Return URL. With regards to the Identity claim name field for AD it’s important that the correct “common” attribute (claim) is found that contains the user name. So, if you review the Discovery Endpoint Document list of “Claims Supported”: https://dev-297076-admin.oktapreview.com:443/.well-known/openid-configuration you will see the “name” claim. Then review the list of attributes for any authenticating user in AD and locate the “name” attribute. See below: Identity claim name: Specifies the name of the claim that will be provided to the target namespace. A string that represents the name of the claim from the id_token that will be provided to the target namespace. So here it’s the “name” claim from the id_token that will be passed to the “target namespace” (AD2016) which also has a “name” attribute which exists for all users. 3.Save and restart Switch on OIDC Tracing via the Custom Topics you will see the decoded id_token you will see the “name” claim: Additional Information Appendix A: Cognos Analytics 11 OpenID Connect - OpenID Connect Authentication Proxy Setting up Cognos Analytics 11 with OKTA Setting up Cognos Analytics 11 with AD/LDAP Setting up SSO with Cognos Analytics 11 and IIS

Blog

Administration: How to setup and authenticate via OIDC OKTA integration with AD on-premise and Cognos Analytics 11 R9+

  Introduction The purpose here is to leverage the integration of OKTA integrated with AD on-premise allowing both AD and OKTA users to successfully authenticate from Cognos Analytics using a SINGLE namespace. The steps below are in simplistic yet “hands-on” to walk through each step,  assuming that the audience is now able to create an OKTA namespace with OIDC. Environment OKTA Organisation AD on-Premise: CASUPPORT.SUPPORT2016.AD.HURSLEY.IBM.COM Server: Cognos Analytics 11 R9 Steps Assume OKTA application has been setup according to the following article. Access the OKTA Dashboard, switch to Classic UI and select from the Directory menu, click Directory Integrations. Select Add Active Directory or Add AD Domain/Agent  Click Add AD Domain/Agent and then click Active Directory Now download the AD Agent by clicking Download Agent. Save the installation file on any server that is part of the AD Domain Run the installation   Specify the FULL DomainDNS - CASUPPORT.support2016.ad.hursley.ibm.com   Select either Create or use the OktaService account (recommended) or Use an alternative account that I specify. Here despite the option to create a new service account, the installation detected that the OktaService account already existed otherwise it would create the account and request a password.   Type the password and click NextClick Next The type of OKTA customer domain depends on the OKTA Access URL. In this example it's: https://dev-170098-admin.oktapreview.com/dev/console So, the entries should be as follows:   Click Next Log in using the okta account Type in the okta admin account (admin) and password then click Sign In. Click Allow Access and then Finish.   Log into OKTA and go to Directory, Directory Integrations and click Active Directory. Select which OUs to sync users from: Select the OUs to sync Groups fromNB: Selections are based on AD Hierarchy Structure defined Select the Okta username format. The options are sAMAccountName or UPN. Click Next and then click Next to initiate the import. In Section 3, Select the attributes to build your Okta User Profile leave the defaults and select Next. Click Import. Since this is the first time select Full Import and click Import.   Import completed successfully Select the AD users and select Confirm Assignments Click Auto-activate users after confirmation and click Confirm. Click People to view the list of imported AD users In this example the AD user TM1USER (tm1@casupport.support2016.ad.hursley.ibm.com) will be used to demonstrate the login using both AD and OKTA using the same OIDC Namespace for OKTA Assign an AD and OKTA user to the ApplicationFrom the Dashboard select Application and then click the application link followed by selecting the Assignments tab and select Assign button. Select the user in this case TM1USER (AD user) and OKTA user (email address)Then click Assign Applications button and the click Assign. The AD user info appears then click Save and Go Back and then Done. Repeat for the okta user email account.   Authenticate now with the AD user Authenticate with an OKTA user Both belonging to the same namespace Group/Role Management Combining both type of users into a Cognos Group Create a Cognos Group and add BOTH users (AD and Okta) as members As an example create a Group called “OKTA-AD-Group” from the Cognos Namespace and then add both members to the group.          

Blog

Administration : How to setup ADFS OIDC with #Cognos Analytics Release R9+

The purpose of this blog is to appreciate the extent of which OIDC can be implemented across multiple Identity Providers supported by Cognos Analytics 11 R8+ which include ADFS (Active Directory Federation Services). The steps below will outline the steps to creating an Application and configuring the Namespace Provider OpenID Connect using ADFS. This will allow federating users within the 2016 AD Domain environment. Environment: Windows 2016 CA 11 R9 Sub Domain: CASUPPORT ADFS installed Steps are as follows: 1. Create an ADFS application 2. Add the CALLBACK URI to the CA 11 Application Click ‘NEXT’ 3. Generate the Shared Secret Client Secret - XW8CH_3qW__rl2t5UEElcm68MRk1Gq6J2doiYws5 Click ‘NEXT’ Summary Info Click ‘NEXT’ and ‘CLOSE’ 4. So we know have the required information to setup the OIDC and that is: Client ID - 100f85d4-7ed8-4826-91b2-b8ad2021963d Redirect URI - https://tm-win2016.CASUPPORT.support2016.ad.hursley.ibm.com:9300/bi/completeAuth.jsp Client Secret - XW8CH_3qW__rl2t5UEElcm68MRk1Gq6J2doiYws5 5. To capture the Discovery Point, it’s simply the ADFS host where in this example it’s the same machine where CA11 is installed but can be on any server. 6. Now using the information captured from the ADFS Application, the details are used when creating the OIDC/ADFS Namespace. See below 7. Switch ALL the URI’s to use https 8. If the optional gateway is used then enable SSL at the gateway 9. Export the Issuer Certificate used for signing the webserver 10. Select ‘NEXT’ and select ‘Base-64 encoded X.509 (.CER)’ Give it any name and location 11. Click ‘NEXT’ and ‘FINISH’ Now, we need to import the exported certificate into the CAM Keystore using the following command line but first stop the service: 12. Start the service by opening the cognos configuration, save and start. When you launch the browser and try to access the URI : https://tm-win2016.casupport.support2016.ad.hursley.ibm.com:9300/bi/v1/disp It appears there are issues with the certificate Click on “Continue to this website (not recommended) and despite the certificate error, you successfully log in. Click on ‘View certificates’ Click on “View Certificate” and then select “Install…” and select ‘Local Machine’ and select the ‘Trusted Root Certification Authorities’ Certificate Store. Troubleshooting When initially setting up the OIDC provider, saving/starting the configuration, the namespace will fail with the following exception: This is due to the missing issuers certificate If you switch to the optional gateway and change the Gateway URI to : The problem is the callback URI doesn’t contain a gateway URI so to resolve this, make sure the call back URI exists in the ADFS Application and in the OIDC Provider Settings. See below: Add the callback URI using the gateway Modify the OIDC Provider Setting ‘Redirect URI’ Restart

Blog

Administration - How to Setup OpenID Connect using OKTA Identity Provider with #Cognos Analytics Release 8+

Introduction Cognos Analytics 11 leverages OIDC (OpenID Connect) Identity Provider supporting customers who wish to take advantage of federation security with web applications. The purpose of this blog is to provide a lab experience of setting up an OIDC authentication provider using OKTA with Cognos Analytics 11 R8+ by walking through the experience in a ‘step-by-step’ format. Basics/Terminology - OpenID Connect (OIDC) OIDC allows client applications to verify the identity of an authenticating user performed by an OIDC Provider. In its simplistic form it’s an open standard identity protocol built on top of the OAuth 2.0 protocol. Claims – name/value pairs that contain information about a user, examples like ‘family_name’, ‘given_name’, ‘locale’, ‘name’, ‘sub’, ‘zoneinfo’. ID Token – A JSON Web Token (JWT) which contains claims about the authenticated user OpenID Connect Provider (OIDCP) – An OAuth 2.0 Authorization Server which can authenticate users and provide claims to a client. Further information can be found here:  http://openid.net/connect/faq/ Environment Single Server Installation Windows 2016 CA11 R8 IIS Gateway with SSL over HTTP OKTA Lab Experience – Step-by-Step Guide Create an Application Log into the OKTA Developer Portal and create a new Application   For the Platform Drop-Down, select ‘Native’ and click on ‘Create’ Provide a name for the application and also the Login Redirect URI(s) that is used when configuring the provider in cognos configuration as the Return URL configured with the OpenID Connect identity provider. The ‘Login redirect URIs’ take the format : https://dispatcherHOST:dispatcherPORT/bi/completeAuth.jsp or https://webserverHOST:webserverPORT/ibmcognos/bi/completeAuth.jsp. This URL completes Cognos Analytics authentication using the OpenID Connect identity provider. So, the above ‘Login redirect URI(s)’ will match the Redirect URI in the OKTA OIDC Provider in Cognos Configuration (see below) Now, click on the ‘General’ tab and then the ‘edit’ in the right-corner and select the following options for both ‘General Settings’ – ‘Allowed grant types ’ and ‘Client Credentials’: On ‘Save’ the ‘Client Credentials’ section will generate three important pieces of information that will be part of the required OKTA configuration settings in Cognos Configuration which are: Redirect URL, Client ID and Client Secret: Click on the "Sign-On" tab and in the section "OpenID Connect ID Token" click "edit" and for "Groups Claim Type" - Filter and "Group Claim Filter" - "Groups" - Regex - .* The next stage is to create a user, group and assign these to the above created application. Create a user Create a new user with a valid email address. Once a validation email is sent, reset the password. Create a Group From the main menu select ‘Directory’– ‘Groups’ - Add Group Assign user to the newly created Group From the same groups page, search for the newly created group Click on the Group name, search for the user or select from the list and click on ‘Add All’ then ‘Save’ Assign user to application Now, assign the user to the newly created application by selecting ‘Applications’ and then click on the newly created application, in this case ‘CASUPPORT_OKTA_NATIVE’ Click on ‘Assign’ – ‘Assign to People’ Select the new user (email) created from the list and click on ‘Done’ The User dialog box appears listing the properties which can be filled in where needed. Otherwise click on ‘Save and Go Back’. Then click ‘Done’ Create the Cognos OIDC OKTA Provider Now, using the information captured from creating the application, a new Authentication Provider is created in Cognos Configuration Launch Cognos Configuration and create a NEW Authentication Provider Fill in the details using the information obtained in point 5 above Details to add are: Discovery Point: https://dev-430078.oktapreview.com:443/.well-known/openid-configuration Client Identifier:       OpenID Connect Client Secret:     Return URL:             NB: Its possible to include additional redirect URIs as multiple environments can share the same OKTA Application Now, save the configuration and EXIT (do NOT start) Export Certificate Next step is to export the OKTA Certificate (Issuer) and import that into the CAM Keystore. Using Firefox click on the secured padlock key: Click on ‘>’ to show connection details and then click on ‘More Information’ Export the certificate -oktapreviewcom.crt, removed the ‘~’ from the file name so its ‘oktapreviewcom.crt’ Import into the Cognos CAM Keystore Copy the file to the Cognos Analytics installation directory analytics/bin64 Navigate to the analytics/bin directory and run the following command line: E:\Program Files\ibm\cognos\analytics1108\bin>ThirdPartyCertificateTool.bat -i -T -r oktapreviewcom.crt -p NoPassWordSet Open Cognos Configuration and change ALL the Dispatcher URI’s protocol from HTTP to HTTPS. NB: If the optional gateway is used then switch to SSL Restart via Cognos Configuration and log in. To check the Group associated with the user’s identity by going to ‘My Preferences’ – ‘Personal’ – ‘Advanced ‘ – ‘Groups and Roles’ – ‘View Details’ the group is visible. Adding additional OKTA Groups (Claims), these are visible when using the #CSVIdentityNameList()# macro in FM Additional Details Using the Cognos Analytics OIDC Custom Topic for Diagnostic Logging Steps are as follows: Log On -  Manage – Configuration – Diagnostic Logging Click on ‘AAA’ and select the properties (vertical 3 dots) and download as AAA.json Edit the json file and add the following entry: OIDC Tracing So to focus ONLY on ODIC tracing, the json file looks like this: Save the json file and then upload it by clicking on Manage – Configuration – Diagnostic Logging – Custom Topics – ‘upload topic’. Navigate to the json file and upload. Then log out and back in. Check the /logs/cognosserver.log file and details such as below will be captured: