The Web Player Custom Authentication framework enables the development of a different authentication mechanism than the ones available out-of-the-box.
Overview
For Custom Authentication to work, the third party authentication
system must provide a mechanism to deduce the authenticated
user’s login name. This can be achieved in various ways. The
authentication system may extend the user session with a domain
cookie or a ticket identifying the user may be appended to the
Web Player URL as an HTTP request parameter. Another alternative
is to retrieve the user name from a custom built HTTP authentication
module.
Background Information
- Refer to the Web Player manual for more information
about impersonation.
Tutorials
-
How to Test the Custom Authentication SDK Example
This tutorial first explains how to build a custom authentication site, then how to build a custom authentication module, and finally how to test the resulting custom web player authentication.
-
How to Implement Custom Authentication
Web Player custom authentication is implemented in two steps. First the custom authenticator is created, then it is enabled in the Web Player configuration.
How Custom Authentication Works
The extension point of the Custom Authentication framework is
an extendable base class. It enables a third party to integrate
with the Web Player Server in an already existing Single Sign
On environment.
A custom implementations of the base class provides the core
authentication framework with information regarding the identity
of an authenticated user accessing the Web Player. The Web Player
uses this information to perform an impersonation operation,
giving the user access to the Analytics Server under the assumption
that he or she is an authorized user.
Implementing custom authentication includes to define how the
user identity is determined. This information is typically extracted
from the web request.
In the scenario to the right (click to magnify), authentication
is handled by a portal server which uses a common Sign-On service:
Upon successful authentication, the Sing-On service sets a domain
cookie containing a user ticket (2), which is made available
to the custom authentication mechanism on the Web Player (4).
This ticket is then translated to the corresponding user login
name by the Sign-On service (5 and 6).
Finally the user login name is used in the impersonation step
when communicating with the Analytics Server (7).