Improved support for SDK authentication of customers of customers.

Hi @Malcolm Lea,

 I can see that this is not optimal for your case. There are some options I can think about:

1. Give the customer limited access to your IdP (Azure?) to issue service accounts. They could then create and manage credentials on their own without involving you.
2. Use a auth federation service like Auth0, where you can connect your IdP with the customers' IdPs and connect the federation service to the CDF project. Service accounts could be issued in Auth0 by the customers, but they don’t get access to your IdP, but you can still sign in using your IdP.

What could the first-class support in the Cognite SDK look like?

Hi @BugGamit, thanks for sharing your thoughts and apologies for a slow response.

We would like to avoid service accounts when working with external parties, i.e. customers, as this makes us reliant on them to keep the secret for the application safe. This would be a concern with either of the above suggestions. That said, the Auth0 suggestion would keep the customers out of our own IdP - which is closer to the direction we want to go in.

Whilst trying to be solution-agnostic in the original post, we are a really thinking of a solution that allows us to guarantee the end-user is from the customer's IdP. This could perhaps entail either (or even a combination of):

• explicit support for multiple IdPs in CDF, allowing us to assign not just an IdP's group id to a CDF group, but also state which IdP issuer the user must have come from.

• token exchange support in the SDK so that, when given an end-user's token for the application they are using, the SDK would negotiate with the IdP configured in CDF and obtain a token to call the API with. https://www.rfc-editor.org/rfc/rfc8693.html . Currently, most implementations of this flow seem to have some limitations (e.g. AAD has a couple of non-standard approaches, various others do not support token exchange across IdPs, etc), but they may catch up soon.

Would be keen to hear your thoughts.

Hi again @Malcolm Lea,

I have some exciting news. We have rolled out our authorization server to most customers. All customers, including PGS, will be onboarded in a few weeks. The majority of our customers are already onboarded.

What does this entail?

1. We introduced a new concept called Organizations. Organizations live above CDF projects. They live in a hierarchy (tree), and an organization higher up in the tree can manage organizations below it.
2. Cognite applications now perform OAuth flows against our new authorization server for interactive logins (available for our migrated customers). The authorization server federates with the customer's identity provider (IdP) (nothing has changed in this regard), streamlining OAuth flows for all clients as there is a single entry point. As a developer, you will no longer need point-to-point integration with the customer's IdP.
3. Every user will have a user profile (name, email, picture) and a unique ID.

The next on our roadmap is to introduce native support for service accounts in CDF. You can then create service accounts in an organization and retrieve client credentials for the service account. We will implement native support in our SDKs to use these credentials.

PGS can then combine the organization hierarchy with service accounts in CDF. You can have a top-level organization for PGS with some sub-organizations, one per customer. Customers can create service accounts within their CDF organization and only access projects tied to this organization (or potentially sub-organizations).

Would something like this solve your problem?

From the text, it's unclear if you want a service account or if you only have a simpler way of authenticating (interactive login). We will improve our Javascript SDK to add support for interactive login now that we have our own authorization server.

With the organization hierarchy, a sub-organization can be configured to use another IdP than the parent organization. This way, you could point the sub-organization to the customer's IdP. Then the customer could use their own IdP to control who has access to the projects.

Hi @BugGambit this is indeed interesting, thanks for the information.

I have a couple of initial questions:

How would the organisations relate to the existing concepts of groups and scoped access? For example, would I be able to say that users (or service accounts) from a customer organisation should have access to a given partition or dataset within a project, but not the others, whilst at the same time letting people from our own organisation have broader access to all the customers’ partitions?

I presume there will still be some kind of mapping still between groups in the external IdPs and in CDF: how would this mapping be managed and where?
 

Look forward to seeing the new functionality!

@Malcolm Lea 

Great to see!

It doesn’t make sense anymore to link CDF groups to groups in the external IdP when we introduce service accounts natively as the external IdP doesn’t have a notion of the CDF service accounts. However, we will add support for you to add these service accounts directly to a CDF group. See the screenshot of a feature we will release very soon which now only supports user accounts (either a specific list of users or “all” users). This doesn’t include service accounts yet, but you get an idea of how it will behave.

These groups will not be linked to an external IdP but rather be fully managed within CDF.

These groups will behave the same as CDF groups today in regard to access, the only thing different is the membership (not requiring source ID anymore). The current CDF groups (externally managed membership) will continue to work as normal.

Will you require access to the data in these sub-organizations? We will support a parent organization managing sub-organizations (change IdP settings, create sub-organizations, create sub-projects). This currenlty doesn’t include industrial data.