The Kaltura API is REST based and stateless. Every call (request) made to the Kaltura API requires an authentication key, the Kaltura Session (aka KS), identifying the account on which the action to be carried, the authenticated user and its role.
A Kaltura Session can be initiated in 3 different ways:
- Calling the session.start action, providing the account Partner ID and an Admin or User secret key.
$ks = $client->session->start ($adminSecret, $anyUserName, KalturaSessionType::ADMIN, $partnerId); $client->setKS($ks);
- Calling the user.loginByLoginId action, providing a User login ID (email), its Password and the account Partner ID.
$ks = $client->user->loginByLoginId($loginId, $password, $partnerId); $client->setKS($ks);
- Creating a session locally - Combine all the Kaltura Session details, and sign them using the shared secret.
$ks = $client->generateSession($adminSecret, $userId, $type, $partnerId); $client->setKS($ks);
The above examples are using the Kaltura PHP5 Client Library.
Important Security Notes:
- ADMIN type KS provides super admin priveliges to the Kaltura account. If you're creating an application where the session will be exposed to the end-user, make sure that you are using a USER type KS and not ADMIN type. Exposing an ADMIN type KS in non-administrative context will expose your Kaltura account to risks of being used by malicious users with unrestricted access.
- Sharing the account API secret keys with 3rd party vendors should be avoided, as secret keys can not be regenerated or blocked for access. Kaltura API based application developers and 3rd party application vendors should build their application to leverage the user.loginByLoginId API and ask the publisher for their email, password and account Id (aka partnerId). Users can be easily created, removed or blocked and their password can easily be changed.