User:Paul.seiler/Temp/Identity and Access Policy and Procedures FINAL.odt

[[Image:]]Policy and Procedures -

Memorandum of

Agreement

Identity and Access Management for the 'Wellington Loop'

October 2009== Table of Contents == 1.Introduction3

1.1 Purpose of this document3

1.2 Scope3

1.3 Audience3

1.4 Overview3

1.5 Terminology4

2.Responsibilities6

2.1.All Participants6

2.2.Wellington Loop7

2.3.Identity Provider Service8

2.4.Organisations9

3.Security10

3.1.Data11

3.2.Software11

3.3.Physical Environment11

3.4.Disaster Recovery 11

4.Legislative Compliance12

5.Audit and Compliance12

5.1. Audits and Reviews 12

5.2. Monitoring and Logging12

5.3. Incident Notification and Response12

5.4. Policy Breaches 13

6.Termination13

7.Changes of Rules13

8.Dispute Resolution13

9.Limitation of Liability14

10.General14

11.Appendices15

11.1.Appendix 1 - References 15

11.2.Appendix 2 - Glossary of Terms, Definitions, Acronyms, and Abbreviations 16Document Version

Modified By	Date	Version	Reviewer / Distribution	Notes
Catalyst IT Contact: David Mullindavidm@catalyst.net.nz	2009-11-02	Final	MinEd LMS Project Team Loop participants	As template for distribution Highlighted clauses donate items to be reviewed by final owners of document.

Introduction

Purpose of this document

This document is a policy framework for the implementation and operation of the Identity and Access Management (IAM) pilot programme within the Wellington Loop. It is envisioned that the document will form the basis of a standard template that is utilised by schools, groups of schools and the Ministry of Education.

Scope

This agreement is intended to cover the rules and guidelines for the implementation, administration and continued secure use of the technology relating to identity and access management within the Wellington Loop.

Audience

• Wellington Loop IAM Pilot Steering Group
• Wellington Loop IT staff and Administration
• Participants in the Wellington Loop
• MLE project vendors
• Ministry of Education MLE Project Team

Overview

The purpose of the IAM pilot programme is to implement a solution for a Single Sign On (SSO) to the Wellington Loop network which allows the sharing of user credentials and other basic attributes with multiple on-line services. This shared access also allows these on-line services to manage appropriate levels of access to the application functions.

This agreement attempts to provide clear guidelines to aid this implementation. It covers rules on the administration, responsibilities and policies to ensure that the users, network and services are operating in an efficient, secure and safe environment. The critical aspect for the guidelines is to establish the rules of trust that will be applied in the Federation cluster of the Wellington Loop.

Terminology

Access Control	# Access Control is the process and rules that encompass both the authentication of a user identity and authorisation of rights to use services and resources available from the service providers and applications on the network.
Attribute	Meta-data describing the end user and/or services provided under the Wellington Loop framework. Attributes are used by Service Providers for service provision, authentication and authorisation.
Attribute Release	The release of Attributes for transfer from an Identity Provider to a Service Provider
Authentication	The process of establishing the digital identity of one entity to another entity. Commonly one entity is a client (an End User, a client computer, etc.) and the other entity is a server (computer). Authentication is accomplished via the presentation of an identity and its corresponding credentials.
Authentication Service	Any activity where an Identity Provider performs the role of End User Authentication and, where relevant, releases the Attributes for its End Users.
Authorisation	The granting of specific types of privileges (including "no privilege") to an entity or an End User, based on their authentication, what privileges they are requesting, the current system state and authorisation rights previously granted by Service Provider the to the End User. Authorisation may be based on restrictions, for example time-of-day restrictions, or physical location restrictions, or restrictions against multiple logins by the same user.
Authorisation Service	Any activity where a Service Provider grants access to End Users to services or resources made available by that Service Provider.
Confederation	A confederation is a network of circles of trust or Federations which is established to recognise and share Attribute Releases from other Federations.
Data	Digital objects including Attributes, Meta-data and Logging information.
End User	Any natural person who is a user of resources or services made available under the Wellington Loop.
Federation	A Federation instance is the circle of trust (COT) that is established when a group of services devolve part or all of its authentication, and access control function to a common Identity Provider (IdP).
Good Practice	Good practice as generally accepted within the IT industry and determined by the Wellington Loop Steering Group as required standard covering practices for identity management, authentication and authorisation of users of on-line resources and services.
Identity	An identity is a user's system name, user full name, student identity number, electronic certificate or similar which directly identifies a person. After the identity of a person has been authenticated and verified as true, the other attributes of the person can be derived from the appropriate authoritative source.
Identity Provider	Any organisation or institution which has been registered by the Federation and has a legal relationship with an End User to provide an authentication service for that End User. It may also refer to a service that manages access attributes that are released between the Service Providers.
Member	A research or education organisation or institution which is registered and participating in the Wellington Loop.
Meta-data	Structured facts that describe information, or information services as defined by the Wellington Loop.
Participant	Any Member or Affiliate which has been registered and is participating in the Wellington Loop.
Participating Organisation	Usually referred to the educational institutes such as schools, universities and research centres.
Service Provider	Any organisation or institution that provides access to End Users to services and resources based on a set of Attributes that satisfy their particular authorisation requirements.
System	Hardware, software and any other IT asset which when combined are used to process Data.
User Directory	The technology used to manage and verify the credentials of an user such as user details, access rights, roles and group memberships.

Responsibilities

All Participants

2.1.1.Terms of Agreement

2.1.1.1.Participation in the Wellington Loop is conditional upon the Participant accepting and abiding by these Rules and acknowledging that these Rules are binding upon and enforceable against the Participant by the Wellington Loop.

2.1.1.2.The Participant warrants and undertakes that:

a) all Data, when provided to the Wellington Loop or another Participant, are accurate and up-to-date and any changes to Meta-data are provided promptly to the Wellington Loop Operator;

b) it will observe Good Practice in relation to the configuration, operation and security of the System;

c) it will observe Good Practice in relation to the exchange and processing of any Data used by the System;

d) it holds and will continue to hold all necessary licences, authorisations and permissions required to meet its obligations under these Rules;

e) it will not act in any manner which damages or otherwise adversely affect the reputation of the Wellington Loop; and

f) it will give reasonable assistance to any other Participant (including to the Participant's identity provider) investigating misuse by an End User.

2.1.1.3.Participants acknowledge that participation in the Wellington Loop does not itself grant them or any of their End Users automatic access to the resources and services of Service Providers, and that such access may be conditional upon each Participant or End User agreeing appropriate terms with the relevant Service Provider governing that access. The Wellington Loop will not be responsible for, nor have any liability in respect of, the performance or otherwise of those terms and will not be required to resolve any disputes in relation to those terms.

2.1.1.4.The Participant grants the Wellington Loop the right to:

a) publish the Participant’s name for the purpose of promoting the Wellington Loop Federation; and

b) publish and otherwise use and hold the Participant’s Meta-data for the purpose of administering the operation of the Wellington Loop.

2.1.2.Acceptable Use Policy

1. 1. 1. 1. All End Users of the ICT Services provided on the Wellington Loop must be required to agree and sign an 'Acceptable Use Policy Agreement' as implemented and drafted by the Participating Organisation.
         2. The Acceptable Use Policy must include statements covering the following conditions:

a) all use of telecommunication and computer resources is required to be of an ethical manner;

b) personal and commercial use other than those purposes approved to support the objectives of the Wellington Loop is not permitted;

c) all material of an offensive and illegal manner is strictly prohibited from being imported, stored, viewed or distributed via the Wellington Loop's ICT resources;

d) all use and processes of the ICT resources must not be in conflict with the laws of New Zealand; and

e) all resources stored within the Wellington Loop's ICT systems remain the property of the designated party, unless otherwise noted.

Wellington Loop

2.2.1.Support

The Wellington Loop will provide the contact details for the support services, including a Help Desk for the network and IdP services.

2.2.2.Governance and Review

1. 1. 1. 1. These Rules have been drafted by the Wellington Loop IAM working group in collaboration with a representative group of Participants for the purpose of providing a framework of understanding, and to direct standards and processes for all Participants.
         2. The Wellington Loop Board will remain the final arbiter of these Rules, and the interpretation thereof.
         3. This memorandum of agreement will be reviewed and updated by the Wellington Loop Board on a regular basis as part of good ongoing governance, to maintain currency and appropriateness.

2.2.3.Audit and Compliance

1. 1. 1. The Wellington Loop Board will use audits as necessary to verify that that correct plans and processes are being implemented by Participants of the Wellington Loop.

2.2.4.Maintenance

1. 1. 1. 1. In the instance when maintenance of network, software or database is required the following guidelines are to be applied:

a) notification for any network or service outage that is planned must be made to all Participants, at least a week prior to the event;

b) notification must include date, time, reason and duration;

c) all urgent maintenance that has to be performed immediately to ensure continued use of the network, which otherwise would disable the network, must be performed as soon as possible;

1. 1. 1. d) all outages must be reported to the Wellington Loop Board; and
         e) where possible, the timing of the outage must not be during school hours, or around an exam period. Appropriate times for an outage are either in the late evenings, weekends, public holidays, or school holidays.

Identity Provider Service

This section details the rules and responsibilities of the Federation's Common Identity Provider Service that is utilised to manage the communication and verification processes between the organisations, End Users and all other Service Providers.

The organisations who provide user authorisation via their user directories are sometimes refered to as Identity Providers. The rules and responsibilities for these organisations are covered in section 9 Organisations.

2.3.1.Attribute Release & Management

1. 1. 1. 2.3.1.1.It is the aspirational objective that the End User credentials communicated by the IdP must comply with the Attributes Release Meta-data schema approved by the Wellington Loop as defined in the 'MLE Interoperability Development Project – SMS Identity Data Exchange Schema – Edtech, September 2009' specifications document. A simplified specification is provided by the Wellington Loop for the interim implementation.
         2.3.1.2.The processes and management rules for the technical implementation of the Attribute Release as managed by the Wellington Loop's Common IdP Service must comply with the specifications defined in the 'Technical Review and Solution Design – Identity and Access Management for the Wellington Loop – Catalyst, October 2009' document.

2.3.2.Single Sign On – Access and Trust Policy

1. 1. 1. 2.3.2.1.The Trust Relationship in the Wellington Loop is based on the devolution of the authentication responsibility to the Participating Organisations. The Authentication of the End User is performed at the individual organisations' user directories. Once an End User is authenticated as a valid user, the Attribute Release containing the user credentials is trusted throughout the Federation.
         2.3.2.2.The Wellington Loop's Common IdP is responsible for the Single Sign On (SSO) service which manages authentication and authorisation queries that is communicated with the Participating Organisation's user directory.
         2.3.2.3.The SSO Service will also manage the 'Where Are You From' (WAYF) protocol to identify the Participating Organisation that the End User is to be Authenticated from.
         2.3.2.4.Multi user sessions are permitted on the Loop network. Limitations to the number of sessions in each service will be managed by the service providers themselves.
         2.3.2.5.Each Access Release token has an expiry time of 24 hours after creation or on termination of the End User session, whichever comes first.
         2.3.2.6.A separate unique user access name will be issued at the Participating Organisation concerned if the End User has a different concurrent role. Also, if the End User is attached to a different Participating Organisation concurrently, a separate unique user access name at that Participating Organisation will be issued to the End User. This will cover the scenario of staff who work at different Participating Organisations at the same time.

2.3.3.Encryption

All communication is carried out over HTTPS/SSL/TLS.

Organisations

2.4.1.Authentication - Authoritative Source

1. 1. 1. 2.4.1.1.The authoritative source for End User credentials will be the individual Participating Organisations' User Directory Systems. The Participating Organisations will provide the Authentication Service of the End Users that originate from their organisation for the Wellington Loop.
         2.4.1.2.The Participating Organisation who will be performing the task of authenticating users, must collect or generate the core Attributes as defined by the Wellington Loop Federation.
         2.4.1.3.It is the aspirational objective that the End User credentials communicated by the Participating Organisation must comply with the Attributes Release Meta-data schema approved by the Wellington Loop as defined in the 'MLE Interoperability Development Project – SMS Identity Data Exchange Schema – Edtech, September 2009' specifications document. A simplified specification is provided by the Wellington Loop for the interim implementation.
         2.4.1.4.End User credentials and attributes must be promptly kept current and accurate.
         2.4.1.5.The Participating Organisation must ensure that sufficient logging information is retained for the period specified by the Wellington Loop to be able to associate a particular End User with a given session that it has authenticated.

2.4.2.Identity Authentication

1. 1. 1. 2.4.2.1.The End User accounts must be unique for the organisation.
         2.4.2.2.Credentials of End Users who are no longer permitted access and privileges to ICT services through the organisation must be revoked promptly.
         2.4.2.3.Where unique persistent attributes are associated with an End User, the Participating Organisation must ensure that these Attributes are not re-issued to another End User until at least 12 months after the last possible use by the previous End User.

2.4.3.Granting Access and Identity Establishment

1. 1. 1. 2.4.3.1.Each Participating Organisation must have a documented process for vetting users and issuing credentials to Service Providers' services or resources. The processes detailed in this document must be adhered to with regard to identity verification, data collection and storage. This document must be made available to the Wellington Loop upon request.
         2.4.3.2.The Participating Organisation must use reasonable endeavours to provide End Users who are allocated access to the Wellington Loop, with appropriate information on how to use their credentials safely and securely.
         2.4.3.3.Where applicable, an expiry date for the End User's access must be entered and set at 18 months after the date of access creation.
         2.4.3.4.All End User records in the Participating Organisation must be reviewed and updated yearly.
         2.4.3.5.A leaving student will still have access for a year after completing the school's educational course.
         2.4.3.6.The administration of the Participating Organisation reserves the right to deny or disable access to any staff or student at the organisation.

2.4.4.Login Password

Password allocation and management is the responsibility of the Participating Organisation, and is performed via the organisations' User Directory. The following are guidelines for the management of passwords:

a) passwords are to be no less than 8 characters and no more than 16 characters, and it must include a minimum of 2 digits;

b) password must not be a dictionary word;

c) a Prohibited Password List is to be applied;

1. 1. 1. d) force password changes after 1 year, allowing the user the opportunity to enter a new password;
         e) force new users to re-enter password on first login;

f) access is locked after 3 failed login attempts ;

1. 1. 1. g) user name must not be pre filled;
         h) passwords must not be saved on client machines or browser clients;

i) user name to be displayed on entry, and password entry to be non display ;

1. 1. 1. j) last login date and time to be displayed after password verification; and
         k) passwords kept in a file for verifying the authenticity of the user must be encrypted.

Security

The following are guidelines for data, software and environment security that all Participants need to consider in their ICT infrastructure plans and policies. Security in a network is as weak as its weakest link, and it is paramount that all Participants take this responsibility seriously to protect all involved on the Wellington Loop Federation.

Data

3.1.1.Malicious Software

3.1.1.1.All media and email must be scanned for malicious software such as viruses and spyware.

3.1.2. Encryption

3.1.2.1.It is encouraged that cryptographic controls and digital signatures be used during data exchanges, particularly over the internet and email.

3.1.2.2.Encryption should be used where applications support it and there is no degradation of service delivery.

Software

3.2.1.Apply secure networks and firewalls. Implement appropriate network management controls and policies.

3.2.2.Ensure latest updates to anti-malware software.

3.2.3.Apply application connection closure after 30 minutes of inactivity.

3.2.4.Apply network connection closure after 1 hour of inactivity.

3.2.5.Allow only approved software to be installed on the servers.

Physical Environment

3.3.1.Secure physical access to servers to authorised personnel only.

3.3.2.Set workstation password secure screen saver time-out to a minimum of 5 minutes.

3.3.3.Ensure password lock screens are applied when away from workstations

3.3.4.Access rights to terminated staff to be removed immediately.

3.3.5.Access rights to restricted areas to be reviewed regularly.

Disaster Recovery

3.4.1.Servers must have an uninterrupted power supply (UPS).

3.4.2.Backup of applications and user directories to be done regularly and rotated.

3.4.3.Ensure off site backup storage for monthly backup media.

3.4.4.A Disaster Recovery plan must be documented and known to authorised personnel.

Legislative Compliance

A Participant must, when acting in its capacity as a Participant of the Wellington Loop Federation, comply with any applicable legislation in relation to privacy and copyright, including without limitation, the following legislations:

• Privacy Policy (The Privacy Act 1993).
• Copyright Infringement (The Copyright Act 1994).

Audit and Compliance

These monitoring and assurance policy rules cover aspects of alerts, reporting and management of breaches of policy and the associated remedial and punitive actions to be taken.

5.1. Audits and Reviews

1. 1. 1. 5.1.1.The Wellington Loop may at any time request to perform an audit on the configuration, processes and documentation of its Participating Organisations, with respect to services and connectivity to the Federation. Notice for an audit must be provided at least a week prior to the date of audit.
         5.1.2.Permission for the audit cannot be unreasonably withheld, and reasonable effort must be provided by the Participant to assist in the review.
         5.1.3.Any non compliance or issues noted in the audit will be detailed in writing and provided to the Participating Organisation. The Participant must on receipt of this notice, promptly remedy the non compliance within 30 days.

1. == 5.2. Monitoring and Logging ==

1. 1. 1. 5.2.1.Logging of user authentication processes will be performed by the Wellington Loop Common IdP as well as the Participating Organisations' User Directory system.
         5.2.2.Logging entries are to be kept or recycled for a 6 month period.
         5.2.3.Appropriate alerts will highlight abnormalities to the system administrator of the corresponding systems.

1. == 5.3. Incident Notification and Response ==

1. 1. 1. 5.3.1.All incidents and outages pertaining to the services on the Wellington Loop experienced by the End Users will be reported to the appropriate administrators of the organisation. These will be actioned by the administrators or escalated to the Wellington Loop's Helpdesk to action.
         5.3.2.All incidents and outages received by the Helpdesk or Wellington Loop support team will be summarised and reported to the Wellington Loop Board on a monthly basis.

1. == 5.4. Policy Breaches ==

1. 1. 1. 5.4.1.All breaches of policy regarding access, at the Participating Organisations' User Directory level, will be dealt with by the appropriate authorities at the organisation and in accordance to the Organisation's policies governing ICT and access.
         5.4.2.All breaches of policy regarding access, at the Wellington Loop's Common IdP Service level, will be dealt with by the Wellington Loop Board and in accordance to the Wellington Loop's policies governing ICT and access.

Termination

1. 1. 1. 6.1.A Participant may voluntarily withdraw from the Wellington Loop IAM Federation upon 20 Working Days’ notice to the Wellington Loop Board.

1. 1. 1. 6.2.The Wellington Loop may terminate participation with immediate effect by giving written notice to the Participant, without any compensation or damages due to the Participant, but without prejudice to any other rights or remedies which either the Participant or Wellington Loop may have.

Changes of Rules

Following consultation with Members, The Wellington Loop may, from time to time publish amendments to these Rules, which will become binding upon the Participant upon publication. The Wellington Loop will make the latest version of these Rules available on the website. The Wellington Loop will also communicate changes to these Rules in writing to all Participants.

Dispute Resolution

1. 1. 1. 8.1.If any dispute arises between the parties arising from or relating to these Rules, the Wellington Loop or the Participant will refer the dispute to their respective representatives, whereupon the Wellington Loop representative and the Participant representative will promptly discuss the dispute with a view to its resolution.

1. 1. 1. 8.2.If any dispute cannot be resolved in accordance with Section 8.1 within 10 Working Days, the Participant or the Wellington Loop may require that the matter be referred for consultation between the Principal of the Participant, or their authorised representative, and the Chair of the Wellington Loop Board. In this event, both the Participant and the Wellington Loop will be represented by one or more delegates in consultations which will be held within 15 Working Days of the requirement.

1. 1. 1. 8.3.If a dispute cannot be resolved under Sections 8.1 and 8.2, then the dispute may be referred by either party to the Wellington Loop Board. The Wellington Loop Board may seek expert advice if relevant. The decision of the Wellington Loop Board will be final and binding upon the parties.

Limitation of Liability

No participant will under any circumstances be liable under the law of tort, contract or otherwise for any loss of profits or savings or for any indirect or consequential loss or damage, however caused, arising out of or in connection with the performance or non-performance of this Agreement.

General

1. 1. 1. 10.1.These Rules are governed by laws of New Zealand which will have exclusive jurisdiction to deal with any dispute which may arise out of or in connection with these Rules.

1. 1. 1. 10.2.If any provision of these Rules is held to be unenforceable by any court of competent jurisdiction, all other provisions will nevertheless continue in full force and effect.

1. 1. 1. 10.3.These Rules and all the documents referred to in them supersede all other agreements, arrangements and understandings between the parties in respect of their subject matter, and constitute the entire agreement between them relating to their subject matter.

1. 1. 1. 10.4.The Participant may not assign or otherwise transfer its participation of the Wellington Loop Federation without the prior written consent of the Wellington Loop.

1. = Appendices =

1. 1. == Appendix 1 - References ==

Federation Rules for Participants – Australian Access Federation Incorporated
Technical Review and Solution Design – Identity and Access Management for the Wellington Loop – Catalyst, September 2009
Ministry of Education LMS Interoperability Solution Discussion – Catalyst, April 2009
MLE Interoperability Project – Identity and Access Management within the LAN – Scoping Exercise Report – Edtech, June 2009
MLE Interoperability Development Project – SMS Identity Data Exchange Schema – Edtech, September 2009
Feide – http://rnd.feide.no
Privacy in Schools – A guide to the Privacy Act for principals, teachers and boards of trustees (Privacy Commissioner, September 2009)

1. 1. == Appendix 2 - Glossary of Terms, Definitions, Acronyms, and Abbreviations ==

AUPAcceptable Use Policy
CACertification Authority
CoTCircle of Trust
CoCoTCircles of Circles of Trust
IAMIdentity and Access Management
ICTInformation and Communication Technology
IdPIdentity Provider
MoEMinistry of Education
PKIPublic Key Infrastructure
SSOSingle Sign On
WAYF Where Are You From