Cloud Pak for Data では、LDAP プロバイダーと連携してユーザー管理を行うことができます。
LDAP 側でユーザーを一括管理しているような環境において、LDAP 側で登録したユーザーを CP4D へのログインユーザーとして使用することで、ユーザー管理の一元化が実現できます
（参考：[Qiita] CP4D の LDAP と連携したユーザー管理）。

さらに、LDAP 側でユーザーに対して属性（ユーザーのロケーションや所属する組織、役職など）が設定されている場合、CP4D では、このユーザーの属性に応じて、CP4D リソースへのアクセス制御（属性ベースのアクセス制御（ABAC：Attribute Based Access Control））をおこなうことができます。
参考：[CP4D v4.8 マニュアル] データ保護ルール (IBM Knowledge Catalog)
　
例えば、あるユーザーが CP4D カタログの中の従業員情報テーブルを照会した際、そのユーザーがマネージャーであればそのテーブルの全列のデータを表示し、マネージャーでなければそのテーブルの特定列（例えば給与額の列など）のデータはマスキングして見せる（他の列のデータは表示）、といった制御が可能になります。
具体的には、以下の例のように、同じカタログのテーブルを参照した際、「staff」である John Geyer にはテーブルの「SALARY」列の値はマスキングして表示し、「manager」である Irving Stern にはテーブルの「SALARY」列の値を表示する、といった制御ができることになります。

あるいは、CP4D カタログの中の人事関連テーブルに対して、人事部に所属しているユーザーは閲覧可能とし、それ以外のユーザーに対してはテーブルへのアクセスを許可しない、といった制御なども可能です。

また、ABAC のための設定が完了した後で、LDAP 側でユーザー属性設定が変更された場合も、CP4D 側でのユーザー設定変更などの操作は不要であり、自動的に変更後の属性に応じたアクセス制御が有効になります。
例えば、前述 1 つ目の例で、マネージャーだったユーザーがマネージャーでなくなった場合、LDAP 側でそのユーザーの属性が変更された（役職がマネージャー以外に変更された）後にそのユーザーで CP4D にログインすると、属性変更前までは閲覧可能だったテーブルの「SALARY」列がマスキングされて表示されるようになります。
同様に、2 つ目の例で、人事部に所属していたユーザーが別の部署に移動した場合、LDAP 側でそのユーザーの属性が変更された（所属組織が人事部から別の部署に変更された）後にそのユーザーでログインすると、そのユーザーは人事関連テーブルにアクセスできなくなります。

このように、ABAC を使用することで、

セキュリティー体制の強化
- ユーザーの所属する組織や役職などに変更があった場合、それに気付かずに機密データ/リソースへのアクセスが付与されたままになってしまうことを防ぐことが可能
手動での労力/時間の削減
- CP4D 側で、手動で各ユーザーごとに Role を割り当てる必要がない

といったことが期待できます。

ID プロバイダー構成

CP4D を LDAP と連携するためには、CP4D 側で ID プロバイダー構成を行います。ここで、LDAP のサーバーやポート、LDAP 認証のための設定などを行っておきます。
参考：[CP4D v4.8 マニュアル] ID プロバイダーへの接続

また、ABAC を実現するためには、ID プロバイダー構成の設定の中で、「SCIM 構成」も設定する必要があります。
参考：[IBM Cloud Pak foundational services
4.6 マニュアル] SCIM configuration by using your product UI

動的ユーザー・グループを作成

次に、CP4D ユーザー・グループを作成しますが、ABAC を実現するためには、ユーザー・グループを作成する際に、ユーザーの属性（LDAP 側でユーザーに設定した属性）をベースとしたルール（メンバーシップ・ルール）を設定します。そのルールに応じて、ユーザー・グループに含めるユーザーを自動かつ動的に決定することができます。このようなユーザー・グループを、動的ユーザー・グループと言います。
尚、動的ユーザー・グループは、Identity Management Service と統合されている場合にのみ使用可能なため、ABAC を可能にするためには、対象の CP4D が Identity Management Service と統合されている必要があります。（CP4D v4.8 以降、デフォルトで統合されています。）

CP4D では、デフォルトで、以下のユーザーの属性を使用して動的ユーザー・グループのメンバーシップ・ルールを定義することができます。
Location（場所）
Nationality（国籍）
Organization（組織）
User type（ユーザー・タイプ）

ユーザーは、ユーザーに設定されている属性に基づいて、動的ユーザー・グループに対して自動的に追加または削除されます。

参考：[CP4D v4.8.x マニュアル] LDAP サーバーを使用した動的ユーザー・グループの作成

例

ここでは、前述 1 つ目の例の ABAC を設定するために、以下のような動的ユーザー・グループを作成します。（今回は、LDAP として Active Directory を使用）

Active Directory 側のグループ/ユーザー
- グループ「groupB」
- グループ「groupB」配下にユーザー「john」、「irving」
- ユーザー「john」のtitle（役職）：staff
- ユーザー「Irving：のtitle（役職）：manager
CP4D 側で動的ユーザー・グループを作成
- グループ「cp4dgrp_manager」
- メンバーシップ・ルールを設定
  - 属性「User Type」= 値「manager」
- Role：「Business Analyst」をアサイン

ユーザー・グループ作成は、CP4Dの「アクセス制御」画面にて実施します。
以下は、ユーザー・グループ「cp4dgrp_manager」作成時の例です。

「アクセス制御」の「ユーザー・グループ」タブで、「新しいユーザー・グループ」をクリック

　
「名前」を入力し、「次へ」をクリック
　 ※ この際、「メンバーシップ・タイプ」として「Dynamic」を選択

　
「メンバーシップ・ルール」を設定し、「次へ」をクリック

　
ロールをアサインして「次へ」をクリック

　
要約内容を確認し、「作成」をクリック

　
これで、「manager」属性のユーザーのみを含む、「cp4dgrp_manager」が作成されます。
この時点では、「manager」属性が設定されている irving のみが、自動的に「cp4dgrp_manager」グループのメンバーになります。

この状態から、john が manager になる（LDAP 側で title 属性が「staff」から「manager」に変更される）と、john も自動的に「cp4dgrp_manager」グループのメンバーになります。

同様に、元々 manager だった irving が manager でなくなる（LDAP 側で、title 属性が「manager」から「staff」に変更される）と、irving は自動的にその CP4D ユーザー・グループから削除されます。

尚、CP4D 側には、LDAP 側で属性を変更したタイミングではなく、そのユーザーが CP4D にログインしたタイミングで属性変更の情報が反映されます。

動的ユーザー・グループを使用したアクセス制御

この動的ユーザー・グループを使用して、CP4D のカタログに登録されているテーブルへのアクセスを制御することが可能です。

例

カタログに登録されている以下のテーブルに対して、「manager」属性を持つユーザーのみが全列読み取り可能、それ以外のユーザーに対しては「SALARY」列をマスキングして表示する、といった制御をおこなう場合の例です。
この際の各ユーザーのユーザー属性は、上記の最後の状態（john が「manager」、irving が「staff」）とします。

対象となるカタログは、作成時に「データ保護ルールの適用」を有効にしておきます。

ユーザーが、ユーザー・グループ「cp4dgrp_manager」に属さない（＝「manager」ではない）場合には「SALARY」列を編集する、という内容で、データ保護ルールを作成します。

データ保護ルール作成画面にて、「この規則が適用される条件」として、以下を設定します。

「ユーザー・グループ」
「次のいずれも含まない」
「cp4dgrp_manager」

また、「このルールの目的」として、

「列の編集」
列に次の用語がある場合「列名」
次のいずれかを含む「SALARY」
を設定します。

これにより、「manager」である john でカタログ（「データ保護ルールの適用」が有効）のテーブルにアクセスした際は、「SALARY」列含め全列のデータが表示されます。

一方で、「manager」ではない irving でカタログのテーブルにアクセスした際は、「SALARY」列が編集された状態でデータが表示されます。

このように、LDAP 側で設定したユーザー属性に応じて、CP4D 側資産へのアクセスを制御することが可能です。
この例ではデータをマスキングしていますが、それ以外にも、データへのアクセスの拒否や列の難読化といった対応も可能です。