What's a shared user?
The concept of a 'shared user' in the context of Kaltura's applications is less about the individual being shared but rather how the application (for example, MediaSpace Video Portal) handles the user. When a shared user logs into one video portal instance and subsequently logs into another, the application checks for an existing profile (identified by their email and external ID). Shared users have the same user ID across different video portals, and have the same My Media across all instances they access.
On the other hand, non-shared users (single-application users) get a new user ID every time they log into a new instance, which can result in one user potentially having multiple user IDs.
How do I enable shared users?
Any user that authenticates through Authbroker gets an external ID and automatically becomes a shared user. If Authbroker isn't set up, shared user settings can be configured in the Application module, specifically the userProfile field.
A value of 1 in the userProfile field indicates that this video portal application will treat all users as shared users, while a value of 0 means they are treated as single-application users.
It's important to note that a single video portal instance can be configured for either shared or single-application users, not both. Once set, this configuration cannot be changed midway (unless you delete all users and start afresh).
What are the advantages of a shared user?
When a shared user logs into different instances or events on the same partner, the following items will follow them:
- My Media: Content uploaded on one site will be accessible across all sites.
- Watch Later: Content added to the 'watch later' list in instance A will appear in instance B, provided the media is available in both instances.
- Auto Login: Users can navigate and auto-login to other sites using the same account. However, if registration is required, they must still register for the other instance.
- Analytics: Admins can view a single user's analytics across all sites.
Where is the user information saved?
The shared user's information is split into two types:
- Basic user information - This information (name, email, title, company, etc.) is stored once per user. Passwords are also part of basic user information but are kept in a different location. If a user tries to set a new password, it's overridden by the old one, ensuring consistency across events. Note, if a returning user has previously logged in without a password (using a magic link, for example), they might need to set one for events that require password authentication.
- Additional registration fields - This information is event-specific and may vary from event to event.
The information for each user can be seen in the User Management page of the Configuration Management console, as shown below:
While the basic user information will show exactly the same on all sites, the additional registration fields will differ, and might even be empty in some sites.
|
Type of data |
Located on which DB? |
Example info |
Reasoning |
Where can be updated from |
Per site |
|---|---|---|---|---|---|
|
Basic user information |
user object |
name, company, country, zip |
These are things that usually don’t change for a person |
Edit profile Edit registration |
Same on all sites |
|
Site specific |
user profile |
Firm, preferences, approve privacy policy |
This is a type of custom data on users - each partner/event can have a different set of data for the users |
Edit registration |
Different for each site |
Understanding user IDs
A video portal instance may have different user types with different IDs, as shown below:
KMC users do not appear in the User Management table.
'Other' refers to users authenticated via SAML, and legacy user IDs created without advanced kauth. It does not include advanced authentication users.
Here's how the IDs differ:
- Single-application user ID: Partner ID + instance ID + email
- Shared user ID: Partner ID + email
In Kaltura's back-end, shared users also have a unique external ID that will help Kaltura administrators identify that user as being a shared user. The externalId field (shown in the image below) will be empty if the user is NOT a shared user.
What is a returning user?
A 'returning user' is a shared user who has joined previous events and returns for another event. When registering for the new event, if the application is set up for shared users, it checks for an existing user (identified by their email and external ID). If found, the existing shared user will be registered to the new site, saving the new site-specific fields if any, and keeping the basic user info unchanged.
You can track analytics on shared and returning users. This includes monitoring their activities, interactions, and metadata across different events, allowing for detailed analysis on a per-event and per-user basis.
FAQs
Can some video portals be set for shared users and other video portals be set for single-application users under the same Partner ID?
Yes, when a user accesses the video portal, each video portal will handle each user according to how it has been set.
If a shared user registers to a new event set up for single-application too, will the user get the registration emails?
Yes, everyone will receive emails. Returning users might get a special email recognizing their status and letting them know their previous personal info is used. If no specific email is set up for returning users, they'll get the standard one, same as regular users. You can customize an email template specifically for returning users in the siteregistration module.
You can also customize an invitation email specially for returning users in the inviteUsers module
What happens when I delete a shared user from the system?
Deleting a shared user from the system can only be done using the API. When deleted, the user's information and access rights across all events and video portal applications will be removed, and the user will no longer be able to log in or access any content or events associated with their account. Deleting a user from the video portal management console only removes the user from the instance, but the user still exists on the database.
What happens if I block a shared user on one event, are they blocked on all events?
Yes, if you block a shared user on one event, they'll be blocked from logging into all events. You can consider using "remove from site" as an alternative to blocking.
Are shared users relevant for SSO only use cases?
Since SSO users are identified by their Identity Provider ID, SSO users are always considered Shared users, as long as the ID passed from the authentication provider is the same.
Are shared users based on email only?
Yes.
Why would we even have a video portal set up for single-application users?
This may be necessary for events that are entirely external and cater to individuals who are not part of the regular user base. This ensures a separate user base specifically tailored for that event, or for less secure environments where you don't want information to flow between different events. Non-shared video portal instances create separate user profiles for each event, ensuring data privacy and security.
Can I use shared users for some events and single-application users for others if I don't want to share users between applications / events?
Please contact your Kaltura Representative.
How can I begin using the shared users system?
To transition from current authentication methods to the new shared user system, please reach out to your Kaltura representative for assistance.
