Cloud Pak for Business Automation

 View Only
  • 1.  Cloudpak for Automation 20.0.0.3 - OKTA - AWS

    Posted Fri March 12, 2021 07:52 AM
    Most of the "CloudPak for Automation" installs, examples are always taking "external" database and "ldap" as default configurations. Looks like most of the testing from IBM is done only with this kind of setups. We are struggling to get CP4Auto installs/configurations with "okta"  and internal database (db in the same openshift cluster) in AWS. Looks like UMS is a must requirement to get this configured and even with UMS, there are multiple issues with mapping groups coming from OKTA into the UMS.  The authentication and authorization only works with a direct "User" mapping in the webSecurity.xml and nothing else. Looks like "oidc/okta" integration is very premature on this cloudpaks and IBM support is struggling to get this resolved. Did anyone faced similar issues? are there any cloudpak reference architectures/implementation examples for OIDC that anyone knows of?

    Thanks
    Vishy

    ------------------------------
    Vishy Kasinadhuni
    Travelers
    ------------------------------


  • 2.  RE: Cloudpak for Automation 20.0.0.3 - OKTA - AWS

    Posted Mon March 15, 2021 05:11 AM

    Hi Vishy,

    the current support struggle around group memberships asserted by Okta is unfortunate and I apologize for that. We have tested delegating authentication to a 3rd party IdP, but with an important difference that may have hidden this current issue: Cloud Pak for Automation today makes a very strong assumption of being connecting to an LDAP server.

    What Okta (or any other IdP) can give us in an assertion (SAML or OIDC or any other customized authentication) is information about the current user: unique user name, display name, email, group memberships. What IdPs cannot give us is information about other users and groups. Not being connected to LDAP implies significant limitations in some services:
    - ODM allows granting access to other users or groups
    - FNCM maintains access control lists for documents and folders
    - Workflow can assign tasks to users (while they are not logged in), e.g. based on group memberships
    - BA Studio / Business Automation Insights can grant access to projects / dashboards etc. to users / groups (that are not currently logged in)

    In all of the above cases, we need information about
    - Which users exist ?
    - Which groups exist ?
    - Which users are in which groups ?
    - In which groups is user ABC ?

    ODM and FNCM connect to LDAP directly. BA Studio, Workflow, BAI consume a SCIM API in UMS (which in turn connects to LDAP).

    As of today (20.0.3), almost all usage of CP4Auto services requires an LDAP connection to be configured. The two supported LDAP vendors are IBM Directory Server and Active Directory. 
    In air gapped environments, you may choose to host your own LDAP inside the cluster and populate it with data from your corporate LDAP, e.g. using SCIM. That said, I think that both, AD and IDS, are not easily hosted in AWS, GKE or other clouds (maybe except for AD in Azure). It is worth noting that CP4Auto demo patterns provision an instance of Open LDAP, however, this is not supported for production as this instance is not highly available.

    I see active work to improve in the above scenarios. Ideas include
    - Avoid direct LDAP connections from individual services, but instead consume SCIM.
    - Allow SCIM to be served from a local user / groups database that is independent from your LDAP.

    Such future enhancements would help your topology, but there is no committed timeline to share. 

    HTH



    ------------------------------
    Jens Engelke
    ------------------------------



  • 3.  RE: Cloudpak for Automation 20.0.0.3 - OKTA - AWS

    IBM Champion
    Posted Mon March 15, 2021 09:19 AM
    Given the choice, I'd rather see CP4BA UMS expose a SCIM 2.0 endpoint that can be used by the external IdP to provision users into the CP4BA UMS. Then all the apps inside CP4BA could use the UMS and that can be hidden internal implementation details.

    The approach where CP4BA expects a push to a SCIM 2.0 endpoint it hosts for user and role provisioning is, from my perspective, the most compatible approach. Then again, I don't think it's unreasonable to do role mapping. Allow us to define roles in CP4BA and then ensure that the role list in the OIDC claims includes a valid CP4BA role. This would enable automatic provisioning on login (FNCM has a mode that allows some automatic provisioning on login, but it does not do the role mapping, it just assigns default roles based on email domain).

    ------------------------------
    Eric Walk
    Senior Technical Architect

    O: 617-453-9983 | NASDAQ: PRFT | Perficient.com
    ------------------------------



  • 4.  RE: Cloudpak for Automation 20.0.0.3 - OKTA - AWS

    Posted Mon March 15, 2021 10:25 AM
    In most of the enterprise implementations of IDP (okta for example), it is integrated to either corporate AD/LDAP directly or by some other means, like csv etc. Why again another implementation of LDAP  into each of the product(s) that needs RBAC?  Exposing the SCIM api endpoint for IDP consumption is a good idea, if this also means having no additional configurations/customizations in IDP.

    My question is what advantages UMS brings to a customer, at least for CloudPaks components (like ODM) that doesn't  need them. UMS requirement should be a choice in these cases.

    Also, keep in mind, in cases like OpenShift, having UMS as requirement also means, now UMS should itself now provide a load balancing and fail-over, by letting multiple containers/pods in the cluster to collaborate for Single-Signon services. Usually the collaboration requires shared UMS database which should be kept in sync in the cluster. Things can complicate in scenario's where we have multiple projects/namespaces in the cluster that needs complete isolation. 


    Vishy

    ------------------------------
    Vishy Kasinadhuni
    Travelers
    ------------------------------