2.1.1.2.doc

807 views
751 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
807
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2.1.1.2.doc

  1. 1. University of Edinburgh _________________________________________________________________________________ Stage: Business Analysis Business Requirements Document New Identity Management Service Integrated Services ITS011 AP89-013 _________________________________________________________________________________ Information Services - Template Revised November 2008
  2. 2. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Document Version: 1.0 Date: 10 May 2009 _________________________________________________________________________________ Page 2 of 60
  3. 3. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Contents 1 DOCUMENT MANAGEMENT..........................................................................................................5 1.1 CONTRIBUTORS.................................................................................................................................5 1.2 VERSION CONTROL...........................................................................................................................5 1.3 ABOUT THIS DOCUMENT...................................................................................................................5 2 OVERVIEW..........................................................................................................................................7 2.1 PROJECT DESCRIPTION.....................................................................................................................7 2.1.1 Overview of IAM at UoE..........................................................................................................7 2.1.1.1 IAM Milestones to Date...................................................................................................................8 2.1.1.2 IAM Technologies already in use.....................................................................................................8 2.1.2 Overview of IAM in HE Sector.................................................................................................9 2.2 OBJECTIVES....................................................................................................................................10 2.3 BUSINESS DEPENDENCIES / CONSTRAINTS.....................................................................................10 2.4 LEGISLATIVE IMPACT.....................................................................................................................11 3 EXECUTIVE SUMMARY.................................................................................................................13 4 BUSINESS REQUIREMENTS..........................................................................................................14 4.1 SCOPE OF IDENTITY MANAGEMENT...............................................................................................14 4.2 REQUIREMENT: SERVICES ARE AVAILABLE AT POINT OF NEED......................................................14 4.2.1 Advance access to services.....................................................................................................14 4.2.2 On-Demand access to services...............................................................................................16 4.3 REQUIREMENT: APPROPRIATE SERVICES ARE AVAILABLE TO ALL TYPES OF USER .......................17 4.3.1 Monitoring / Auditing.............................................................................................................19 4.3.2 Removal of services................................................................................................................19 4.3.3 Students / Alumni....................................................................................................................19 4.4 REQUIREMENT: ADMINISTERING ACCESS TO SERVICES IS MORE EFFICIENT AND SCALABLE ........21 4.4.1 Groups....................................................................................................................................22 4.4.1.1 Sharing Groups Between Services..................................................................................................23 4.5 REQUIREMENT: IDM SERVICES ARE MORE ROBUST ......................................................................24 4.6 REQUIREMENT: IDM SUPPORT COSTS ARE LOWER.........................................................................24 4.7 USERNAMES ...................................................................................................................................25 4.7.1 Single UUN per Identity.........................................................................................................25 4.7.2 UUN Formats.........................................................................................................................26 4.8 POLICY FRAMEWORK......................................................................................................................26 5 CURRENT PROCESSES...................................................................................................................27 5.1 BUSINESS PROCESS DESCRIPTION ..................................................................................................27 5.2 BUSINESS PROCESS MAPS..............................................................................................................27 5.2.1 New Student/Applicant............................................................................................................27 5.2.2 New Staff.................................................................................................................................28 5.2.3 New Functional.......................................................................................................................29 5.2.4 New Visitor.............................................................................................................................29 5.2.5 New Alumni (1).......................................................................................................................30 5.2.6 New Alumni (2).......................................................................................................................30 5.2.7 Alumni Data Change..............................................................................................................31 5.2.8 Change Data Applicant/Student/Staff/Visitor)........................................................................31 5.2.9 Student Debt............................................................................................................................32 5.2.10 Staff New Functional............................................................................................................32 5.3 TARGETED BUSINESS PROCESSES....................................................................................................33 5.4 CURRENT SYSTEM CONTEXT DIAGRAM.........................................................................................33 6 FUNCTIONAL REQUIREMENTS..................................................................................................34 6.1 GOLDEN COPY DATA SOURCES......................................................................................................34 6.1.1 Common Requirements...........................................................................................................34 6.1.2 Oracle HR (Staff)....................................................................................................................34 6.1.3 Visitors (VRS).........................................................................................................................35 _________________________________________________________________________________ Page 3 of 60
  4. 4. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6.1.4 eVisitors..................................................................................................................................35 6.1.5 Functional Accounts...............................................................................................................35 6.1.6 Org Hierarchy........................................................................................................................36 6.1.7 eFinancials ............................................................................................................................36 6.2 CORE IDENTITY MANAGEMENT......................................................................................................37 6.2.1 Identity Store...........................................................................................................................37 6.2.1.1 Usernames......................................................................................................................................38 6.2.2 Roles.......................................................................................................................................39 6.2.3 Groups ...................................................................................................................................40 6.2.4 Provisioning............................................................................................................................42 6.2.4.1 Authorisation Services....................................................................................................................43 6.2.4.2 Service Registry..............................................................................................................................43 6.2.5 Reporting................................................................................................................................44 6.2.6 Administration........................................................................................................................45 6.2.7 Auditing...................................................................................................................................45 6.3 INTEGRATION REQUIREMENTS - DOWNSTREAM SERVICES............................................................47 6.3.1 Common Requirements...........................................................................................................47 6.3.2 Visitor Registration Service....................................................................................................47 6.3.3 MyEd.......................................................................................................................................47 6.3.4 Wiki.........................................................................................................................................47 7 NON-FUNCTIONAL REQUIREMENTS........................................................................................49 7.1.1 Security...................................................................................................................................49 7.1.2 Users.......................................................................................................................................49 7.1.3 Performance...........................................................................................................................51 7.1.4 Back Up & Archiving Policy..................................................................................................51 7.1.5 Data Migration.......................................................................................................................52 7.1.6 Conformance with browsers, devices, operating systems......................................................53 7.2 TRAINING & SERVICE SUPPORT REQUIREMENTS...........................................................................53 8 PROPOSED PROCESSES.................................................................................................................54 8.1 BUSINESS PROCESS DESCRIPTION ..................................................................................................54 8.2 BUSINESS PROCESS MAPS..............................................................................................................54 8.3 PROPOSED SYSTEM CONTEXT DIAGRAM .......................................................................................54 9 DATA REQUIREMENTS.................................................................................................................56 10 USER ACCEPTANCE TESTING...................................................................................................57 10.1 STRATEGY.....................................................................................................................................57 10.2 ACCEPTANCE CRITERIA (HIGH LEVEL)........................................................................................57 APPENDIX A – POLICIES.................................................................................................................59 IS POLICIES..........................................................................................................................................59 APPENDIX B – INTERFACES...........................................................................................................60 APPENDIX C – REQUIREMENTS COVERAGE MATRIX..........................................................60 _________________________________________________________________________________ Page 4 of 60
  5. 5. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 1 Document Management 1.1 Contributors Role Department Name Owner IS Anne-Marie Scott Contributor IS Tim Gray Contributor IS Contributor <Business Partner> Contributor <Business Partner> Contributor <Business Partner> In addition to the contributors above, information has been gathered through a series of workshops. Details of all workshop attendees are at: 1.2 Version Control Date Version Author Section Amendment 21/04/09 Draft AMS All First draft in new BRD template. 28/04/09 Draft TG 5 Add process maps 10/05/09 1.0 AMS 2, 4, 6, 7 First issue of document. 1.3 About this document This document differs slightly from the standard IS-Apps Business Requirements Documents template in that it draws a clear distinction between Business Requirements (section 4) and Functional Requirements (section 6). This is primarily because the majority of an Identity Management services business is transacted between systems, rather than between systems and users. Therefore whilst there _________________________________________________________________________________ Page 5 of 60
  6. 6. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ are key business processes and goals that need to be articulated in order to understand and measure the benefits of a new Identity Management service; there are also specific functional requirements that tend towards the technical, that need to be articulated in sufficient detail in order to provide a satisfactory gap analysis, and ultimately systems analysis and design phase to be completed. _________________________________________________________________________________ Page 6 of 60
  7. 7. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 2 Overview 2.1 Project Description The primary objective of this project is to replace the current Identity Management System (IDMS) with a new more robust service that meets the objectives in section 2.2 below. However, it has become clear within the early phases of this project that the replacement of the IDMS has to be seen within the wider context of Identity and Access Management (IAM) strategy within the University as a whole; there are intersecting strategies around uptake of single sign-on and user provisioning / de-provisioning for example. Whilst this project will concentrate on the replacement of the core Identity Management technical components of our IAM infrastructure, it is worth keeping this larger view in sight throughout. The recommendation of the 2007 Scoping Study carried out with Salford Software recommended the procurement of an IDM solution. Subsequent investigation and consultation during 2008 with typical vendors and market analysts, including Gartner, suggest that procurement may not be the de facto route for us to take, and that an open source solution may well be a viable option for us. Package solutions from vendors typically contain more functionality than the University requires (see section 2.1.1.2 below), and would seem likely to leave us with a large amount of development work to do to integrate University systems successfully. At this stage then we plan to pursue an open source based solution with the potential for some in-house development to meet our particular needs. This is a route we have taken successfully in the past in other areas, most notably the MyEd portal and EASE authentication. 2.1.1 Overview of IAM at UoE We have some 10+ years experience at the University of Edinburgh in the various technologies and processes that typically form an IAM solution, and whilst there are issues with the current IDMS technology, our understanding of IAM concepts and our business requirements are relatively mature. Our efforts around IAM to date have been largely focussed around operational efficiency and effectiveness; automating account creation across key services and reducing risk by managing provisioning and de-provisioning of the EASE and Active Directory authentication services for example. The work carried out in 2008 to integrate Applicants into the University EASE authentication service and MyEd web portal has pushed our thinking around IAM forwards into a more user-centric area, such that it should now be seen as a business enabler – timely access to relevant services underpinned by good IAM translates into good service and a positive view of University of Edinburgh IT on the part of key communities, in particular Applicants and Alumni. _________________________________________________________________________________ Page 7 of 60
  8. 8. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 2.1.1.1 IAM Milestones to Date  Directory Services – long history (Novell, Microsoft, OpenLDAP)  Late 1990s – single UUN per identity  Early 2000s – Automation Server established  2004/5 – EASE SSO & Kerberos authentication  2004 – Alumni added to Automation Server  2004 – Automation server used to populate University web portal  2004 – Visitor Registration System released (for affiliate management)  2005 – IDMS Release 1  2005/6 – Central Auth & AthensDA  2008 – Shibboleth instead of AthensDA  2008 – Applicants added to IDMS  2008 – EASE Friend  2008 – eVisitor service established 2.1.1.2 IAM Technologies already in use The following table aims to show how the milestones above translate into an overview of our current IAM components and how this project will impact upon them. Overall it is clear that we have many pieces of the IAM solution already in place. SSO / Authenticatio n Federation Directory Services Group Authorisation s Identity Store User Provisionin g Auditing / Managemen t Active Directory EASE EASE Friend Kerberos Shibboleth (Central Auth) Active Directory Central Auth Oracle Internet Directory Active Directory Central Auth Groups Manager Current IDMS Current IDMS Current IDMS IDMS Portal Mature functionality that the new IDM will integrate with Patchy functionality – the IDM can consolidate and enhance _________________________________________________________________________________ Page 8 of 60
  9. 9. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Existing IDM functionality to be replaced as not really fit for purpose over the long term. 2.1.2 Overview of IAM in HE Sector Whilst it is difficult to get a detailed picture of IAM at other institutions a 2008 Gartner study 1 in this area gives some view of the broad picture:  37% of institutions surveyed have implemented an IAM solution; 29% are in the process of doing so and 20% have plans to start implementing in 2008.  User convenience is a primary driver for IAM programmes across all regions surveyed. Security, lowering costs around user provisioning, federation and SOA strategy are other key drivers. Compliance is also a driver, but the least important in all regions, except North America.  SOA and federation drivers are ranked as more important at larger institutions.  Security over affiliate users access rights is a key driver for many (as many as 30% of institutional users are not in the HR or student records). This figures does not include alumni.  Solutions tend to be a blend of commercial, home-grown and open source. 43% of institutions with a solution in place are using some home-grown components and 31% report the use of open source components 2 .  North America tends to favour procured solutions (51%), whilst Europe and the Middle East tend to favour home-grown (52%).  Larger institutions tend to favour home-grown solutions and more types of solution in their mix (OSS, commercial, home-grown).  High dependence on home-grown IAM solutions by early adopters has been driven by a lack of capable vendor solutions. The complex nature of higher education IAM still means that to some extent this is still the case: large numbers of users, multiple golden copy sources and high turnover are still typical challenges in HE IAM.  Few institutions have a strategy that encompasses institutional IAM, federation and user-centric IAM. The University of Edinburgh fits into this broad view in quite a positive way. We would appear to be in the leading percentile when it comes to IAM, in so far as we have a solution already 1 Gartner Higher Education Security Survey 2008: Progress in Identity and Access Management, JM Lowendahl, M Zastrocky & M Harris. 2 Note that this includes single sign-on technologies such as CAS, Pubcookie etc since this survey looks at IAM as a whole. Single sign-on and directory services are 2 of the most mature open sources areas within IAM. _________________________________________________________________________________ Page 9 of 60
  10. 10. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ implemented and are now looking to replace for strategic / long term requirements. We are very much like our European peers in that we have favoured a blended approach with a focus on home-grown and open source. We are also typical of larger institutions in so far as we see federation and SOA as important drivers and have made headway already around federation with Shibboleth. We have already integrated both visitors (affiliates) and alumni into our current IDMS, fed from well defined golden copy systems. Reassuringly, the work we have undertaken with EUCLID on Applicants also suggests that we have a view on IAM as a user- centric set of processes that can aid recruitment. 2.2 Objectives The objectives for the implementation of a new Identity Management Service are:  Provide a robust, supportable Identity Management service.  Increase the number of services that can benefit from automated user provisioning.  Provide enhanced audit and compliance features, ensuring access to services is only available to those that should have it.  Provide a more holistic view of the multiple roles users hold within the institution, delivering access to services appropriately and making this information available to other personalised services such as the institutional web portal. 2.3 Business Dependencies / Constraints • EUCLID Integration – Generic Interfaces Project (http://www.projects.ed.ac.uk/areas/student/euclid/STU139/index_table.shtml) This project will develop a new interface within EUCLID that will feed several services that ultimately we would wish to feed from the Identity Management service. This generic interface may also be the one that the Identity Management service will source its data from; however it is likely that further data from EUCLID will need to be made available to the new IDM service. Further analysis here is required during the Systems Analysis and Design stage. • HR Multiple Assignments Project (http://www.projects.ed.ac.uk/areas/hr/general/HRS056/index.shtml) This project aims to record where staff are associated with more than one area of the University (for example job share staff). This can be seen as analogous to students who are on more than one programme of study, or alumni who have more than one degree _________________________________________________________________________________ Page 10 of 60
  11. 11. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ from Edinburgh. The new Identity Management service will need to take account of this additional information. This may have implications for downstream services. • Establish Service Oriented Architecture for Corporate IT Systems (http://www.projects.ed.ac.uk/areas/hr/general/HRS056/index.shtml) There is a reasonable degree of assumption around the SOA infrastructure being useful to this project in terms of integration with golden copy systems and real time processing requirements. This infrastructure is not yet in production and is as yet unproven. This does present a risk to this project in that an alternative technology may have to be found; or the Identity Management service project becomes the proof of concept. • Central Auth The original proposal for this project included providing groups management functionality that could be used to enhance group information within Central Auth. A joint bid for funding between IS Apps and IS ITI was made on this basis. This requirement goes hand in hand with the larger objective of providing a groups service for the University as a whole that can underpin provisioning of both groups and users. Central Auth is an OpenLDAP based service, originally developed by the JISC funded AMIE project, and currently provides authorization services that underpin our Shibboleth implementation. In addition it will shortly perform the same sort of authentication functions for Linux desktops as Active Directory does for PC and Mac desktops. It has potential within this project beyond being another service to be provisioned from the central IDM (in the same way as many commercial IAM suites have an LDAP compliant directory within the service). There is good support for LDAP based groups within services such as MyEd and the Wiki service; there is also good support within Apache that could allow Central Auth to handle groups based authorization for websites in a similar fashion to Active Directory. This project should aim to capitalize on Central Auth as an existent piece of infrastructure where this is required and practicable. To be done: Please ensure that any potential risk identified in 2.3 is covered in the project Risk Register. 2.4 Legislative Impact Data Protection / Records Management Since this project is largely about dealing with golden copy data and transmitting that data between University services, both Data Protection and Records Management legislation will have an impact. In the main this will be about respecting and reinforcing golden copy sources and processes; security; and data retention and archive processes. _________________________________________________________________________________ Page 11 of 60
  12. 12. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Disability / SENDA Compliance SENDA is a modification of the larger Disability Discrimination Act, so in that sense both pieces of legislation apply. The main impact within this project will be to ensure that web- based administration and self service user interfaces are accessible. Freedom of Information There are no specific Freedom of Information considerations except those that would already be covered by Auditing requirements. _________________________________________________________________________________ Page 12 of 60
  13. 13. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 3 Executive Summary <to be done once document is complete> _________________________________________________________________________________ Page 13 of 60
  14. 14. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 4 Business Requirements 4.1 Scope of Identity Management Identity Management Services are essentially the set of functions and processes that bridge the gap between the creation of digital identities in golden copy systems, and the use of those digital identities within other University services. Functions and processes related to tying civil identities to digital identities (such as the Entitlement to Work processes around staff recruitment) are outside the scope of Identity Management. The diagram below aims to show where the join between golden copies and Identity Management lies. 4.2 Requirement: Services are available at point of need In order that University members are able to work and study efficiently, and have a positive view of the quality of IT services that we provide, we need to ensure that IT services are available in a consistent and timely fashion. 4.2.1 Advance access to services Ensuring IT services are available in a consistent and timely fashion will often mean that identities and services need to be created and provisioned in advance of official ‘start dates’. The precedent in this area is already well established for applicants and students; however the situation for staff and visitors is patchier:  New Staff – Identities are created and services provisioned at the point a contract is raised in HR  Returning Staff - Identities are re-enabled and services provisioned upon contract start date  Visitors - Identities are created / re-enabled and services provisioned upon visit start date. _________________________________________________________________________________ Page 14 of 60
  15. 15. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ There are often requests from academic staff/visitors who wish to start ‘work’ before the start of their contract, most often requiring access to EASE, email, diary etc and local computing systems. In additional, having accounts and services enabled in advance of start dates allows other local services to be set-up, and induction activities such as scheduling meetings, registering email aliases etc to be carried out in advance of arrival. Promoting and sustaining a productive working environment for staff is identified as an enabler within the University Strategic Plan so there are clear advantages to enabling advance access to services for the staff and visitor community. _________________________________________________________________________________ Page 15 of 60
  16. 16. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Proposed Policy for advance access to services Identity and services set- up Access available to University member Applicants Unchanged: Identities and access to services created (or re-enabled for previous applicants / students) at the point that applications are received. Unchanged: Account credentials issued at the point that applications are received. Students Unchanged: Identities created at point of application (see Applicants). Additional services enabled at point unconditional offer is firmly accepted. Unchanged: Account credentials will already have been issued at point of application (see Applicants). Staff Identities and access to services created (or re-enabled for returning staff) at the point that contracts are raised. Account credentials can be issued once a signed contract has been received by HR. Advance issue of account credentials is not mandatory; it should be at the discretion of the local organisation unit. Visitors Identities and access to services created (or re-enabled) at the point that the visit is approved (rather than just created). Accounts credentials can be issued 7 days in advance of a visit start date. Alumni Unchanged: Identities are services are setup as part of being an Applicant/Student. Unchanged: Account credentials are often already known. Where they are not, the Development and Alumni Services will distribute account credentials assuming that the member is in the alumni golden copy. 4.2.2 On-Demand access to services Within the current IDMS framework the timescales for provisioning services vary considerably, meaning it can take seconds for an Active Directory account to be created, up to an hour for an EASE account, and up to 24 hours for MyEd and WebCT accounts for example. For users and support staff this is a baffling set of timings that creates a great deal _________________________________________________________________________________ Page 16 of 60
  17. 17. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ of uncertainty about whether services are available or not. This most affects the staff and visitor communities. Creating identities and provisioning accounts in advance will streamline this greatly. However, where identities are created on demand (short notice visitors for example), or where service entitlements are being augmented, identities need to be created and at the very least, core central services provisioned in near real time. Core central services are defined as:  EASE  Active Directory  MyEd  Central Auth  Wiki Service  Email  eDiary  WebCT  VPN / Wireless 4.3 Requirement: Appropriate services are available to all types of user We have a requirement as an institution to ensure that as far as is practicable, we adhere to the terms and conditions of the licensed content and software that we buy and ensure that only users who are entitled to services receive them. We also need to ensure for security and reputational reasons that access is limited to only the services that are appropriate to a person’s current relationship with the University. For most types of user policies in this area are quite clear; for example people whose only relationship with the University is as an alumnus or applicant would not be entitled to an Active Directory account or licensed Library resources. Conversely all people whose relationship with the University includes being a student or a member of staff are entitled to both of these are services. For other types of user using the policy is much less clear, and the difficulty is primarily around ‘Visitors’. A 2006/07 Internal Audit report on Licensing of On-Line Materials identified that significant numbers of people were registered within categories of visitor that allowed _________________________________________________________________________________ Page 17 of 60
  18. 18. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ access to licensed resources where this entitlement was not appropriate or was “anomalous to their primary relationship with the University”. <link to further research within this project> The policy around entitlement to services for visitors is modelled within the Visitor Registration Service (VRS), where a choice of visitor category determines the profile of services that they receive. There are 18 visitor categories that staff can choose from within the VRS and the usage of these categories is not always clear, or well aligned to the purpose of their visit. <insert ref to wiki research> A common example where confusion arises is when a student of another UK HE needs access to our services as they are working for us as an intern. The most obvious choice based on the categories presented in the VRS is to set them up as a student visitor (which has a unsuitably restrictive set of entitlements). However, the correct choice is to set them up as a member of non-payroll staff, since in fact the purpose of their visit is to carry out staff-like duties. Consequently staff often chose the category with the most attractive set of services. Visitors are normally set up by local administrative staff at the request of other staff within their area and they are also often asked to enable services that may not be appropriate. This presents obvious tensions. On the one hand local staff are best placed to understand the purpose of an individuals visit within the institution and need the ability to enable access to services with an element of discretion; however they also need systems and guidance that foster best practice, give them sound basis for decision making, and enshrine a sense of personal responsibility for the choices that they make. Throughout all of this there is also a need to retain as much efficiency as possible around service provisioning. We have around 4,500 active visitor accounts at any one time and the prospect of manually selecting services such as EASE or the Wiki (services that all visitors have access to) is unattractive. This project will need to deliver and agree a revised service entitlement matrix for visitors, with a greatly simplified set of visitor types, and a more expansive set of guidance on service eligibility. The focus needs to be strongly aligned with ‘purpose of visit’. This information should be combined with applicant, student, staff and alumni entitlements to create a single unified entitlement matrix for all user types. _________________________________________________________________________________ Page 18 of 60
  19. 19. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 4.3.1 Monitoring / Auditing We need to be able to better monitor and audit which users have access to which services and on what basis that access was granted. At present it is possible to report on the services that an individual has within the IDMS administration tools, but not to report on all the users of a particular service. Although a historic record of all identities is kept, including where an identity had a new UUN granted or was reconciled, the current audit system is inadequate, only providing a few months worth of audit trail. There is no historic archiving or normalising of audit information, which makes it hard to investigate long running issues, or to gather adequate system metrics for performance monitoring. 4.3.2 Removal of services The new service must to accommodate both adding and removing services from identities during the entire time period that an identity is active. The current IDMS has no ability to remove services once they have been granted. The only point at which access to a service is disabled is when the identity is ‘retired’ e.g. when a member of staff leaves, a student graduates etc. If a visitor returns in a different capacity, with a lesser entitlement to services, all of the services they originally had are re-activated, despite this lesser entitlement. 4.3.3 Students / Alumni The transition from being a student to being an alumnus is an area where the University is currently missing an opportunity. Students are currently entitled to a grace period of 150 days (240 for PGR students) after graduation, during which they continue to receive access to services. This is to allow students who are leaving the University time to tidy up emails and other materials that they wish to retain. It also allows continuity of service to students who have applied for further study in the next academic session. At the end of this grace period students who are not staying on for further study convert into alumni. As well as losing services such as their SMS mail account, MyEd layouts for these students change quite considerably; this is one of the most visible effects of this change. This has the unintentional effect of presenting the transition to becoming an alumnus in a negative light; becoming an alumnus is synonymous with services _________________________________________________________________________________ Page 19 of 60
  20. 20. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ being taken away from an individual. This links needs to be broken in order to better promote the University / alumni relationship. The grace period for access to services should remain as-is, but the relationship between student and alumni roles should be changed such that recent graduates see themselves as alumni who retain some student access privileges as a result of their successful graduation from the institution. Ultimately service entitlements during grace periods should be seen as privileges associated with being an alumnus, not being a student. This will require some rethinking of MyEd layouts in order to support this, and will be contingent on how quickly after graduation records can be transferred from the student to alumni golden copy systems. For students who are staying on for further study the case will be slightly different. In this scenario in addition to being Alumni, they will also retain roles as either Applicants, or Students dependant on the progress of their application. _________________________________________________________________________________ Page 20 of 60
  21. 21. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 4.4 Requirement: Administering access to services is more efficient and scalable Identity Management Services must facilitate a high degree of automation for large volumes of users to delivery efficiency benefits. Equally access to Identity Management Services must be able to scale beyond the limited set of IS owned applications that use the current service. Whilst the requirement to ensure that users have access only to the services that are appropriate to them (see XREF above) will require some amount of manual intervention around service selections, particularly for Visitors, there are services that are available to very large portions of the University membership and Identity Management Services must continue to enable automated provisioning of these services. Examples include all members except eVisitors being provisioned with the EASE service, all staff and students being provisioned with Active Directory, all University members being provisioned into MyEd and the Wiki service etc. Integration with our current IDM is also overly complex and costly and as a result various ‘back door’ methods of acquiring identity information have been used around the institution, in particular in areas outside IS. This is clearly a risky practice and has data protection implications. There is strong support around the Schools and Colleges for a central IDM service that will support integration with local teaching, learning and research services. There is also strong support from areas such as Finance for closer integration with IDM services, for example to ensure that only current members of staff have access to Finance applications. The majority of service owners have also identified that a ‘push’ based model for receiving identity information is preferable to the current ‘pull’ based model. This requirement around ease of integration presents clear tensions, as there is a need to support integration with a diverse range of services, current and future, but to do so in a way that is sustainable, efficient and scalable. A highly centralised model is unlikely to work within the University as it is unlikely to be as responsive to requests for integration as is required. Presenting good quality, well described, standards based interfaces to IDM services, along with clear policies and process will likely be the best solution here. It is worth noting that this model is at odds with commercial IDM solutions, which tend to be designed with a large degree of centralised control implicit within them. This reflects that whilst security and compliance are important drivers within the University, they are not the primary drivers for our IDM services (see section XREF above). The ‘connectors’ supplied with commercial solutions contain the application logic and data mappings required to ‘push’ data down into services without the need to install any additional software within the _________________________________________________________________________________ Page 21 of 60
  22. 22. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ downstream service. Each connector is highly tailored to an individual service but ownership of the connector functionality remains with the central identity management service. The two diagrams below provide a simple overview of the two different models. Commercial IDM Model Proposed University of Edinburgh Model 4.4.1 Groups Core to making Identity Management Services work better for services both within and beyond IS is the provision of an authoritative source of groups information, along with groups administration facilities. At present we have a copy of the University’s Organisational Hierarchy within the IDMS. We also hold a single affiliation between an identity and an Org Hierarchy unit. This does allow services that consume both of these pieces of information to create groups and group memberships locally (as MyEd, Central Auth and Active Directory do). However, there are significant weaknesses in the current IDMS around groups:  The current IDMS only holds a single Org Hierarchy membership per identity. This does not adequately represent staff or visitors who work in multiple parts of the organisation. This also does not adequately represent students on more than one programme of study, all of the courses that make up a single programme of study, applicants with multiple applications, or alumni who have taken more than one degree here.  There are no services available within the current IDMS to interrogate group memberships for the purposes of authorisation, or selecting a groups of identities as a _________________________________________________________________________________ Page 22 of 60 Owned by ServiceOwned by IDM IDM Services ‘Connector’ functionality Service Owned by IDM Owned by Service ‘Connector’ functionality ServiceIDM Standard Interface(s)
  23. 23. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ means of selecting a sub-set of the University population e.g. all students on Physics 1.  There are no means of abstracting groups and group memberships out of downstream services, even when these services can accommodate it e.g. the Wiki service.  There are no means by which ad-hoc groups can be created, maintained and shared between multiple services. As well as identifying sub-sets of the University population, based on information from the golden copies, or based on ad-hoc groups created by end users, groups also have a role to play in terms of provisioning services. For example all identities that have the role ‘Student’ would go into a large group containing all students in the University. This large ‘Student’ group then forms the basis for provisioning MyEd, EASE, Active Directory etc. 4.4.1.1 Sharing Groups Between Services There are some particular challenges presented by this project around sharing groups between multiple services, yet ensuring as much automated provisioning as possible continues. The current arrangements around WebCT are a good case in point. This touches on the complexity required around roles information. WebCT currently receives a nightly feed from the IDMS of all staff, students and eligible visitor identities. In addition it receives a feed from the student record of all courses flagged as ‘WebCT Active’ plus membership information about those courses (students studying on the course, the course organiser and the course secretary). An automated process within WebCT creates new users based on identity information, new courses where required, and updates the membership of all courses as appropriate. Students are assigned the ‘student’ role on a course. The course organiser and the course secretary are assigned the ‘course designer’ and ‘course instructor’ roles respectively. Course teaching or admin staff (and occasionally eLearning support staff) are then able to associate any other staff / other students beyond the information held in the student record e.g. PG teaching assistants, other staff tutors etc. In this way the bulk of the provisioning work is carried out automatically, and assuming the course organiser / secretary information in the student record is correct, no further work is required on the part of IS to enable access to the course in WebCT. _________________________________________________________________________________ Page 23 of 60
  24. 24. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ In 2008/09 around 2,400 courses delivered were flagged as being WebCT active, so clearly this provisioning mechanism saves a massive amount of manual effort across thousands of students. However, very often the same groups as are required within WebCT are required by other services such as course mailing lists, authenticated web sites, wiki spaces or local courseware tools. This project needs to find a way of preserving the current efficiencies around automated provisioning, but move the work to associate other members of staff or students with courses out of WebCT and into the IDM groups service such that it can be shared with other services. An ideal situation would be one where the course organiser role from DACS could be translated into ‘course designer’ in WebCT, ‘space admin’ in the wiki service etc. It is also worth noting that the EUCLID Interfaces project has looked at many of the indirect uses of data from DACS and determined that much of the current activity in this area is focused around creation and maintenance of local mailing lists for courses etc. There is a clear opportunity here with sharing groups between services to streamline processes and make transparent the use of identity information across the organisation. 4.5 Requirement: IDM services are more robust Identity Management services have a core part to play in supporting University business. They need to have high availability and be resilient for disaster recovery purposes. The current IDMS has limited resilience capabilities. Given the business critical nature of Identity Management Services, we need to ensure that the new service is co-located and that there are resilience and automated fail-over capabilities built into the design. 4.6 Requirement: IDM support costs are lower Identity Management Services should not be reliant on a high level of manual intervention to ensure normal business keeps running. Administration facilities need to have a high degree of usability, require little training and allow devolvement to local support staff. At present it costs around 2 FTE a year from IS-Apps alone to service the current IDMS. This includes bug investigations and fixes, managing events such as students being taken in and out of service, organisational hierarchy changes, issues with duplicate records, future visits etc. Very little of this effort is spent on any kind of service enhancement. Given the limited set of functions that the current IDMS provides, this is a very high cost. _________________________________________________________________________________ Page 24 of 60
  25. 25. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ A large amount of effort is spent centrally performing maintenance and administrative tasks using scripts direct on the IDMS databases as the web-based administration tools around the current system are very poor. The user interface is particularly difficult to use and the set of functions available to support staff is very limited. The only functions available within the current IDM are:  View a single identity record and service entitlements (no view of this is available for alumni)  View initial password  View leavers reports  View service entitlement matrix  Grant services (complex implementation)  Reconcile Staff to Visitor UUN or vice versa  Reset service status  Add new IDMS Admins (complex implementation) Other common tasks such as taking staff and students in and out of service, renaming UUNs, updating missing email aliases etc are all carried out with scripts. 4.7 Usernames 4.7.1 Single UUN per Identity There has been much discussion about whether this project can undertake the work to reconcile identities down to one identity per real person. This is clearly desirable, but at this stage the costs in undertaking this work vs. the numbers of users affected, and the risks it would add to an already complex project are felt to be too high. This project will deliver an Identity Management Service that could accommodate a single identity per real user in the future, but the work to provide reconciliation facilities and audit downstream services to determine impact should be a future project once the core functions of the new IDM are proven. Notes for Future Reference Experience around the Rectorial Elections in 2009, where we produce a reconciled electoral register with a single vote per person tell us that only only 1161 students out of over 25,000 who where also members of staff. Of these only around 65% could be automatically reconciled. There has also been strong support for retaining a separation of identities where people are both staff and students. For many the distinction between when they are working _________________________________________________________________________________ Page 25 of 60
  26. 26. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ as a student, and when they are working as a member of staff is helpful. The only real viable solution in this area then is likely to be one where the end user chooses to reconcile their identities themselves. 4.7.2 UUN Formats There has also been much discussion around UUN formats, with strong support from service owner for changing all UUNs to be based on a numeric value to avoid UUN changes as a result of name changes, and strong support in the opposite direction from support staff, who find the name based format used for staff and visitors particularly useful in determining whether one is working with the right account or not. The current ‘v1’ pre-fixed visitor namespace is entirely polluted and something of a false distinction. It was felt to be easier to lose the ‘v1’ prefix for visitors. A ‘v’ prefix may still be required for student-like visitors. A discussion around student UUN formats and whether being based on matriculation number was ‘unfriendly’ was also considered. It was felt that this was not a large issue and so it was decided that student UUN formats would remain as-is. 4.8 Policy Framework <to be completed> _________________________________________________________________________________ Page 26 of 60
  27. 27. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5 Current Processes 5.1 Business process description Please provide a description of the current business processes 5.2 Business Process Maps Swimlanes in here detailing all the business processes currently in place that are relevant to the IDMS. This includes processes that currently don’t interact with the IDMS, such as new eVisitors, or services looking for group information, or services that get data direct from the golden copy systems. Also needs to include tables of change codes, IDMS polling times, status codes, matrix of services for types of users. Action: Tim and AMS to complete this section. Reviewed by: Golden Copy data owners, business partners, service providers. 5.2.1 New Student/Applicant _________________________________________________________________________________ Page 27 of 60
  28. 28. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5.2.2 New Staff _________________________________________________________________________________ Page 28 of 60
  29. 29. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5.2.3 New Functional 5.2.4 New Visitor _________________________________________________________________________________ Page 29 of 60
  30. 30. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5.2.5 New Alumni (1) 5.2.6 New Alumni (2) _________________________________________________________________________________ Page 30 of 60
  31. 31. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5.2.7 Alumni Data Change 5.2.8 Change Data Applicant/Student/Staff/Visitor) _________________________________________________________________________________ Page 31 of 60
  32. 32. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 5.2.9 Student Debt 5.2.10 Staff New Functional _________________________________________________________________________________ Page 32 of 60
  33. 33. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ This section provides details of the current processes – a process is defined as a serious of actions, operations, or functions that produces the required outputs. Current processes should be mapped, even where process is manual. Use Triaster, or an alternative business process mapping tool, to map the activities and identify inputs and deliverables for the current business process. The current business process flow diagram describes the current process accurately, including any flaws, or short comings that exist in today's process that will be targeted for repair or improvement by the future process Individual business processes should be mapped separately. If required, provide an index of process maps. Add in links to: Html version of process maps – sample PDF printable version of process maps – sample 5.3 Targeted business processes Annotate targeted areas (areas which require change) in the process maps, and document these in full below. 5.4 Current System Context Diagram The information in the current business system flows from and to other systems. The following diagrams represent the high level context for the information flow between the current system and external entities. Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif _________________________________________________________________________________ Page 33 of 60
  34. 34. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6 Functional Requirements  Mandatory (M) crucial features required to allow the user to achieve key objectives  Highly Desirable (HD) features that help users achieve their objectives effectively but are not crucial to the process  Desirable (D) features that are nice to have as they may enhance the experience for the user 6.1 Golden Copy Data Sources 6.1.1 Common Requirements ID Requirement Categor y 1.1 All golden copies must identify identity records that have changed (where ID management cares about the change – see section XREF for details of data required. M 1.2 Golden copies should push identity information into the ID Management service at point of change, where this is technically possible. HD 1.3 Where it is not possible for a golden copy to push data changes to the ID Management service, it will be possible for the ID Management system to ask for details of all changes. M 1.4 It will be possible for the ID Management system to ask for details of all changes on a regular ‘polling’ basis e.g. every 15 minutes. M 1.5 Where a duplicate identity is created in a golden copy system e.g. a duplicate staff or student record, the golden copy will identify the duplicate record and remove as appropriate. The IDM will treat this as a normal deletion process. M 6.1.2 Oracle HR (Staff) ID Requirement Categor y 2.1 At the point that a new staff identity is created in the Identity Management service the username and email address will be recorded against each member of staff’s record. Oracle HR will not be the golden copy for this information, but this will assist with reconciliation for example when staff return on a new contract. M _________________________________________________________________________________ Page 34 of 60
  35. 35. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6.1.3 Visitors (VRS) ID Requirement Categor y 3.1 It will continue to be possible to select the services that a visitor needs at the point of creating their visit. M 3.2 The current model of visitor categories controlling access to services should be replaced with a model that better reflects the purpose of the visit. The emphasis should be on automating provisioning of core systems for efficiency purposes, but leave enough flexibility that additional individual services can be granted as required. Responsibility for selecting additional services will lie with the College and School staff. M 3.3 It will continue to be possible to print a letter with initial username and one- time registration key information for e.g. EASE registration. M 3.4 It will be possible to register a visitor who has no IT system access – but does have access to doors via the Card system. M 3.5 It will be possible to create visits that have overlapping dates as long as they are associated with different areas of the organisation. M 3.6 It should be possible to set-up new visitors and associated visits in bulk. M 3.7 It should be possible to associate a visitor record with a UUN that already exists within the IDM. This is to facilitate the transition between staff and visitor roles and vice versa. 6.1.4 eVisitors ID Requirement Categor y 4.1 eVisitor should be linked with the new Identity Management service as another golden copy source of identity information so that eVisitor identities can be used within groups. M 6.1.5 Functional Accounts ID Requirement Categor y 5.1 It should continue to be possible to set up Functional accounts for the following purposes: • Generic training accounts • Machine to machine accounts • Exchange Diary resources and associated mail accounts M _________________________________________________________________________________ Page 35 of 60
  36. 36. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ • Generic email accounts and diaries (for example for support teams) 5.2 It should be possible to specify specific usernames for accounts. M 5.3 It should be possible to setup ranges of usernames based on a specific prefix e.g. istest01 – istest10 where ‘istest’ is the prefix M 6.1.6 Org Hierarchy ID Requirement Categor y 6.1 Where the University Org Hierarchy is changing, the following types of changes should be identified when data is supplied to the IDM system: Rename – not moving within the organisational structure Rename – and moving within the organisational structure Move – moving position within the organisational structure New – new organisational unit Delete – old organisational unit HD 6.1.7 eFinancials ID Requirement Categor y 7.1 Where a student is in debt, there should be a process that informs the IDM service to suspend services. Likewise once the debt is cleared services should be reactivated. At present this process is a manual one. Preferably this should be an automated interface. HD _________________________________________________________________________________ Page 36 of 60
  37. 37. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6.2 Core Identity Management 6.2.1 Identity Store ID Requirement Categor y 8.1 The ID store will be integrated with all the golden copy systems. M 8.2 The ID store will hold identity objects including their attributes. The attributes of an identity are detailed along with whether they are mandatory or optional for the different type of University member. Applican t Studen t Alumn i Staff Visitor eVisitor Title M M M M M O First Name M M M M M O Preferred forename O O O O O O Surname M M M M M O Date of Birth M M ID Status M M M M M M Start Date(s) M M M M M O End Date(s) M M M M M O Golden Copy Reference (Staff number / matric / VRS number) M M M M M M UUN M M M M M M Initial Password M M M M M O UID M M M M M M Card Number M M O Library Number M M O Job Title? O O Org Unit(s) M M O M M Programme of Study Code(s) M M O Course Code(s) M Role(s) M M M M M M Email address M M O Personal Email Address O P O O M Note that start dates and end dates are probably per role – see XREF below. M 8.3 ID Status will reflect the currency of the identity as a whole, rather than the particular role. ID status is still derived from the information supplied by _________________________________________________________________________________ Page 37 of 60
  38. 38. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ the golden copy sources. 8.4 At the point an identity is created, an initial password will be generated, according to the same rules as is currently used e.g. 8 characters, mix of numbers, symbols, lower and upper case M 8.5 Initial passwords must be unique. No two users should have the same password. M 8.6 The ID store will be able to reconcile records where the same identity is provided from multiple golden copy systems.  At present this relates to Applicants / Students and Alumni only.  The rule used for reconciliation will be where the username provided by the golden copies is the same in this scenario.  In these scenarios, the name information held by the student record should be the authoritative record.  Associations with multiple organisational units and programmes should be preserved and reflected.  The multiple roles that the identity holds should be preserved and reflected. M 8.7 Where a golden copy system identifies a change to identity data, the ID Store will be responsible for quantifying the type of change e.g. a change to personal details; a change to organisational affiliation etc M 8.8 Once an identity is no longer current (determined by golden copy system), the IDM will maintain a record that it existed, but remove all information received from the Golden Copy except the Golden Copy Reference. M 6.2.1.1 Usernames ID Requirement Categor y 8.9 The ID store will generate usernames for all staff and visitors to the University. M 8.1 0 The ID store will accept usernames provided as part of identity data from EUCLID, ThankQ and eVisitor. M 8.1 1 With the exception of applicant / student / alumni and eVisitor usernames, the ID Management system will be the golden copy source of usernames. M 8.1 2 All usernames must be unique and should never by recycled. M 8.1 3 At present, 8 character UUNs are used. It must be possible in future to increase the size of usernames generated. M _________________________________________________________________________________ Page 38 of 60
  39. 39. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 8.1 4 Usernames must be able to accommodate eVisitor usernames as their maximum length. M 8.1 5 It must be possible to constrain the creation of usernames such that certain characters are excluded. M 8.1 6 It must be possible to constrain the creation of usernames such that certain usernames or words are excluded. M 8.1 7 It must be possible to re-generate a username M 8.1 8 It must be possible to specify a username. M 8.1 9 Usernames must contain at least one alphabetical character M 8.2 0  Three separate name spaces will be maintained: 1 based on matriculation number for applicants / students / alumni;  1 based on visitor number for student like visitors;  1 based on firstname/surname for staff and staff-like visitors. M 8.2 1 Usernames must be unique within their name space. M 6.2.2 Roles ID Requirement Categor y 9.1 The identity store will hold roles, including their attributes. The attributes of a role are:  Role Name  Description? M 9.2 Roles will be derived from the golden copy systems. Roles initially used by the Identity Management Service will be:  Applicant  Student UG  Student PGT  Student PGR  Staff  Visitor – Staff like  Visitor – Student like  Alumnus HD _________________________________________________________________________________ Page 39 of 60
  40. 40. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________  eVisitor 9.3 It must be possible to associate an identity with one or more roles. M 6.2.3 Groups ID Requirement Categor y 10.1 The Groups service will hold group objects, including their attributes. The attributes of a group are:  Name  Unique ID  Members  Owner  Parent  Description  Services that use the group M 10.2 The Groups service will take a feed of the University Org Hierarchy from the Organisational Hierarchy golden copy and build a group for each unit within the University. M 10.3 The Groups service will take a feed of the University curriculum from the curriculum golden copy (DACS/EUCLID) and build a group for each programme and course instance. How far back do we need to go? 4 years? More? In order to keep historic course groups available for e.g. WebCT for the duration of a student’s programme of study. Are groups only auto-created if there’s a current identity that’s a member of them? Do we only get groups from the golden copies where they have a current identity in them. This logic must already exist in the current DACS extract for WebCT… M 10.4 Identities can be members of multiple groups. M 10.5 Groups can contains identities and/or other groups. M 10.6 It must be possible for end users to create their own ad-hoc groups. M 10.7 Ad-hoc groups can contain other ad-hoc groups, or groups auto-created from the golden copy. M 10.8 It must be possible for end users to edit ad-hoc groups, but not auto created groups. M 10.9 It must be possible to restrict ownership and editing rights for an ad-hoc M _________________________________________________________________________________ Page 40 of 60
  41. 41. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ group to a single identity or group of identities. 10.1 0 It must be possible to restrict deletion of groups where they are auto- created or flagged as being used in by particular service. M 10.1 1 When creating or editing a group, it must be possible to select services to be used by that group. M 10.1 2 Where a group contains members whose role explicitly disallows access to a service that has been selected for the group, this should be highlighted. HD 10.1 3 It must be possible to move identities between groups. M 10.1 4 It must be possible to change the parent of a group. M 10.1 5 It must be possible to change any of the attributes of an ad-hoc group except the unique ID. HD _________________________________________________________________________________ Page 41 of 60
  42. 42. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6.2.4 Provisioning ID Requirement Categor y 11.1 Provisioning will be done on a ‘changes only’ basis where only identities or groups that are new, have been changed, or are to be deleted are provided. HD 11.2 The system will facilitate user provisioning. This provides services with the identity information needed to create new accounts, etc M 11.3 The system will facilitate provisioning of group memberships. This provides services with group information. In some cases, this information is used for local authorisation e.g. in provisioning a mailing list, the group information simply tells the system who is a member of the list, so that all e-mails are sent to the right people. But in provisioning WebCT, the service uses this local information to control who may access what information. M 11.4 A standard schema for identity and group objects will be used when provisioning. Different services will not be provided with their own individual schema. HD 11.5 It must be possible to push identities and groups data out to downstream services via the following methods:  a web service, using a standard XML schema  a CSV file out to a specified file location  an email to a specified address M 11.6 It must be possible for a service to pull identities and groups changes via the following methods:  A web service, using a standard XML schema  A jdbc database connection  An LDAP query (note that this requirement may be satisfied by provisioning Central Auth) M 11.7 The IDM should be able to respond to requests for information about a group or user e.g. asking for name and role information based on supplying a UUN. The following methods should be supported to facilitate this:  A web service, using a standard XML schema  A jdbc database connection  An LDAP query (note that this requirement may be satisfied by HD _________________________________________________________________________________ Page 42 of 60
  43. 43. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ provisioning Central Auth) 11.8 It must be possible for a service to pull the full set of identities and groups information that it is entitled to for reconciliation or initial set-up purposes via the following methods:  a web service, using a standard XML schema  a CSV file out to a specified file location M 11.9 Downstream systems will be responsible for matching and updating existing data when changes are received. The expectation is that golden copy data will always overwrite local data where there is not a match. HD 11.1 0 It must be possible to remove service entitlements (de-provision) for any identity on a service-by-service basis. M 11.1 1 The system must be capable of making logical decisions about provisioning, based on identity and group attributes. For example, all identities with the Student role get the SMS mail service. M 11.1 2 The system must be capable of provisioning and de-provisioning based on identity start and end dates. This includes removing or adding identities to groups within the IDM service as well as downstream services. M 6.2.4.1 Authorisation Services ID Requirement Categor y 11.1 3 Facilities will be provided that enable services to query whether a user is allowed to access a service (or an aspect of a service). The group information within the IDM is used as the basis of the decision about whether to grant access. The local service itself does not need to hold this information. The following methods should be supported to facilitate this:  A web service call  An LDAP query (note that this requirement may be satisfied by provisioning Central Auth) M 6.2.4.2 Service Registry ID Requirement Categor y 11.1 4 All services that are provisioned with, or query for IDM data will need to be registered with the IDM service. M _________________________________________________________________________________ Page 43 of 60
  44. 44. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 11.1 5 For each service registered the following information needs to be recorded:  Name of service  Method used for provisioning  Groups of identities available to that service  Excluded roles M 11.1 6 The relationship between services and identities may be recorded by specifying it as part of service registration, or by selecting that service when managing a group. M 11.1 7 It must be possible to exclude certain roles from ever receiving a service. For example if an identities only role is as an alumni, they should never receive access to licensed Library Resources, even if they have been added to a group that has access to Library Resources selected as a service. M 11.1 8 All services that use IDM data from a downstream service e.g. Active Directory / Central Auth need to be registered with that service. M 6.2.5 Reporting ID Requirement Categor y 12. 1 Business Objects will be used as the standard reporting tool. M 12. 2 Standard reports will be provided that show:  All the attributes, group memberships and services that a single identity uses  All the identities and groups within a specific group  All the services that use a specific group  All the groups that a specific service uses  All identities by status  All identities by organisational unit  All identities by role  Full change history for a single identity within any given time period  Full change history for a single group within any given time period  Full change history for a single service within any given time period M 12. For system capacity management purposes, it must be possible to report M _________________________________________________________________________________ Page 44 of 60
  45. 45. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 3 on volumes and types of changes within any given time period 12. 4 Further custom reports can be built by individuals, tailored to their own needs M 6.2.6 Administration ID Requirement Categor y 13.1 Administration facilities should be web-based. M 13.2 It must be possible to devolve administration facilities out to local computing support staff. M 13.3 It must be possible to restrict administration rights based on type of administrator. M 13.4 It must be possible to change service entitlements for an identity. M 13.5 Users must be able to see their own identity record and self-service and opt-in to some services. HD 13.6 It must be possible to suspend an identity. This is not the same as deleting an identity. The expectation is that the identity will be returned to service after e.g. fees have been paid. M 13.7 The IDM should be capable of alerting administrators to specific events, including the addition or deletion of identities within their area. This should be configurable on the part of the administrator. HD 13.8 It should be possible to print a letter with initial username and one-time registration key information for e.g. EASE registration for any type of user. M 13.9 Facilities to allow identity to be verified against golden copy information prior to account credential issue are required for administering staff and visitors working remotely to the University. HD 13.1 0 It should be possible to trigger the re-provisioning of services for a particular identity. M 13.1 1 It should be possible to reconcile UUNs within namespaces e.g. associate a visitor UUN with a staff member and vice versa. M 6.2.7 Auditing ID Requirement Categor y 14. 1 All changes to the following entities must be audited:  Identities  Groups M _________________________________________________________________________________ Page 45 of 60
  46. 46. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________  Services  Administrative privileges 14. 2 Audit information should contain details of the type of change, the source of the change and any user / system identifier that associated with the change. M 14. 3 It must not be possible to change any record in the audit trail HD _________________________________________________________________________________ Page 46 of 60
  47. 47. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 6.3 Integration Requirements - Downstream Services 6.3.1 Common Requirements ID Requirement Categor y 15. 1 Where an identity is suspended from service, access to the downstream service should be disabled, but no account or other information should be deleted. HD 6.3.2 Visitor Registration Service ID Requirement Categor y 16. 1 The VRS should be integrated with the new IDMS for access to Staff and Visitor identity information for the purposes of setting up administrative accounts within the VRS. The current CCD data-store should be decommissioned. 6.3.3 MyEd ID Requirement Categor y 17. 1 The current download from IDMS to MyEd will need to be radically redeveloped. M 17. 2 User provisioning will still be required, but we should investigate whether we should use the uPortal LDAP groups facilities for groups and authorisations. HD 6.3.4 Wiki ID Requirement Categor y 18. 1 The current user provisioning mechanism will need to be redeveloped. User provisioning will still be required and will need to be expanded to include eVisitor accounts. M 18. 2 Groups based on organisational hierarchy and the curriculum must be available within the wiki service. We should investigate Confluence’s HD _________________________________________________________________________________ Page 47 of 60
  48. 48. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ LDAP integration facilities. _________________________________________________________________________________ Page 48 of 60
  49. 49. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 7 Non-Functional Requirements 7.1.1 Security ID Security Requirement Categor y 19.1 Authentication All web based access to IDM facilities should use EASE Authentication M 19.2 Changes to golden copy data It should not be possible to amend any item of data that originates from one of the golden copy services via an administrative interface. M 19.3 Interfaces All interfaces through which identity information is passed should be secured. The exact security used will depend on the interface in question. M 19.4 Devolved Administration Administrators should only be able to administer users within their part of the University. HD 7.1.2 Users ID Users Requirement 20.1 Expected number of current users Around 155,000 users current at any time ~ 35,000 students ~ 8,000 staff ~ 5,500 visitors ~ 100,000 alumni ~ 2500 eVisitors ~ 5,000 functional accounts 20.2 Expected annual user growth Up to 100,000 new IDs created each year. Around 95,000 IDs retired each year. Around 5,000 new alumni added each year. 20.3 Administration System Roles  System Administrator  Service Owner  Support Staff  End User _________________________________________________________________________________ Page 49 of 60
  50. 50. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 20.4 Audience (business areas with access to the system) Access to administration facilities could be available to all staff involved in the support of end users or of systems provisioned from the IDM. End user access would include every current identity within the University. _________________________________________________________________________________ Page 50 of 60
  51. 51. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 7.1.3 Performance ID Performance measure Requirement Categor y 21.1 Identity creation throughputs Ability to handle up to 6,000 new identity creations within 24 hours (based on max UCAS file size of 4,500 applicants, plus headroom) M 22.2 Identity changes Ability to handle data changes of around 35,000 identities within 24 hours (based on annual seeding of courses process) M 23.3 Provisioning of core services Provisioning should take place in near real time. Identity creation to successful provisioning of core services should ideally be complete within 30 seconds for a single identity. HD 7.1.4 Back Up & Archiving Policy Backup and retention will to an extent depend on the infrastructure selected. These requirements assume SAN storage and Oracle RDBMS as likely infrastructure. ID Backup/Archive Requirement Categor y 24.1 Nightly Backups The IDM service should be backed up at least once every 24 hours. M 4.2 Retention Backups should be retained for at least 4 weeks. M _________________________________________________________________________________ Page 51 of 60
  52. 52. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 7.1.5 Data Migration Is there any data we would want to actually migration from the current IDMS? ID Data Source Requirement _________________________________________________________________________________ Page 52 of 60
  53. 53. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 7.1.6 Conformance with browsers, devices, operating systems Administration facilities are likely to be used primarily from within the University and primarily from desktop or laptops. No mobile support is anticipated as a requirement. ID Browser Windows Mac OS Linux 6.1 IE 7.x M N/A N/A 6.2 Firefox 3 M M M 6.3 Other Browsers HD HD HD 7.2 Training & Service Support Requirements Define roles and responsibilities for the new service and deliverable required to underpin this. To be completed. _________________________________________________________________________________ Page 53 of 60
  54. 54. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 8 PROPOSED PROCESSES This section provides details of the future processes – a process is defined as a series of actions, operations, or functions that produces the required outputs. 8.1 Business process description Please provide a description of the proposed business processes 8.2 Business Process Maps Taking into account the business requirements defined above, use Triaster, or an alternative business process mapping tool, to map activities and identify inputs and deliverables for the future business process. Individual business processes should be mapped separately. If required, provide an index of process maps. Add in links to: Html version of process maps PDF printable version of process maps 8.3 Proposed System Context Diagram The information in the current business system will flow from and to other systems. The following diagrams represent the high level context for the information flow between the proposed system and external entities. Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif _________________________________________________________________________________ Page 54 of 60
  55. 55. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ _________________________________________________________________________________ Page 55 of 60
  56. 56. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 9 DATA REQUIREMENTS Please include details of the data to be captured by the new software. This should be listed in the table below. If this is a substantial amount of information, please provide a high level summary in this section, and attach the details as an appendix. For example: Data Group Data required Source Customer Name Date of birth Gender Nationality Application form Application form Application form Application form Contract of Employment Campus identifier Contract identifier Terms of employment HR system HR System Core HR _________________________________________________________________________________ Page 56 of 60
  57. 57. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 10 USER ACCEPTANCE TESTING Please highlight the UAT strategy identified for this project 10.1Strategy Please ensure the following are included in your considerations: Duration of UAT Test setup requirements (e.g. co-dependencies, business cycles) Sources of test data Required participants 10.2Acceptance Criteria (High Level) Referring back to section 4, create high level acceptance criteria for each business requirement. Please note that this section will be used as sign off criteria. Detailed acceptance criteria will be recorded in the UAT Test Plan. Examples of acceptance criteria: 1 Capture HR data for current HESA return ID Requirement Acceptance Criteria 1.1 Facility to capture current version of Finance’s hierarchy Check current finance hierarchy appears in Core HR system 1.2 Automatic facility to load finance hierarchy into HR core system Current finance hierarchy appears without manual intervention in Core HR system 1.3 Ability to validate HESA specific data in Core HR system Run validation report 1.4 Ability to report against extract tables Generate report from tables 1.5 Ability to extract HR data for new starts since previous years return Create report to check data has extracted to table 2 Archive data from final HR HESA submission ID Requirement Acceptance Criteria _________________________________________________________________________________ Page 57 of 60
  58. 58. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ 2.1 Archive of each years submission must be captured and stored Satisfied that submitted data moves into archive 2.2 Ability to report against archive Generate report from archive UAT Document: Add in link to UAT Test Plan here. _________________________________________________________________________________ Page 58 of 60
  59. 59. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Appendix A – Policies IS Policies Entitlement to Services  Visitor/Alumni Entitlement Matrix: http://www.ucs.ed.ac.uk/EUCS/entitlement.html  Staff Accounts: http://www.ucs.ed.ac.uk/isd/accounts/staff.html  Student Accounts: http://www.ucs.ed.ac.uk/isd/accounts/student.html  Visitor Accounts: http://www.ucs.ed.ac.uk/isd/accounts/visitor.html  Access to electronic information services for external users http://www.lib.ed.ac.uk/resources/collections/electaccess2.shtml • UUN Format Policy: http://www.ucs.ed.ac.uk/isd/archpub/accounts/uun.html • Account expiry policies: http://www.ucs.ed.ac.uk/ucsinfo/cttees/citc/policies/accdelete.html  Policy on forwarding of staff email after leaving the institution: http://www.ucs.ed.ac.uk/ucsinfo/cttees/citc/policies/emailfor.html In addition to UUNs never being recycled, this policy says that mail aliases are not recycled. Non IS Policies • Financial Debt Policy: http://www.finance.ed.ac.uk/student/tuitionfees/docs/collection_policy.pdf • HR Disciplinary Policies: o http://www.humanresources.ed.ac.uk/policies/sams/SAM628.html (Academic / Academic-Related) o http://www.humanresources.ed.ac.uk/policies/sams/sam32.htm (Non Teaching) _________________________________________________________________________________ Page 59 of 60
  60. 60. Business Analysis: Business Requirements Document New Identity Management Service Version: 1.0 _________________________________________________________________________________ Appendix B – Interfaces Work that Mairi has been doing to determine what services used what data from the current IDMS. Also note the type of interface e.g. web service, email etc – see notes on wiki at present. Appendix C – Requirements Coverage Matrix Link to external spreadsheet of requirements showing progress. Add in questionnaires as another appendix. _________________________________________________________________________________ Page 60 of 60

×