CMS API : Fetching typeDefinitions / namespaces for regular users ?

Options

I noticed that for a given namespace/typeDefinition , only users that are tenant or owner of

that namespace/typeDefinition can fetch it through the API GET /cms/namespaces , GET

/cms/type-definitions/ , GET /cms/type-definitions/attributes ,

What could be the solution for this issue ? maybe user impersonation ?

Answers

  • @jpluimers , any idea on how to soleve this issue ?

  • jpluimers
    Options

    @Med_2024 , in general, CMS has the option to apply acls.
    I did a quick test where I used VS Code to define a namespace and type, then deployed this.
    After that I created/added a new user (normal user with no specific roles) to my app (in the tenant/subscription).
    In my Rest client I retrieved an access-token and did a GET on https://na-1-dev.api.opentext.com/cms/type-definitions/med24_med2024mydef which did return the type definition.

    Requesting the type definition acl shows via https://na-1-dev.api.opentext.com/cms/type-definitions/med24_med2024mydef/aclshows the following permits for the type definition:
    "permits": [
    {
    "identity": "subscription_users",
    "identity_type": "role_alias",
    "permissions": [
    "browse"
    ]
    }
    ],

    Can you check the permits for your type definition? Does it also have the browse permission for subscription users?

  • As @jpluimers states, all namespace, type and trait definitions have a browse permit for any user of that subscription. Just make sure that the namespace and type definitions were created for that application. As a tenant admin/subscription admin you can see all the namespaces, types and traits in all subscriptions inside the tenant.

    As a second note, if you want, you can also design a backend for your application that can run such system calls as "system". In this case, your backend should get a client_credentials token (using the Confidential client id and secret) and use that token to fetch system data and then send the results back to your frontend app.

  • @jpluimers , when I execute GET

    https://na-1-dev.api.opentext.com/cms/type-definitions/corres_outgoing_correspondence/acl with the tenant ,

    but when executed with the created user

  • Is this the Application Subscription that you used to create the type with? The user needs to login under the same subscription to view the type definition.

    If you created the type using Postman - check to see which client_id you used to authenticate, then make sure that the normal user logs in to the same application subscription.

    If you created the type using VSCode, make sure that the application set in VSCode is the same that the normal user logs in.

  • The app (namespace , types ) was created using the VSCode , it's the same Application subscription

    (client id and client secret) , with the created user I can fetch the type instances of the type defintion , but

    not the type defintion itself

  • jpluimers
    Options

    As we see in your screenshot, the acl on the type definition allows subscription_users to browse. That allows them to see the type definition.

    What I did in my test is add a user to the 'Users' of the app, and wit that making it a subscriptino user for the app. Then sent an oauth request with the ClientID/secret of the App (as given in VS Code on first deployment), type as password and the username and password of the user. This given an access-token for the user as subscription user on the app, and with that I can retrieve the type definition.

    Can you try with a new app with only a namespace and type and follow above steps? Just to have the simplest reproduction case?

  • Can you please try the following:

    Go to Admin console, login as the Organization admin and then go to your Tenant → Apps → Your App → User Management → Roles → ims_user and add your user there.

    Get a new token and then try to get the type again.

  • @LazarescuA , I added my user under role_ims as you proposed still getting the same response

    {
    "path":"https://na-1-dev.api.opentext.com/cms/type-definitions/corres_incoming_correspondence",
    "title":"Not Found",
    "status":404,
    "details":"Type entity with id d05a0902-994a-4475-a0c5-c59634598221 not found"
    }

  • And if you add them to the ims_admin role, do they see it then?

  • @LazarescuA , @jpluimers I created another app with one namespace , one type , added a new user and he can see the type.

    It seems that for some reason the issue is with my first app , tried with different users with different roles

    ims_admin, ims_user , always the same issue , I don't what I should do ?

  • Can you check the following:

    On your initial application, get the subscription ID (In Admin center, Organization → Tenant → Apps → Click on your app) and see it in the browser address:

    Check the ACL on the type you are not seeing with a normal user:

    Get the ACL ID for the type: https://{{host}}/cms/type-definitions/{{type_name}}

    In the result JSON, get the acl_id

    Then get the ACL Information: https://{{host}}/cms/permissions/{{acl_id}}

    In the result JSON, check the ACL name:

    The ID inside the name of the ACL should match the subscription ID, otherwise the role_alias is not going to return your current user within the subscription.

    You can manually add in the ACL new groups/users and they will then see the type definition.

  • @LazarescuA , indeed the ID inside the name of the ACL and the subscription ID aren't a match !

    How to manually add in the ACL new groups/users ?

  • @Med_2024 , you can follow the documentation on developer.opentext.com for the Content Metadata Service (https://developer.opentext.com/imservices/products/contentmetadataservice/apis/contentmetadata) in the section Permissions, PATCH Permission:

    I used the following:

    • I have a user that logs in to a different subscription, a type defined in the initial subscription, I log in and don't see the type (404 error on getting the type)
    • The user is part of a Tenant Group (AllUsers_Google IDP)
    • added a Tenant Group in the ACL definition for my initial subscription like this:
      • get a token with an admin account
      • get the type permission id (see my previous answer)
      • API patch to the /cms/permissions/{acl_id}
      • payload (in red is what I added, rest was already there - you can probably omit the description and initial permits since this is a patch call):
    • ran the type get call again (same token) and it works

  • @LazarescuA , do you have an idea what should be the identity_type if the group is created in app level so it's not a tenant_group ?

    Also tried with user , getting the error     "details": "Multiple users found with email

    '********************************.com'. Try using specific id" , what should be the specific id ?

  • Hello @Med_2024 ,

    If the group is created at the App Level, it will be a subscription_group.

    You can add a specific user either by email or by their ID - to get their ID, see the Administration API: https://developer.opentext.com/imservices/developertools/developeradmin/apis/developeradministrationapi and look at the Tenant Users:

    The calls above will return the user id.

    PS: when adding a specific user, in the patch call, the permits element has the following structure:

    • identity will be the email or ID of the user
    • identity_type will be "user"
    • permissions will be the array of permissions