From Help Desk to ITIL Service Desk

In general, the IT help desk is staffed by individuals who receive emails or calls from users that require assistance. These requests propel the help desk staff into fire-fighting mode, as they work to resolve the user issues. A service desk ideally moves the inefficient and reactive help desk process, to a proactive, highly productive and efficient service, which becomes more cost-effective over time.

A service desk designed with ITIL initiatives uses a standard set of best practices for lowering costs and improving the quality of IT service delivery. The aim of a service desk is to act as the operational interface between the IT organization and its customers, for achieving an organization’s goals.

Whereas a Help Desk consists of a single, or very few processes, a Service Desk usually involves a number of processes that are highly integrated and work together seamlessly. This includes request, incident, problem, change and knowledge management. A Help Desk provides simple ticketing at the low end, through complete incident management at the high end, such as LiveTime Help Desk. This provides essential front line features for managing customer issues and providing communication and status updates. Many also provide limited workflows and basic service level agreements.

In contrast, a Service Desk is concerned not only with taking and responding to calls, but managing the entire lifecycle of the request as it evolves through other relevant processes. For instance, a call may originate as a simple incident which may then evolve into a problem which is also related to several other incidents. This problem may subsequently require a physical change in the environment to resolve, at which point it will trigger a change request. This change request will then need to be assessed and actioned and eventually get rolled into a release which requires testing and deployment. At each stage of it’s evolution any Team member has complete process visibility whereby they can see the underlying request hierarchy. Throughout the entire process information with the knowledge base is scanned, together with the properties and attributes of the Configuration Item (CI). This simple example demonstrates how different business units or groups can be involved in the process and how they can work together very easily, ultimately improving the efficiency of the entire process, rather than using a single isolated Incident Management process.

In addition, a service desk, or service management product will control each process within a service level agreement, which may also include Operation Level Agreements (OLA’s) and/or Underpinning Contracts (UPC’s). A Help Desk will normally provide simple timers and often call these service agreements.

So while the help desk provides basic features to assist an organization in providing customer service and support, the service desk tightly integrates many other processes such as incident, problem, change and release management (in addition to other core processes such as knowledge management) within the workflow. Together, these processes, when married to service contracts and knowledge management ensure customer requests are managed through the entire lifecycle within the business.

LiveTime Single Sign-on (SSO) and SAML

LiveTime recently announced SAML based single sign-on (SSO) for LiveTime 6.1. What does this mean for your business and how can this be easily leveraged in existing environments?

Single Sign-On technologies, typically implemented using SAML or SAML2 specifications, streamline the end-user experience by granting access to resources without forcing users to re-authenticate with each application. Such a setup consists of, an IdP (Identity Provider), which manages the login session and is the source of user information along with one or more SPs (Service Providers) which manage resource access. SP’s are present with protected resources and handle the heavy lifting of challenging users for authentication if required or otherwise validating SSO sessions and dealing with other security concerns of such a configuration. This information is then filtered down to the protected applications and/or resources which can leverage the provided data to grant access to resources, bypassing another application login cycle.

With the Single Sign-On components doing all the heavy lifting, Java web applications (Servlets) need only leverage the information communicated using HTTP session headers. Using HTTP Session headers is a standard extension of SSO technologies, which support various methods of passing user information to protected resources. These can be named at the users discretion and configured to contain any information a protected application may require (subject to privacy policies of the implementing organization). This technique of passing user information to applications is implemented in most SAML2 Single Sign-On implementations, both free implementations (eg. Shibboleth, JOSSO) and commercial (eg. CA SiteMinder, Oracle Identity Manager, Novell SecureLogin).

Configuration

LiveTime takes the complexity out of setting up single sign-on by providing direct access to the key attributes required fro each SSO provider.

Simply login as a Administrator and select SSO in the menu. First, enter the Session ID of your Identity Provider. These are unique headers passed inside the HTTP headers and uniquely identify each provider, such as shibsessionid for Shibboleth. Then provide the user name identifier (usually uid) followed by the users email, which is used to validate the username.

Now you can simply turn on Single Sign On and test the logins. If everything has been correctly setup at the Identity Provider level and it is correctly intercepting logins, LiveTime will seamlessly pass the user into the application and bypass the login screen entirely.

Since this process is handled at the header level within LiveTime nothing else is required. SSO controls within your provider are now responsible for controlling the security around application access.