Configuring your portal's general security policy¶
Public or private?¶
The most important choice is whether your portal should be public or private. That is whether you want anonymous users to be able to access the portal or if you'll require people to signup before they can access anything.
Important
Making your portal public doesn't mean that anybody will have access to all of the datasets! You'll always be able to limit what the general public can see through the use of sensible default security parameters for your datasets and explicit parameters on each single dataset.
See the dedicated section for more information about dataset security.
This setting can be found in the security subsection of the configuration section of your portal's back office.
Note that if you decide not to allow anonymous users to access your portal, they will be redirected to the login page unless you'd rather they land on a specific page you've written.

Signup policy¶
No matter your choice of public or private, you can then decide on who will be able to become a registered member of your portal. In order to do this, go to the Configuration/Signup subsection of your portal's back office.

Closed signup policy¶
If you decide not to allow people to signup freely, the only way of adding members to your portal will be through direct email invitations.
Open signup policy¶
If you allow people to register, you'll then have to decide whether you want to approve each access request to your portal manually or not. Note that whatever your decision, each member of the portal able to manage users will receive a notification for each new access request.

Do not forget to add the signup button to your header's menu, or people won't see a signup form until they try to access a restricted area of your portal.

The signup process is usually very straightforward: an email, a password, and that's it. You can decide to customize the experience by setting up a custom text as a disclaimer, request users to accept your terms and conditions, and even require that they leave a message for the portal's administrator (useful when you want to manually approve access requests).

User session timeout¶
By default, all authenticated users are automatically logged out after a 2-week inactivity period. This duration can be changed in the Configuration/Security section of the back office.
Note that every user request to the portal resets the timeout, so sessions can actually last longer than the timeout duration.
Single sign-on¶
If your organization already has its own identity management system, you can set up a bridge between your identity provider and your Opendatasoft portal. This will give general access to your portal to each of your organization's members.
Opendatasoft supports two types of identity providers:
About local users and linked users¶
When a SAML or an OpenID Connect identity provider is configured on a domain, a user can belong to 3 categories.
A standard Opendatasoft user that was invited by email or signed-up on a domain: this user logs in on the domain using the standard sign-in interface with their usual Opendatasoft username and password and the account is accessible on the whole Opendatasoft network. Opendatasoft users are represented throughout the platform with the
pictogram.
A local user that authenticates through the organization's identity provider: this user logs in on the domain exclusively via the organization's identity provider, and as it is only available on a specific domain, it can be limited in the use of features relying on the Opendatasoft network. Local users are represented throughout the platform with the
pictogram.
A linked user that has a standard Opendatasoft account but is associated on this specific domain with an identity from the organization's identity provider. This user is a standard Opendatasoft user that can both authenticate through the Opendatasoft sign-in interface and the organization's identity provider. Since linked users are Opendatasoft users with
SAML
orOpenID Connect
authentication abilities, they are represented throughout the platform with both theand the
pictograms.
Local user
Every user that has a user account on the identity provider trusted by a domain and doesn't have an Opendatasoft user account can connect through. During the first connection, a local user will be created for the user based on the domain's identity provider settings.
These local users have the permission to explore the public datasets of the domain by default. Extra permissions can be given to these users at the domain level, on individual datasets, or via groups (other than the SAML users
or OpenID Connect users
groups, of which they are automatically members).
The creation of new local users via an identity provider authentication can be disabled using the "Disable local user provisioning" checkbox in the identity provider configuration (SAML or OpenID Connect) configuration. Disabling local user provisioning will not prevent existing local users from signing in.
Linked user
Users that have an Opendatasoft user account can link this account to another account at the identity provider. This procedure is called account linking.
After the link has been established, linked users who log in through their identity provider will be logged in to their Opendatasoft user account. They'll still be able to log in with their Opendatasoft password, though.
There are 2 methods for linking an Opendatasoft user account:
The first one is to click on
Link your account to a SAML account on this domain
orLink your account to an OpenID connect account on this domain
in the identity tab of the user account settings:

The other method is to create the link during the user account creation process by clicking the link to complete the registration through SAML. This actually speeds up the user account creation process and allows for a quick account linking:

Note
Linking during sign-in is only supported with SAML identity providers.
Default login page selection¶
The Opendatasoft platform allows to choose the login page that will be displayed to users when they click on a login link or try to access a restricted page.
If the identity provider login page is selected as default, the authentication flow (SAML or OpenID Connect) will be initiated automatically if an anonymous user clicks on the login link or try to access a restricted page like the back office. When the identity provider login page is selected, users who wish to connect to the platform using their Opendatasoft credentials have the option to do so by manually visiting the domain login page at https://<platform-url>/login/
.

Using user attributes to filter data¶
Users who have been logged in through identity federation (SAML 2.0 or OpenID Connect) may have been set specific profile attributes. These attributes can be used to filter the content of the datasets these users can access.
To do so, you can edit the security configuration of a specific dataset and use the #attr function in the filter query of the SAML or OpenID Connect security group attached to the dataset. This way, users belonging to these groups will only see dataset records that match the filtering query, as explained below.
Through the #attr function, it is possible to filter dataset records in such a way that the only records returned are the ones that match
a value set in the user attributes sent by the identity provider. For the following examples, we assume that we have the 3 users, with respective
usernames and SAML attributes user-country
and user-language
:
User | user-country |
user-language |
---|---|---|
User1 | France | French |
User2 | Canada | French |
User3 | United States | English |
And a dataset with the following records:
country |
language |
message |
---|---|---|
Worldwide | English | Hello world |
France | French | Bonjour à tous les Français |
Canada | French | Bonjour à tous les Canadiens |
Canada | English | Hello to all Canadians |
United States | English | Hello to all Americans |
We can restrict these users so that they see only messages that apply to their respective countries, with the query #attr(country, user-country)
.
User1 sees
country |
language |
message |
---|---|---|
France | French | Bonjour à tous les Français |
User2 sees
country |
language |
message |
---|---|---|
Canada | French | Bonjour à tous les Canadiens |
Canada | English | Hello to all Canadians |
User3 sees
country |
language |
message |
---|---|---|
United States | English | Hello to all Americans |
We can also restrict these users so that they only see messages that are in their respective language, with the query #attr(language, user-language)
.
User1 sees
country |
language |
message |
---|---|---|
France | French | Bonjour à tous les Français |
Canada | French | Bonjour à tous les Canadiens |
User2 sees
country |
language |
message |
---|---|---|
France | French | Bonjour à tous les Français |
Canada | French | Bonjour à tous les Canadiens |
User3 sees
country |
language |
message |
---|---|---|
Worldwide | English | Hello world |
United States | English | Hello to all Americans |
Since it is a function of the query language, it can also be grouped with the usual operators. For example, we can restrict users to only seeing messages that fit their country and languages with the query #attr(language, user-language) AND #attr(country, user-country)
.
User1 sees
country |
language |
message |
---|---|---|
France | French | Bonjour à tous les Français |
User2 sees
country |
language |
message |
---|---|---|
Canada | French | Bonjour à tous les Canadiens |
User3 sees
country |
language |
message |
---|---|---|
United States | English | Hello to all Americans |