Replies posted by Malcolm Lea

3 Replies

M
Committed
Malcolm LeaCommitted

Improved support for SDK authentication of customers of customers.Gathering Interest

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!

6
BugGambit
Practitioner
1 month ago
M
Committed
Malcolm LeaCommitted

Support for OIDC client credentials in Power BI ConnectorGathering Interest

Thanks for the response. It’s food for thought: I didn’t realise about the OData approach to make a direct call instead of using the connector. However, I’m not seeing how we would avoid obtaining the tokens manually before making the OData call, unless PowerBI could also run this part (and store the client secrets and tokens somewhere secure?). If not, any token we used would i) be visible in the query code, and ii) expire after a short period and need to be recreated. We’re talking about published reports here which are typically refreshing datasets on a schedule i.e. with no end user present.It would be great to see authentication via client credentials as part of the PBI connector at some point - any plans to do this?

2
M
Committed
6 months ago
M
Committed
Malcolm LeaCommitted

Improved support for SDK authentication of customers of customers.Gathering Interest

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 configure

6
BugGambit
Practitioner
1 month ago

Badge winners

Show all badges
Terms & ConditionsCookie Settings