Identity and Access Management (IAM) Roadmap DRAFT v2. North Carolina State University

Transcription

1 Identity and Access Management (IAM) Roadmap DRAFT v2 North Carolina State University April, 2010

2 Table of Contents Executive Summary... 3 IAM Dependencies... 4 Scope of the Roadmap... 4 Benefits... 4 Risks... 4 Current and Major Foundation Projects... 5 The Internet2 IAM Model... 9 Policy and Governance Source Data / Systems of Record Enterprise Directory Services Identity Data Consumers (Applications, Services) Groups and Privilege Management NC State University Current Account Provisioning NC State University - Planned IAM Services NC State University IAM Governance and Team Structure Next Steps Conclusions Gantt Chart of IAM Initiative Projects APPENDIX A IAM Project List Page 2 of 23

3 Identity is such a crucial affair that one shouldn't rush into it. - David Quammen, writer Executive Summary The area of Identity and Access Management (IAM) has existed for a number of years, particularly in higher education. It has recently been gaining momentum at most universities in part due to an increasing amount of online collaboration between institutions and the growth of identity federations such as InCommon. These new collaboration efforts allow and encourage colleagues and students from academic environments to access shared resources within an identity federation without the need for an account and password on each resource. Additionally, with the growth of services being made available in the cloud (e.g. Google Apps for Education) many of our students and employees will be accessing external resources using their NC State campus credential (UnityID and password). But let s go back to identity and access management Digital identities are the electronic representations of individuals. Therefore, identity management is the management of data that is contained in an individual s digital record specifically data about who they are. Some identity attributes for employees would be their name, phone number(s), campus location and address, job classification, college and/or department and address. Similar attributes are captured for students, and additionally we might have information on program of study, year, college, course enrollment, and whether they have a FERPA privacy block in place. Access Management is the process of granting, maintaining or revoking the entitlements or authorizations individuals (or their digital identities) have to online resources - whether data, applications or services. Identity and Access Management (IAM) covers the entire spectrum of users and their digital identities; the data captured about them, how it is protected and who or what is authorized to access it, how users are designated and differentiated from other members of the community (e.g. students, faculty, staff, alumni, parents, guests, etc.); how sure we are that the electronic credential we issue (username and password) goes to the right person; what services individuals are entitled to use; and the mechanisms, directories and systems that allow them to securely access those services. The IAM Roadmap addresses each of these areas and shows how they re related and dependant on each other. Priority projects are identified that are needed to support current university programs and applications, or lay the foundation for later efforts. These include the current Shibboleth and Identity Federation Project (which is supporting the student and other projects), a Password Management Project to provide self-service password resets (saving the Helpdesk many hours of support calls), Non Name-Based UnityIDs (to protect user privacy and eliminate renaming issues), the Campus Affiliation and Services Matrix to match campus affiliates with the services they require, a Guest Account system, and an Enterprise Directory Services project to develop a central location for campus identity data. The benefits of a fully implemented IAM infrastructure in addition to improving the efficiency and effectiveness of our existing systems - are specified and become more apparent as each project is briefly explained. The risks of not implementing a complete IAM environment are redundant accounts, systems and services; not meeting or adhering to audit requirements, federal regulations and state and federal privacy laws; and not being able to provide access to university services in a timely manner or remove that access when a user s relationship with the university changes. Page 3 of 23

4 IAM Dependencies As part of the overall IAM initiative, there is a dependency on the campus IT and University governance groups and the university data stewards to establish policies and procedures that define the different relationships individuals have with the university, and what services and data they are entitled to access. This extends across the student and employee lifecycles as well as to all non-traditional affiliates. Decisions made by the IAM governance committee(s) will determine what data needs to be obtained about individuals and stored in the appropriate System of Record (SoR). This data is the source for IAM identifiers and attributes that make up the core of the IAM system and is centrally located in the Enterprise Directory Service. Scope of the Roadmap This document is structured to show the relationships between the components that make up the IAM environment and how authoritative and sufficient identity data (attributes) can provide data consumers with the information they need to make appropriate authorization decisions about who should have access to what. The Roadmap is not a comprehensive project plan for addressing the IAM needs of the university. Plans will be developed as specific projects are undertaken to implement or enhance some facet of the overall IAM infrastructure for NC State University. Benefits The IAM Roadmap shows how the functions and components of Identity and Access Management are integrated into an infrastructure that enables many of the university services and online resources to operate more efficiently, effectively, economically and securely. From defining who has what relationship with the university, and as a result of that relationship to what services they are entitled; to provisioning access to those services through account and privilege management, IAM provides a foundation for developing web applications, sharing information and collaborating with others at the university, UNC System, State, National and International level. Risks As with any service that enables people to interact with systems, applications and resources, the availability of IAM services is critical to providing online access to the NC State community. This requires a very robust IAM environment from redundant, fault-tolerant servers, power, and networks, to an appropriate level of support personnel. The underlying infrastructure and backend systems need to be in place for the full benefits of Identity and Access Management to be realized. Another risk is that the growth in demand for IAM services might exceed the resources available to build and grow the infrastructure required to support it. Page 4 of 23

5 Current and Major Foundation Projects The following projects are currently in progress or will be shortly, as they lay the foundation for future IAM projects. Shibboleth and Identity Federation Project The Shibboleth System is a standards-based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner. NC State users of external resources that are members of an identity federation can use Shibboleth to access these resources. This allows the user accessing the remote service to authenticate at NC State using his or her own campus username and password. The user then presents a digital authentication assertion to the resource along with any requested attributes and the resource makes a determination on whether to allow access. NC State established a Shibboleth Identity Provider (IdP) for the university in August, 2008 in response to a UNC-GA requirement to participate in the UNC System identity federation. This was to allow students within the system to register for courses at any of the system schools by accessing an interinstitutional registration application. Since that time, we have become a member of the InCommon identity federation and have the ability to easily set up access to federation service providers (SPs). We are currently exploring the use of Shibboleth to access some of our current vendors that are members of InCommon, rather than having to maintain a username and password on the vendor site and we have recently launched Google Apps for Education for student , which uses Shibboleth for access. Current campus web services that use or are planning to use Shibboleth to provide access are VCL, Moodle/Wolfware, My Pack Portal, the NCSU Library services and a number of web applications in engineering. There is also a strong interest in setting up this application as a potential replacement for the existing web authentication service WRAP. A primary benefit of using Shibboleth is that NC State users authenticate at our campus and don t need to maintain accounts in another location. Additionally, access can frequently be determined by the resource provider without needing to exchange personally identifiable information (PII), thus protecting the privacy of individuals. Password Self-Service Reset & Initial Password This project is well underway and is a foundation project for automating the account provisioning process for new users. It uses the Sun IDM product along with an application developed by AegisUSA that will allow users to set their initial password automatically, as well as establish challenge-response (UIA) questions for future password resets. The ability to set an initial password eliminates the use of a guessable formula for the initial password that is currently in use. By requiring the user to set their challenge-response questions when the initial password is chosen a way is provided for the user to reset their own password if they forget what it is. Currently, a user must come to the OIT Helpdesk in person to have a password reset. A primary benefit of this project is that Sun IDM will be connected to all the Page 5 of 23

6 enterprise account systems (currently Active Directory, Novell edirectory, MIT Kerberos and Google Apps for Education). The connectors that tie Sun IDM to the account systems for synchronizing passwords will also be configured to allow the accounts to be disabled. Once this project has been completed, the Sun IDM connectors will be mapped to other fields in the account systems so that when a student or new hire employee requires access to services they will be provisioned automatically with a SIS or HR action. Consequently, when a student or employee leaves the university, these same accounts can be automatically disabled and access to the appropriate campus services can be de-provisioned. Campus Affiliation vs. Services Matrix This project starts by developing a list of affiliate types that are recognized by the university as distinct populations that receive a unique service or set of services. For example: Student, Faculty, Staff, Alumni or Guest. This affiliation (or list of affiliations) can then be carried as identity attributes for each campus user. To clearly distinguish who is entitled to what services on campus, it may be necessary to provide more granularity by carrying sub-affiliations. For example an Employee who is also a Student and an Alumni, with sub-affiliations of FTE and Grad (MBA). Another example is a Guest who carries a sub-affiliation of Library Patron. These individuals all receive some service or services from the university. These will be mapped against the affiliation type and possibly grouped into service categories. These affiliation attributes or groups could then be used to make authorization decisions about which individuals get access to specific web services. An example of this would be certain licensed online library services. These might only be available to those users who carried a faculty, student or staff affiliation, or guest with a library patron sub-affiliation. Non Name-based UnityIDs There are many issues associated with name-based identifiers (usernames). The biggest challenge from an IT support perspective is the time-consuming and labor-intensive effort to rename an employee when their last name changes. Many applications embed the username in account or record information and these all need to be changed to ensure the individual continues to receive services they re entitled to. Creating usernames (UnityID) that are not name-based will allow us to stop the practice of renaming accounts. An additional benefit is that having name-based identifiers makes it difficult to release a principle name to an application if it can be easily traced back to a student (if they have a FERPA privacy block in place). Just privacy concerns in general would be eliminated if the UnityIDs were randomly generated or used an algorithm that did not include the users name. This project should be relatively simple to implement as it only requires a change to how the UnityID is created. Coming up with an approved formula for the creation of the identifier might be the most difficult aspect of the project. Communicating to campus that renames will no longer be done to Page 6 of 23

7 usernames is also part of this project. An additional enhancement might be to allow users to choose from several usernames when initially entering the university. This might eliminate those situations where whatever method is chosen to create an identifier results in something that is offensive to the individual user. An extension of this project might be to use another numeric campus identifier (ncsuid) to store in records and applications, and only use the UnityID as an alias for logins. It would still be a permanent identifier, but could be changed if there is a problem with it, and not required changes to multiple records and account systems. Enterprise Directory Services An Enterprise Directory Service (EDS) provides campus with a single location for unique user identity data that can be consumed by authorized campus resources and applications. It can be used for many purposes from online person directories to user account information, and to make access decisions around who is entitled to various services. Systems of Record (SoR) would supply authoritative data feeds to the EDS to keep it current. If applications access the EDS rather than using extracts or copies of user data, they would always be using current data and eliminate the possibility of making decisions or reporting on aged data. It also reduces the need for extracts that must be created and copied to multiple systems. The data is much more controlled and secure than a distributed model which gives the data to another owner and must depend on them to keep it secured. The Directory would also hold group and role data that could be created dynamically or by users (either directly through a GUI or by a request to a support team that would create static groups). Groups could be created for any number of purposes classes, distribution lists, department groups, application groups, etc. Groups based on course or class membership could be used to provide appropriate student access to applications such as VCL or Moodle or services such as the Library book reservation system. Roles could be assigned to individuals based on affiliation types, job functions or responsibilities, etc. Application or resource owners could petition the EDS service team to add additional attributes to support their specific services. Guest Account System The Guest account system provides a mechanism to authenticate people who are loosely-affiliated with the university and allow them to access appropriate resources without allowing access to those services restricted to more traditional members of the university community (students, faculty and staff). It also provides a way to enable certain groups of individuals (parents, vendors, alumni, retirees, job applicants, etc.) access to services, without being entered into our HR system as No Pay Employees. These individuals are often provided access to campus services they are not entitled to (or the university is not licensed for) simply because they can login to certain university accounts. Many applications cannot determine a user s affiliation with the university at this time, and therefore assume if someone can login they must be someone who should have access to the service. Having a guest account system would Page 7 of 23

8 provide another way to help make this determination as well as improve the integrity of the HR and Student user data. It also would allow us to capture some limited amount of bio-demo data (to be defined by campus leaders and data stewards) that could be used to provide statistics to different university groups such as admissions, development, athletics, etc. Seminars, summer youth camps, sports camps, continuing education and conferences would fall into this group of campus programs that might need guest access to services. If these individuals transition to a more traditional relationship with the university over time, it could be determined where they first experienced contact with NC State and provide an opportunity to evaluate the effectiveness of these programs in encouraging a renewed and richer relationship with the university. Page 8 of 23

9 The Internet2 IAM Model This diagram was developed by the Internet2 - Middleware Initiative (I2MI) and highlights a model of Identity and Access Management for Higher Education. middleware.internet2.edu Page 9 of 23

10 Policy and Governance Define user Affiliation Types for the university and what Services should be provided to each affiliate or group of affiliates Determine the risk associated with enterprise applications and what Level of Assurance (LoA) and strength of authentication (e.g. Strong Passwords, Second password, multi-factor) should be required for access to each Approve and support implementation of procedures for identity-proofing employees, students, affiliates and guests to meet each Level of Assurance (LoA) required for access Approve access to university identity data in the Enterprise Directory Services (e.g. College, Department, Application/Server, Individual) Authorize the creation of IAM working groups or project teams to address IAM areas of need Set priorities of various IAM projects based upon the university business need and available resources Page 10 of 23

11 Source Data / Systems of Record Systems of Record (SOR) should be identified and the appropriate authoritative data elements or attributes made available to the Identity Management system and/or an Enterprise Directory Service (EDS). The University Data Stewards define what identity data is authoritative (above), approve population of the data into an EDS and who can access it. Traditional campus users (faculty, staff and students) are distinguished from those who are more loosely affiliated with the university. Create a Guest System System of Record, to contain accounts and identity data for non-traditional users. Provide for movement of users between the guest and enterprise systems as their affiliation changes over time. Page 11 of 23

12 Enterprise Directory Services Design the Enterprise Directory Service to hold all the commonly used authoritative identity attributes of traditional and nontraditional users to provide the most value to authorized university identity data customers/consumers Continually evaluate technologies, methodologies and peer solutions to determine if NC State is providing the best service for our customers Evaluate and make recommendations on how to use the IAM system to provide identity information that allows campus resources, services and applications to make appropriate access decisions (e.g. Library services, LMS, college or department web resources, enterprise applications, etc.) Promote appropriate technologies if they can facilitate effective, efficient access to Systems and Services (e.g. Federated Identities, Single Sign-on, Single Authentication environment, twofactor authentication) Page 12 of 23

13 Identity Data Consumers (Applications, Services) Evaluate customer business requirements and needs for identity data and other IAM services Enhance the IAM System (e.g. additional attributes, group and role management, entitlements, etc.) to meet these data needs and to facilitate appropriate and secure access to campus resources where required Provide appropriate attributes to Federated Partners where agreed to by federation policies or agreement (contract) with the Service Provider Page 13 of 23

14 Groups and Privilege Management Look at the implementation of fine-grained group management as a means of providing access to university applications and resources Find or develop tools (scripts) to create entitlements for users based on group membership or roles, and use where appropriate to facilitate access to applications, services and resources Work with campus to transition their resources and applications to use shibboleth and group, role and attribute/entitlement-based access Review and recommend a process or application for group creation (centrally and/or user managed) Look at functional role management and privilege management as a way to provide access to applications and services Page 14 of 23

15 NC State University Current Account Provisioning Page 15 of 23

16 NC State University - Planned IAM Services Page 16 of 23

17 NC State University IAM Governance and Team Structure Page 17 of 23

18 Next Steps After the adoption of the IAM Roadmap, projects will continue in support of the IAM Initiative. The priority of the projects and the resources required to implement them will be determined by the campus business needs and at the direction of the IAM Oversight Committee. The IAM Service Team will continue to review the roadmap and make updates to it and the IAM Project list. They will also continually evaluate the progress of existing projects and make recommendations to the IAM Oversight Committee for establishing new projects or forming new teams as campus demands, business needs, changes in regulations or new technologies dictate. Conclusions The IAM Roadmap is not a static document. As progress is made on various IAM Projects the priorities of the remaining areas of IAM will change. Also, new technology or tools may influence when and how IAM projects are prioritized. What won t change are the business needs of the university for accurate, authoritative and secure identity data about campus community members and guests, and the ability to quickly and securely authenticate those users who have a right to access the university s resources. Page 18 of 23

19 Gantt Chart of IAM Initiative Projects Page 19 of 23

20 APPENDIX A IAM Project List IAM Topics / Tasks Description / Comments Relationships Affiliation vs. Services Matrix Identification of Affiliations Mapping Affiliates to Services When they receive/lose services ID-Proofing & Initial Issuing of Credentials Student Employees Affiliates (non-students) Remote - Distance Education Creation of University Identifier? (ncsuid) Enterprise Directory Services Schema Changes Group Management Determine what different affiliations exist and whether to group into categories Identify what services the university provides to "each" affilate type (e.g. student, alumni, parent, staff, contractor) Needed to implement appropriate provisioning & de-provisioning of services for each affiliate (or group/class of affiliates) Elevate LoA at time of Campus ID receipt Completed when filling out Form I-9 Numeric Identifier that exists outside of ERP systems Adding attributes and Object Classes Some affiliations are part of the Student or Employee "life cycle" and transitions between affiliations result in the addition or removal of services provided People could be provisioned into "affilation groups" that have a specific set of services (e.g. MyPack Portal Self-Service, Library Services, Alumni Services) (see above) Handoff of campus credential (or recredentialing) Potentially need to achieve LoA "2" for certain apps (included for completeness) Required for access to resources Required for access to resources Would allow people to move between guest system and HR/SIS as their affiliation with the university changes Add eduperson, eduorg, educourse Object Classes as well as Student Class data Needed for centralized access management to resources; Requires tool(s) or scripts to Page 20 of 23

21 implement Entitlements (Attributes) Adding Attributes (Process) Federated Identity Attributes Identify Systems of Record Technical Implementation Decisions Shibboleth/SAML - Federation Production IdP (Identity Provider) NC State Federation Process for new SPs WRAP replacement MyPack Portal Currently in place, but need to improve robustness of service (failover, load-balancing) Shibboleth for campus resources and web apps Documentation and Approval Process Shibbolizing Portal authentication Usually created as a result of Group Membership or having a certain "role". Would also be used in access management decisions by web apps or protected resources Requires an approval group (Data Release Management Oversight Committee); Can be used for access management Same as other attributes, but need to be made available to federation SPs Needed to ensure that attribute data is "authoritative"; alternatively to consider additional identity data attributes added to the EDS? Required for any shibbolized services (either internal or external) - needs authentication mechanism and attribute data (EDS) Same prerequisites as above; Can provide WRAP replacement for campus web apps Required to create new SPs within NC State Federation IdP needs to be at full production capability; Process needs to be published, with review committee or approval workflow in place NC State Federation needs to be in place or portal may need to operate within the UNC System Federation; applications behind the portal may need to be modified to accept additional credentials (UNC-CH users?) Page 21 of 23

22 Attribute Release Policy (ARP) uapprove Privacy Flags Account Management & Authentication Sun IDM Hardware Upgrade - Production Account Provisioning Account De-provisioning Guest Authentication System Reduced AuthN Environments Multi-factor authentication Single Sign-On (SSO) Both the policy decisions and the technical execution of the policy that determines which identity attributes are released to which Service Providers (SPs) A tool/utility to allow a user to see what attributes are requested by a SP (above and beyond those attributes that would normally be released) and authorize their release Review uapprove and FERPA regulations with Internal Audit and Legal Affairs Authentication Environment for nontraditional campus affiliates Make effort to utilize a minimum set of authentication service(s) More than just username/password Should be in place prior to releasing student attributes to external federation resources - needs approval from HR and Student data stewards Policy decisions must be made in order to implement the ARP within the IdP.XML files as well as within uapprove; release of student attributes to any external SP require uapprove to be in place (must check FERPA privacy block) Must be checked by uapprove prior to releasing attributes for students Need additional hardware to handle increased load. Requires "trigger" from HR or SIS SOR; Effort to minimize the number of accounts provisioned (same as above - trigger; minimal number of accounts) Need policy to define different affiliation types, services provided, start/stop dates for services; Need to understand whether attribute data will be kept in EDS along with traditional campus members Stable, primary authentication environment for all services; reduce synchronization of credentials Requires application(s) ability to take advantage of another factor, or to implement a second password or reprompt Ability to re-use an authentication credential previously obtained by the user Page 22 of 23

23 Password Management Obtaining initial password; self-service password resets Single authoritative source for campus password; ability to securely sync with other systems if necessary Controls (FGPP)? Need application or tool to implement Issuing Initial Password FERPA and other regulation may determine "how" we can do this; also ties in with identity proofing for on-campus and remote students Need to have "Proponderance of Evidence" to issue to a user via US Mail, Cell Phone, ? Self-Service Password Resets (UIA) Probably through Sun IDM Need adaptors or connectors in place to implement UIA questions; UIA in place to do self-service pwd resets Privileged account management Use SAR? Connectors to required system; determine workflow to approve accounts and access; implement in SAR? SAR/SunIDM should push administration policies consistently to all systems it provisions Not clear on this one - implying that there needs to be consistent password policies across platforms, applications? Page 23 of 23