Skip to main content

Restricted data sharing: what are your governance needs?

  • October 23, 2026
  • 1 reply
  • 5 views
  • Translate All

josephinerohner
Community Manager
Forum|alt.badge.img+2

Hi everyone,

More and more of you use your Huwise portal to share data with a selected audience: partners, subsidiaries, logged-in staff, contractors. ​@Lauralee reviewed what the platform lets you do today to manage these accesses in detail, with real (anonymized) examples from your portals. 🔒

1. Identify who logs in

  • SSO (OpenID Connect or SAML 2.0): your users log in with their company account. No accounts to create by hand, and removing someone from the directory removes their access.
  • Several SSO providers on one portal: one group brought 7 of its entities together around a shared catalog, each with its own identity provider.
  • Group mapping: your directory stays the source of truth. An international organization receives a staff category through SSO, and each user automatically joins the right group with the right permissions.
  • Conditional access rules: based on a user’s attributes (company ID, email domain…), the portal approves the sign-up, rejects it, or sends it for manual review.

2. Manage users and their rights

  • Permissions granted automatically when an account is created.
  • Temporary access, revoked automatically on a set date (contractors, interns, audits).
  • Account deactivation, for example when terms of use are not respected.
  • API call quotas per user, per group, or for the whole portal.

3. Control access to datasets

  • Public or private portal, mandatory sign-up or not: an electricity network operator shows metadata to everyone and keeps the data for registered users.
  • Security tab: each user or group sees only some columns or some rows of a dataset. An energy distributor shows each municipality only the data for its own area.
  • Access requests: the dataset stays private and appears in the catalog. Interested users request access, and the data producer approves it. A data monetization provider uses this for its offer.
  • Catalog visibility: hide a technical or test dataset, or make all new datasets private by default.

4. Organize several workspaces

  • Private federation: an internal portal feeds the open data portal of the same group, private datasets included.
  • Filtered distribution: a main workspace sends a dataset to each secondary workspace, filtered on its geographic scope.

Finally, traceability: usage statistics, group membership, API keys and the activity log show who accesses what.

For the details of each setting, check the User Guide:

(Some features, such as SSO, depend on your plan.)

Over to you

What about you: who do you share restricted data with, how have you set it up, what is missing ? Share your vision in the comments section 👇

1 reply

Forum|alt.badge.img+2
  • Guardian
  • October 23, 2026

Personally, for us it would be a great help if there could be some integrated “actions” between the forms and dataset security. 

We use forms for requesting access to a handful of different datasets, it would make the admin much easier if one “approve” was clicked, that user was automatically granted certain permissions to datasets or groups.

Also if would be very useful if users were sent emails notifying their form request was either rejected or accepted - I dont believe this happens currently?

Thanks

Ryan

Translate