Hello @Choubey
It’s important to understand that the Kaltura platform supports multiple access control mechanisms (I’m referring to the application layer here; naturally, we apply ACL restrictions at the lower layers as well - networking [layer 3 in OSI terms] and transport [layer 4]).
The mechanism that is of interest in this scenario is called content entitlements. For a high level overview, please see:
https://developer.kaltura.com/api-docs/Secure_Control_and_Govern/Content-Categories-Management.html
https://developer.kaltura.com/api-docs/Secure_Control_and_Govern/Content-Entitlements-Privacy-Enforcement.html
The way to determine whether a certain API request should be allowed is by looking at the KS (Kaltura Session) parameter.
This is true to all API requests, made by Kaltura’s own applications (KMC, MediaSpace, etc) as well as third party/customer applications.
A KS consists of multiple fields, the most important ones being:
- Partner ID
- Expiration date (represented as a UNIX/Epoch timestamp)
- Type (USER or ADMIN)
- user ID
- Privileges
A detailed explanation of the KS structure can be found here:
https://developer.kaltura.com/api-docs/VPaaS-API-Getting-Started/Kaltura_API_Authentication_and_Security.html#ks-components
To better illustrate the above, please consider this output (the result of decoding the KS string):
hash 633c8563f79775bb648bc36983b602051094a7fb
real_str $PARTNER_ID;$PARTNER_ID;1564681348;2;1564594948.5176;jess.portnoy@kaltura.com;swiew:$ENTRY_ID;
partner_id $PARTNER_ID
partner_pattern $PARTNER_ID
valid_until 1564681348 = 2019-08-01 17:42:28 (will expire in 23 hours and 59 minutes)
type 2
rand 1564594948.5176
user jess
privileges disableentitlementforentry:$ENTRY_ID,setrole:PLAYBACK_BASE_ROLE,sview:$ENTRY_ID
In the example above, because the KS was generated with these privileges:
disableentitlementforentry:$ENTRY_ID,setrole:PLAYBACK_BASE_ROLE,sview:$ENTRY_ID
If you attempt to use it to view a different entry ID, it will also fail.
The privileges
field can be used to limit the actions that can be performed with the KS in question.
For the use-case at hand, we only want the KS to allow playback and therefore, the sview
privilege is sufficient.
By setting sview:$ENTRY_ID
in the privileges
field when generating the KS, one can limit playback to one specific entry, which is the desired behaviour here.
As is always the case, the principle of least privilege (PoLP) applies.
There are two main methods for generating a KS:
Both methods allow you to set a specific user ID and the desired privileges and select the session type (you’ll want a USER session in this case, not ADMIN).
Kaltura has official API clients for many different languages.
A full list can be found here: Native Client Libraries - Kaltura VPaaS API Documentation.
we also offer a mechanism called appToken, which you can read about here:
https://developer.kaltura.com/workflows/Generate_API_Sessions/App_Token_Authentication
The main advantage of using that method is that a given token can easily be revoked whereas, if the
admin secret needs to be changed, you will have to put the request to us.
So, in conclusion, you need to either:
- Generate a KS as per the above and include that in your embed code (see example below)
- Associate the entry IDs in question with categories for which no entitlement enforcement is enabled (this is the default when creating a category in KMC)
Here’s a sample embed code with the ks
param:
<script src="https://www.kaltura.com/p/partner_id/sp/PARTNER_ID00/embedIframeJs/uiconf_id/UICONF_ID/partner_id/PARTNER_ID"></script>
<div id="kaltura_player" style="width: 528px; height: 327px;"></div>
<script>
kWidget.embed({
"targetId": "kaltura_player",
"wid": "_"+PARTNER_ID,
"uiconf_id": UICONF_ID,
"flashvars":
{
"ks": ""
},
"cache_st": 1564598506,
"entry_id": "ENTRY_ID"
});
</script>