Service Definition

eVisitor

Aims of Service

The eVisitor Service is intended to provide a simple to use and lightweight way for people to self-register with the University to get access to on-line services.

In order for this service to achieve the desired aim, there are a number of key principles that are adhered to:

·  The service is based on simple lightweight API’s which service providers can use to integrate eVisitor registration into their existing sites.

·  eVisitor registration integrates with existing EASE login methods (via cosign friend) to ensure all users of university systems continue to be presented with a single login method.

·  All Application Services using eVisitor must be registered in advance by the relevant Application Service providers.

·  Once a user has registered for one service though the eVisitor service they will never need to re-register to use another service registered with eVisitor.

Operational Framework

The service as a whole comprises of three main elements. There is the core eVisitor service, the underlying authentication service and then the end user application which will use the eVisitor service for registration and authentication.

eVisitor Service

The core eVisitor service comprises of the API’s supplied to Service Managers to use with their services, the central eVisitor Data store where details of eVisitor Identities and attributes are stored. Further to this a central Administration portal is provided, accessed through the MyEd portal.

Through the supplied API’s service providers are able to embed functions such as User Creation, updating user details and tools to lookup eVisitor accounts to check for existing records.

The eVisitor Data store is a central data store housing the registered data for all eVisitors. This allows not only the generating service but all others to check for existing eVisitor ID’s.

To provide security around these functions each Application Service that uses the functions will be required to register in advance. Unregistered Application Services will be denied access.

Authentication Service

The authentication system put in place for use with eVisitor is the EASE Friend service. This service allows for a single login point for all University Identity types, however eVisitor ID’s will have a login comprising of their email address and a password as opposed to a generated UUN.

Application Service

The final tier in this process is the application servie providers themselves. Although not directly a componenet of the eisitor service they are integral to the service being successful. The more applications that take up the lightweight registration system for use with online applications help to further establish the service as the single and simple solution. This helps to provide a unified interface to all University system users and reduce admin and support overheads.

Service Elements

·  Operational management of the eVisitor service is carried out by IS-Application service Management

·  Registration of new eVisitor accounts is carried out via self registration or by service providers using administration tools.

·  Support and guidance on the implementation of the API’s can be provided by IS-Applications

·  Reporting on eVisitor Stats will be available to associated service providers through the BOXI reporting service (for details on BOXI please see http://www.managed-services-index.ed.ac.uk/areas/itservices/busintel/BOXI/index.shtml )

Service Targets

Support is available, Monday to Friday, 9am to 5pm. excluding University Holidays

Except for planned service outages, the service is available 24 hours a day, 7 days a week.

Any planned outages will be scheduled, and notice given 2 weeks in advance via a service announcement issued by IS-Apps Production Management.

Charges

There are no charges associated with this service.

Service Contacts

Service Management Section (Delivery and Integration Team)
Current contacts details for Service Management are at: http://www.mis.ed.ac.uk/who/service_management/index.shtml

The team can be contacted directly via the University CMS System listed as IS-Apps Service Management or by emailing

For general support enquires on a running service, customers should first contact their local computing support officer. Where this is not possible queries can be submitted via the communications channels detailed above.

CMS calls to all IS-Apps teams are handled on a priority basis. The table below gives information on priority levels and the associated response times that we aim to achieve.

Priority / Description / Incident Response Time / Incident Updates / Problem Updates – by priority (Level 2 or 3 only)
Critical / For production business critical faults that affect the whole system and would cause risk to overall objectives and reputation. Generally this would mean the service was not functioning at all. / Within 1 working hours / Daily / Target to close top 5 priority calls monthly
High / For production faults that affect individual or isolated users circumstances rendering the system ineffective under these conditions / Within 4 working hours / Every 2 working days / Monthly review of priorities, but with weekly update.
Medium / For production or test faults that affect functionality that is not essential to ‘normal’ operations, or where a higher priority call has been provided with a temporary work around. / Within 48 hours / Every working week / Monthly review of priorities.
Low / For any work that is seen as ‘nice to have’ or can be managed without indefinitely. / n/a No commitment to fix – archived for review at system upgrade. / n/a / n/a

Feedback or Escalations

Feedback on the eVisitor service should be sent to