The Kaltura API is representational state transfer (REST)(http://en.wikipedia.org/wiki/Representational_state_transfer), which is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged over the past few years as a predominant Web service design model. REST has increasingly displaced other design models such as SOAP and WSDL due to its simpler style and statelessness. 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.
Methods for Generating a Kaltura Session
There are three methods for generating a Kaltura Session:
- Calling the session.start action: This method is recommended for scripts and applications to which you alone will have access.
- Calling the user.loginByLoginId action: This method is recommended for managing registered users in Kaltura, and allowing users to log in using email and password. When you log in to the KMC, the KMC application calls the user.loginByLoginId action to authenticate you using your registered email and password.
- Using the appToken service: This method is recommended when providing access to scripts or applications that are managed by others; this method provides tools to manage API tokens per application provider, revoke access to specific applications, and more.
The examples above use the Kaltura PHP5 Client Library.
To learn more about the Kaltura Session, its algorithm, guidelines and options read the Kaltura API Authentication and Security article.
Important Security Notes
- The ADMIN type KS provides super admin privileges 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.</strong>
- 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.