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

Requesting access and managing authorized support contacts in the IBM Support Community

As we transition to the new IBM Support Community at https://www.ibm.com/mysupport you might have questions about the different capabilities available to users in the community and how their access to those capabilities can be managed. The good news is that your own organization can manage your users and their level of access. And from a user perspective this is largely done through self-service capabilities, often built right in to the community. Anyone familiar with the process for requesting access and managing authorized support contacts through the IBM Service Request tool that we have used for many years to support our on-premises software and hardware will see little change. But things are quite different for those who have only ever known the now discontinued IBM Client Success Portal where we used to provide support for many of our on-cloud services. Please review the document IBM Support Community: Requesting access and managing authorized support contacts for an overview of: the user roles and their associated capabilities in the IBM Support Community; how a user can request access to the IBM Support Community in a given role or request an upgrade to a higher role; how Administrators (the client's Site Technical Contact and their delegates) can access the User administration application embedded into the IBM Support Community to manage their authorized support contacts, auto-approve rules, and more; how a site's Primary Passport Advantage contact can change the Site Technical Contact through the Passport Advantage Online (PAO) portal; and what to do if the site's Primary Passport Advantage contact has left the organization.

Blog

We’ve improved your support experience!

We appreciate the opportunity to have you as a client.  IBM continually strives to seek new and better ways to improve the support experience we offer you.  With that in mind, we’re implementing some enhancements to our support model by launching a new IBM Support Community that all IBM products will move to over time. We are pleased to advise you that this weekend we have moved all client support – including discussion forums and support case management – for the following IBM Business Analytics cloud services to the new Support Community: IBM Cognos Analytics on Cloud IBM Cognos Controller on Cloud IBM Planning Analytics IBM Watson Analytics We know that you may have other IBM products that will also be migrating to this new support experience. Watch out for further information on the specific timing of this from the relevant support teams. Within the new Support Community, self-service capabilities are available to allow for better ease of use, including: Discussion forums where you can ask questions, help answer questions from other users, and interact with knowledgeable IBM staff Simplified search capability powered by IBM Watson to view knowledge artifacts, forum discussions, and support case history Support case creation/updates Ability to attach documents for review by support staff …and much more! We invite you to view the following short videos that provide an overview of the initial experience that will continue to evolve and become richer over time. Introducing the IBM Support Community: Search https://mediacenter.ibm.com/media/t/1_hjcvgybl Introducing the IBM Support Community: Forums https://mediacenter.ibm.com/media/t/1_dnpmr6oi IBM Support Community: Open and manage Cases https://mediacenter.ibm.com/media/t/1_47uqs38j During this weekend’s transition to the new Support Community your active support cases will be moved first followed by your case history, and can be found under the Cases tab once you have signed in. You can access the new support experience by following these steps: Go to  https://www.ibm.com/mysupport To participate in the discussion forums, and to submit and manage your support cases, you will need to sign in. If you sign in to your IBM Business Analytics cloud service using the same user name and password that you use on your organization’s network then you can sign in to the IBM Support Community the same way. Otherwise you should sign in using your IBMid user name and password. Note that this is not the same as your IBM Client Success Portal user name and password that you most likely use today to submit and manage your support tickets for your IBM Business Analytics cloud service. If you do not have an IBMid, you can sign up for one here: https://www.ibm.com/account/us-en/signup/register.html. Note that in the new support experience you will, by default, receive a notification email whenever an update is made to one of your ongoing cases. Please do not reply to this notification email as this will not update your case. The notification email contains a link directly to your case where you can review the details of the update and respond appropriately. You can configure your email notification preferences for support cases and discussion forum updates. Please see the following community release update for further information, https://www.ibm.com/mysupport/s/article/Case-Email-Notifications. If you experience a problem with the IBM Support Community (such as a login issue, etc.), we are here to help.  Please submit your issue via the link found near the end of each page in the community and someone will get back to you as quickly as possible. We hope you enjoy the enhancements of this new IBM support experience and always welcome your feedback.

Blog

Transition to a New IBM Support Portal

We heard you…and we are taking actions to improve your Support experience! IBM appreciates the opportunity to have you as a customer.  We always strive to seek new and better ways to improve our communications and support that we offer.  With that in mind, we are implementing a new Support Portal for a select number of IBM products, including Business Analytics. Our new portal will be supported by IBM Watson and will provide you with enhanced transparency into your ticket resolution workflow along with improved self-service options. You can watch a short video to learn more: https://ibm.co/2gKKwlK When we transition to the new Support Community, you will be able to access the new portal to open a new ticket (which will now be called a “case”).  At this time, you will no longer be able to access the current Support portal for the Business Analytics solution, and you will be redirected to our new Community. We will provide you with more detailed access information as we get closer to the transition date. The new Support Portal will be a “one-stop shop”for Customer Support related information for the Business Analytics solution, and will offer you the following self-service capabilities: Ticket creation/updates Ability to attach documents for review by Support Simplified search capability to view ticket history and knowledge base artifacts And much more! We will continue to expand this new platform so that all IBM customers will have this new, improved Support Experience. Should you have any questions, please contact your IBM Business Analytics team. Regards, IBM Business Analytics Support Team Also see... Adding Interested Parties to your case in the IBM Support Community What is the role of a Primary Site Contact How to request full access IBM Support Community Blog articles on the IBM Support Community  

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:    

Blog

Inviting team members to your case in the IBM Support Community

In the new IBM Support Community, you can invite other members of your team to stay informed about, or contribute to, a new or ongoing support case. Click the Case Number for the case that you would like to invite one or more of your team members to. In the right side of the case details page click the Invite other team members icon.       Select the team members that you want added to the case. Click Save. The team members that you have invited will now receive case update notifications. They can also add comments and upload files to the case. And they will find your case and others they’ve been invited to in the Cases I’m invited to views in the Cases section of the support community.   Need to add a team member to your list? If the person that you would like to invite to your case does not appear in the list of available team members then they may not yet be authorized to access support under your organization’s account or they may be authorized in the Basic User role, meaning that they can only see and update the cases that they own. For security reasons, only a user authorized in the Full User or Administrator role by your organization’s Site Technical Contact or his/her delegates can be selected to be a case team member as these roles allow them to see and update all cases submitted under your organization’s account. Once signed in to the support community users can check their current authorized role by selecting the User administration option from the user profile menu in the right of the page banner, If your colleague already has Basic User access a link is provided to request an upgrade to Full User access. However, if they have no current authorized role then they will need your organization’s IBM customer number and the country where it is registered to submit a request, You can find your IBM customer number and country to provide to your colleagues by checking your existing access under the User administration menu. Your organization’s Site Technical Contact and/or their delegates have the Administrator role and may have defined rules to automatically approve requests for the default Basic User role based on a user’s email address domain. However, they rarely do this for the Full User role and so requests for additional access usually trigger a notification to these administrators advising that there is a request pending their review and approval. This access can also be requested through our legacy IBM Service Request tool, https://www-946.ibm.com/sr/help/register.html Also see... The role of the Site Technical Contact IBM Service Request User Access Levels How to request full access IBM Support Community Blog articles on the IBM Support Community    

Blog

VIDEO: New Support Community coming December 11, 2017

In preparation for the upcoming shift to our new Support Community on December 11, here are three videos that serve as a good introduction - Introducing the IBM Support Community | Search Introducing the IBM Support Community | Forums Introducing the IBM Support Community | Open and manage cases