Accessing Application Groups

Solusoft

We need to get list of application groups.

We found two different APIs for this. One in admin API and one in Content Metadata Service APIs.

What is the difference between these two APIs? Which one is recommended if we want to access group by user who is not application administrator? Which API supports filter using group name?

LazarescuA

I just wanted to point out that the cms/… endpoint refers to the cms service only. It will cascade the users/groups you create here but they might have different id's.

The endpoint you should be using to work programmatically with users/groups is the admin endpoint (organization/…/subscription/…). Those will be the actual users that can login to your application.

For your question above, there are a couple of solutions:

1. As Roger said, you can use a backend. Indeed, the backend needs credentials and you can use a keystore to encrypt credentials so that they are safely guarded.
2. External authentication: you can add another authenticator in OCP and your users will authenticate against that authenticator (Google IdP, Azure, AD, etc.) - then you can query that authenticator through its API's
3. Snapshot: if all your users/groups are going to be created within your application, also create an entry in the cms service (cms_object) for each group and its members. Then you can assign ACL's, can filter, etc. - so you can expose that information to your end-users. You can also have super users (admins) that could click a button and regenerate all the information in case something is out of sync. In this case, the app will use the admin's credentials and recreate all cms objects based on real users/groups in the system.

Roger K

The CMS groups are really in place to support the Workspace case roles functionality within Core Content. For example an Employee workspace for Fred Smith would have the roles Manager and HR Business Partner defined on them. These roles are actually implemented as CMS groups.

For your developer applications you should use the application subscription groups as this is where all services are configured to pick up users and groups from by default.

WRT your question to accessing group information and making it available to an end user - we deliberately do not make group information available to end users as this is security information which we have no real idea as to how it is being used. For your application, if you want to make a list of subscription groups and group members available to an end user within your application for something like re-assignment use cases then you should wrap these into a service in your backend, make the call as a user with the requisite permissions, filter results if necessary to elide sensitive groups and memberships - and then present to your end users.

Solusoft

We explored above option but to implement it we need to store tenant admin credentials to someplace in our backend application which is not recommended.
So we are trying to achieve above functionality by CMS groups, and we are testing this API with postman.

We could successfully create a group and assign the application users(subscription members) by its id to group. But when we retrieve this group members, their status is show as "INVITATION _PENDING".

We are doing following steps and its response is in below screenshot.

create CMS group with members

Group detail

Group member details:

In below response, the tenant_user_status is showing as "INVITATION_PENDING" but these added users did not receive any email or invitation in any form. These members of the groups are already created and are application users so which invitation is this and where it is sent?

Lawrence Yang

That looks like an issue with Admin Center. When you add a user to a Core Content subscription, it automatically that user to tenant users. Both tenant users and subscription users will show 'Invitation Pending' status in Admin Center. Once a user registered the account with Core Content, it should reset invitation pending status in both tenant users and subscription users list in Admin Center.

This is not something an API call can affect. I'd suggest you double check the user information in Admin Center.

CMS and Core Content rely on subscription groups and subscription users for ACLs. CMS has following endpoint to list subscription users:

/cms/subscription-users

Unfortunately, there is no corresponding /subscription-groups end point. As Roger pointed out above, /groups endpoint is only intended to be used with groups mapped to case roles. These groups don't show up in Core Content application UI as normal subscription groups. But if you only intend to use it programmatically, it is probably ok. Make sure you get the user id from the /subscription-users collection.

LazarescuA

I just wanted to point out that the cms/… endpoint refers to the cms service only. It will cascade the users/groups you create here but they might have different id's.

The endpoint you should be using to work programmatically with users/groups is the admin endpoint (organization/…/subscription/…). Those will be the actual users that can login to your application.

For your question above, there are a couple of solutions:

1. As Roger said, you can use a backend. Indeed, the backend needs credentials and you can use a keystore to encrypt credentials so that they are safely guarded.
2. External authentication: you can add another authenticator in OCP and your users will authenticate against that authenticator (Google IdP, Azure, AD, etc.) - then you can query that authenticator through its API's
3. Snapshot: if all your users/groups are going to be created within your application, also create an entry in the cms service (cms_object) for each group and its members. Then you can assign ACL's, can filter, etc. - so you can expose that information to your end-users. You can also have super users (admins) that could click a button and regenerate all the information in case something is out of sync. In this case, the app will use the admin's credentials and recreate all cms objects based on real users/groups in the system.