Azure AD OpenID Connect API v1 (Azure AD for developers 1.0) doesn't support returning the groups claim in the ROPC (Resource Owner Password Credentials) logon method that Cognos uses to Authorize Stored Credentials for scheduled tasks and jobs. Since the groups claim is not returned via this authentication method, the session ends up with no Roles, Capabilities, or Permissions, and the scheduled task or job fails. This prevents the use of Azure AD groups to provision an user or service account. Therefore Cognos needs to support the Azure AD OpenID Connect API v2 (Microsoft Identity Platform 2.0), so that groups claim can be returned through ROPC logon.
This is currently affecting our 1200 user environment, we moved to Azure AD from Active Directory with SSO because this met with our Security Requirements and Policies. We have had to implement a service account that has access to all Roles, Capabilities, and Permissions to all items in Cognos. Several times a day we look for and move any User schedules to run as the service account. Please refer to TS003289567 for more details.
The following is the Justification we sent to Support so that this would be classified a Bug, but now we are having to request this enhancement.
1. We moved from v10.2.2 fp8 using SSO w/Active Directory where users were able to schedule reports in November 2019 to v11.1.3
2. We have experienced feature regression because of the issue identified with Cognos using an unsupported method of authentication with Azure AD v1 API
3. We chose AzureAD because from the documentation available it appeared that it was supported, and this met our Corporate Security Policies and Requirements for new application deployments
4. We invested $600,000.00 in this upgrade project
5. We invested 100s of Admin/Engineer/Architect hours designing and deploying all new Cognos environments (Dev, QA, Prod), manually setting all permissions to Azure AD groups equivalent to the Active Directory groups in the new environments, rebuilding all Role and Capabilities from net new.
6. We invested 100s of hours of Project Management/Management/Report Developer time to test and validate reports on 11.1.3
7. We invested in new infrastructure for more powerful server hardware (10 year difference in hardware age)
8. We had employees who were committed to making the migration to 11 successful that turned in 80-100 hour weeks to only immediately run into the Azure AD issue, and instead of being able to relax, this started a 2 month process to convince IBM support there was a flaw in the Azure AD authentication component.
9. We have 1200 active users, and permissions drift would be about 1% (or affect an average of 12 users) a day
10. This has taken away the ability for Cognos to be a self service environment for our users, eroding confidence in the platform, they are turning to competitors
11. We justified the project expenditure and advertised to the user base how the new version is all about self-service and now they can't even create schedules
12. We have invested 100s hours in troubleshooting, researching, and working through IBM support to get to the point of getting the issue identified and acknowledged
13. This failure has resulted in dozens of admin hours curating scheduled items to re-assign them to a bespoke service account that has been granted broad permissions so that users will receive the report they have scheduled.
14. We can't leverage Generic OIDC because we would lose the use of "Graph" (UID lookup to Group Name and Membership via https://graph.microsoft.com) and would have to manage all user membership manually.
15. Manual: We would have to write a custom process to export users daily from Active Directory group membership into CSV and then import them into Cognos Roles daily to meet Security Requirements, and run a comparison for permissions removed and manually process those.
16. Because the Azure AD component wasn't completely tested during development and Cognos is unable to retrieve groups when using stored credentials, this problem should be a defect with an appropriate APAR.
17. Moving to Generic OIDC, ADFS, or back to SSO w/AD would require building new environments in parallel, resolving the group membership issues, and 100+ hours of Admin/Engineer time to deploy new servers, configure, and migrate report content
18. ADFS, SSO w/AD, or a manual process will require a lot of internal bureaucracy and exception approvals for deviations from Security Policy easily consuming 100+ hours of Admin/Engineer/Architect/Management time
This feature has been implemented:
In 11.1.7 it is called MS Identity
In 11.2.x it will be called MS Identity Platform 2.0