Humboldt State University Request for Quote #03152013 Identity Management System

Humboldt State University Request for Quote #03152013 Identity Management System Addendum #1 The following changes, omissions and/or additions to the Request for Quote Documents shall apply to proposals made for and to the execution of the various parts of the work affected thereby and all other conditions shall remain the same. In case of conflict between Request for Proposal Documents and this Addendum, this Addendum shall govern. Table of Contents Section A: The RFQ Table of Contents incorrectly identified the Vendor Checklist as A.7 and omitted the listing for the Evaluation Criteria. The Table of Contents should have identified the Evaluation Criteria as A.7 and the Vendor Checklist as A.8. The section heading numbers and content were correctly identified in the body of the RFQ as A.7 Evaluation Criteria and A.8 Vendor Checklist B.1 Executive Summary: The final sentence of this section has been corrected from The vendor checklist contained in Section A.7 should follow the Executive Summary. to The vendor checklist contained in Section A.8 should follow the Executive Summary. A.4 Schedule of Events: The deadline for vendor responses is unchanged; all responses are due by Wednesday, April 17, 2013 at 4:00pm. Questions submitted by various prospective proposers: The University s response to each question is as follows: 1. We would like to know more in detail about payment option. If this bid is rewarded to my company, how would HSU pay us? Such as, are you going to pay us monthly bases, quarterly, based on level of completion, or after the completion? Also, we would like to know if there is any pre-bid meeting. Payments will be made based on the terms agreed to in the final contract and associated terms and conditions. If you have payment requirements or preferences, include them with your response to the RFQ. There will not be a pre-bid meeting, but all questions submitted by 4/4/13 will be included in an addendum to the RFQ and sent to all potential vendors on 4/8/13. 2. Section A.8 Vendor Checklist: Document Set-Up - The headings listed below are missing from the checklist. Is this purposeful? B.2 Profile ( the sub-sets are displayed: (B.2.1 & B.2.2) B.2 is the heading for B.2.1 & B.2.2; there is nothing to respond to for B.2 alone. HSU_IDM RFQ 03152013 Addendum 1.docx Page 1

C.2 General Characteristics (seems no response is required to this section) C.2 is informational to the vendor to take into consideration when proposing their solution. C.4 Specific Requirements ( the sub-sets are displayed: C.4.1 & C.4.2) C.4 is the introduction to sections C.4.1 & C.4.2; there is nothing to respond to for C.4 alone. D.2 Proposed Schedule Paragraph 3 in section D.1 Proposed Implementation Plan notes that At a minimum, the proposed plan should include a Project Schedule and Timeline including estimated start and end dates, milestones, and accompanying written explanation for complete project implementation Therefore, the information on your proposed schedule should be part of your response to section D.1; section D.2 just reiterates schedule information contained in the project scope and other details informational to the vendor to take into consideration when proposing their solution. D.3 Acceptance Testing D.3 is informational to the vendor to take into consideration when proposing their solution. 3. User Provisioning a. Of the resources to be managed, how are they administered? i. Distributed among departments? No. ii. Geographical areas? No. iii. Centralized IT group? Yes. b. Are employees granted access to systems based on job roles/classifications (i.e. all Level I accounts immediately receive these four standard access )? Yes, initial provisioning to standard accounts (OpenLDAP, Active Directory, Kerberos, Google Apps, Web Servers, Databases) is fully automated based on affiliation. c. Are new employees, students granted access to systems based on a per platform/application need? Initial automated provisioning is all to the same set of systems. Additional provisioning is based upon appropriateness for the role and responsibilities of the position. d. Are the provisioning/de-provisioning processes standard for all resources or do they differ by application? This currently differs by application but our goal in this process is to develop a standard process across all resources. i. If non-standard, please list the resources that are different: In some cases provisioning is done manually in the local system. HSU_IDM RFQ 03152013 Addendum 1.docx Page 2

e. Do you currently have conventions for creating new user accounts for each of the managed platforms/applications (i.e. Lastname, Firstinitial)? FirstInitialMidddleInitialLastInitialNextup# eg, mam87 i. Are new ID s consistent across all platforms? Yes, although users may have additional special privilege accounts that start with the username and have an appended _xxx indicating the type of account and privilege. ii. If not, is this an objective for the project? N/A f. When an employee leaves the company, what is the current process used to remove their access rights from the IT systems? Deprovision report, list of access For Active Directory, Kerberos, and Databases - Where no active affiliations remain, accounts are locked nightly and deleted after 40 days. Access to many systems is provided through a synchronized set of groups in Active Directory and OpenLDAP. Group Membership changes are performed every 4 hours and calculated and rebuilt nightly. Affiliation attributes are also stored in OpenLDAP edupersonaffiliation attributes which are calculated and updated nightly. Other systems which use local groups use manual processes for deprovisioning. Former employees are allowed to keep access to email and self-service portals which rely on OpenLDAP for authentication. 4. Identity Data Synchronization Yes, Identity Data including users and groups is in scope and should be synchronized across all directories and target systems. a. Are there exception cases, complex scenarios, or other cases that fall outside a simple synchronization/copy scenario? There are some exception cases that may need to be handled manually. b. Are there rules which require specific accounts to be filtered? No. 5. Password Management a. How will initial passwords be assigned? Random One Time Passwords (OTP) are sent to prospective students home address via US mail. New employee random OTPs are sent via email to the email address provided to Human Resources during on-boarding. OTPs may not be used to access any system other than the password management interface. OTPs are human readable and must be locked after 5 failed attempts. b. How should subsequent passwords be assigned? Existing campus password strength, re-use, and complexity requirements must be enforced by the password management interface. 6. Reconciliation/Data Correlation HSU_IDM RFQ 03152013 Addendum 1.docx Page 3

a. For the applications and systems that will be managed by the Identity Manager product, are the account names consistent across the platforms? Yes. i. If not, is there a key common to all resources that may be used as a correlation key for linking accounts to an individual? N/A ii. If so, what is the correlation key? Peoplesoft HCM/SA EmplID number. 7. Business Processes and Rules a. Are processes established concerning provisioning workflow? Yes. i. If so, are the processes documented? (Please provide sample workflow diagrams if available) Workflow diagrams are not available at this time. b. Is integration with a problem management (help desk) application required? No. i. If so, which application and what version? We use Kace, but integration is not required at this time. 8. Role Management a. Do you have IT or Business roles defined in your organization? Yes. i. If so, how do you provision these roles today? Through standard provisioning processes using affiliations that are calculated from PeopleSoft. 9. Identity Certification a. Are you currently performing identity certification? No. i. at what frequency? N/A ii. is it manual or automated process N/A b. How do you perform remediation? (e.g. Closed-Loop) N/A 10. Policy Enforcement a. Do you have existing IAM policy that needs to be enforced? N/A b. Do the need to be enforced at provisioning time? N/A c. Are detective scans sufficient to meet your requirements? N/A 11. Technical Infrastructure HSU_IDM RFQ 03152013 Addendum 1.docx Page 4

a. What is the platform(s) on which the Identity Manager product will be installed (product/version)? Dependent on selected product. i. Application Server? Dependent on selected product. ii. Operating System? RHEL 6.3 or Windows server 2008R2/2012 are preferred iii. Database? Oracle 11G is preferred b. What email application (include version) will be used for email notifications/workflow approval requests? Google Apps for Education 12. Is automated provisioning in scope for this project? If so, please provide detailed requirements for provisioning as section A.2 references replacing an existing provisioning but section C does not provide detail. Yes, initial provisioning is fully automated based on affiliations calculated from data in PeopleSoft. Standard accounts are created in the IdM and populated to the main directories (OpenLDAP, Active Directory, Kerberos) and placed into relevant groups in OpenLDAP and Active Directory. Additionally, accounts are created in our hosted Google Apps for Education domain via Google's Java based API. Further self-service provisioning of web accounts and personal MySQL Databases is also possible for users with eligible affiliations. 13. In section C.4.2 Preferred Requirements, number 1 & 3, can you please provide more detail, specifically around the business goals? (1) Faculty and student governance groups hold elections on a recurring basis using Account Center; (3) Policies internal to the CSU require that we be able to audit our Identity Management system and directories for accuracy. 14. Please confirm the number of end users in scope for the following categories: 7200 is HSU s FTE (Full Time Equivalent) student population per IPEDs. See current headcount below: a. Students 9723 b. Applicants 14652 c. Alumni 14381 (w/ unexpired passwords) d. Faculty, staff & administration 2293* e. Contractors 42 f. Volunteers included in * above g. Guests 45 h. Former Students/Graduates see alumni i. Former Employees 100 (who are not also current/former students) j. Special purpose accounts (departmental, web, calendar resources) ~200 15. What is the authoritative source of data for each of the defined categories of end users: a. Students Peoplesoft HR/SA HSU_IDM RFQ 03152013 Addendum 1.docx Page 5

b. Applicants Peoplesoft HR/SA c. Alumni Not really tracked, just former student in HR/SA d. Faculty, staff & administration Peoplesoft HR/SA e. Contractors Current IDM system (Account Center) f. Volunteers Peoplesoft HR/SA g. Former Students/Graduates Peoplesoft HR/SA h. Former Employees Peoplesoft HR/SA i. Guests Current IDM system (Account Center) 16. To what degree will the CSU Accessibility Requirements effect the decision making process for this RFQ? Review of accessibility is required for all purchases greater than $15,000. Should the product that most meets our functionality requirements not be accessible, we will be required to develop an equally effective alternative access method and will negotiate with the vendor to develop a roadmap to becoming fully accessible. 17. Please list the other companies that have been invited to participate in this RFQ. VENDOR NAME CONTACT EMAIL PHONE Advanced Integrated Systems Vera Russell vrussell@aisconsulting.net 714-572-5600 Aegis Identity Software, Inc Janet Yarbrough janet.yarbrough@aegisidentity.com 303.589.5435 AlphaCorp Security Brian Minner bminner@alphacorpsecurity.com 765-532-3259 Bid Ocean, Inc Sherry Ramer eric@bidocean.com 866-347-9657 Brooks Company Dick Brooks dick@brooksco.com 800-959-6560 Carillon Information Security, Patrick Dube pdube@carillon.ca 514-485-0789 Inc. Cloupid, Inc. Ryan Champion ryan@cloupid.com 310-871-1128 Column Technologies Matt Moore mmoore@columnit.com 630-297-1467 Courion Brad Frost bfrost@courion.com (508) 948-6282 Dell Inc Cheryl Gardner cheryl_gardner@dell.com 916-761-2456 Enable-IT Dennis Rex dennis@enableit.com 714-243-8577 Fischer Gary O'Neill gjo@fischerinternational.com 678-366-0426 FYA Construction James Appleton fya.construction@gmail.com 608-217-4611 Global Technology Solutions, Kamal Deep Kamal@globaltsinc.com 916-669-8691 Inc. Government Technology Kameron Militano kmilitano@gvtechsolutions.com 800-326-5683 Solutions GreMark Consultancy, Inc. Gregor Mark gregormark70@yahoo.com 860-555-4418 HEAVENLY TECHNOLOGIES RON BRANDON ron.brandon@heavenlytechnologies. 916-706-8145 net Heritage Global Solutions, Inc. Nicole Buchan nicole.buchan@heritageglobal.com 619-866-4284 HSU_IDM RFQ 03152013 Addendum 1.docx Page 6

HOMEFRONT LIGHTING INC TOM TREPANIER tomtrepanier1@hotmail.com 760-720-7662 Innovative Federal Operations Larry Wick ifogusa@gmail.com 800-314-8902 Group, LLC itab ALEX LIM info@goitab.com 213-663-4095 KDJA Services LLC Karen Adams karenadams2289@att.net 888-551-0227 Lasting Impressions Katie Fuller katie.fuller@yahoo.com 530-701-6421 MAXIMUS FEDERAL Franklin Smithson franklinjsmithson@maximus.com 703-251-8240 SERVICES mhc ram kumar mhc@mobiusservices.in 718-257-6611 Microsoft Eric Smith Eric.Smith@Microsoft.com 206.251.0251 Multicard, Inc. Lindy DeCastro ldecastro@multicard.com 480-966-6536 Onvia Kevin Green sourcemgmt@onvia.net 206-373-9309 Oracle Dan Rupinski Dan.Rupinski@oracle.com 650-291-0852 Smart Tools Byron Siu smarttools@att.net 650-967-3875 SUMEDHA Global Computing Manohar Mandadi mmandadi@sumedhaglobal.com 916-524-9052 Sypherlink, Inc. Charlisa Marcum charlisa.marcum@sypherlink.com 614-652-6100 Visionary Integration Professionals (VIP) Kelly Skelton aarfpey@vipconsulting.com 916-830-3106 18. In A2, scope is defined to be serving 7000 Students. The RFP then notes that the solution must also serve applicants, alumni, faculty, staff, guests, contractors, and volunteers (for a total of eight customer populations). So that we can present the requested complete proposal, please provide the approximate number of people in each population and the number of major groups within each. If possible, summarize the requestable resource access required for each population. 7200 is HSU s FTE (Full Time Equivalent) student population per IPEDs. See current headcount below: a. Students 9723 b. Applicants 14652 c. Alumni 14381 (w/ unexpired passwords) d. Faculty, staff & administration 2293* e. Contractors 42 f. Volunteers included in * above g. Guests 45 h. Former Students/Graduates see alumni i. Former Employees 100 (who are not also current/former students) j. Special purpose accounts (departmental, web, calendar resources) ~200 19. What are the acceptable platforms available and supported by HSU for hosting the application (OS, DB, etc.). For example, are Windows Server 2008 on VMware ESX and MS SQL 2008 R2 available for hosting the IdM system? VMWare ESX HSU_IDM RFQ 03152013 Addendum 1.docx Page 7

Redhat Enterprise Linux 6 Windows Server 2008R2 or 2012 Oracle 11G MSSQL 20. Are there any other inputs besides those listed we should consider, including 1 - Scheduled queries to PeopleSoft HR PeopleSoft Student PeopleSoft Finance Accounts for guests and contractors are created locally in Identity Management System. 2 - Can you please confirm the versions of all integrated PeopleSoft modules? PeopleSoft versions are currently at version 9.0 3 - Any web self service functions? Please refer to the RFQ, section C.4.1, item #1 21. So that we can replace as-built functions, if possible please list existing input scripts by function which query PeopleSoft HR, Student, and Financial systems. This detail will be provided to the selected vendor. Please detail the process by which existing input scripts will be replicated using your solution. 22. Are screen shots available for all existing web self service functions so that we can make sure we factor the features and functions you will require we replicate in our proposed solution? Please provide in your response a description of the web self service functions available in the current shipping release of your solution. 23. Are there any other output targets we should consider in addition to those listed, including: AD OpenLDAP Kerberos MySQL Oracle Linux (via listener API) Google (via Java API) No, not for this proposal. If you have a full list of output targets that your solution natively supports, please include it with your response. a. Can you please confirm the versions of all in-scope target resources? AD = Win 2008R2 Servers Active Directory Functional Level 2008 OpenLDAP = Red Hat Enterprise Linux Server release 5.5 (Tikanga) OpenLDAP v 2.3 Kerberos = Red Hat Enterprise Linux Server release 5.9 (Tikanga) Kerberos 5 release 1.6.1 MySQL = Red Hat Enterprise Linux Server release 6.4 (Santiago) Red Hat Enterprise Linux Server release 6.4 (Santiago) mysql Ver 14.14 Distrib 5.1.67, for redhat-linuxgnu (x86_64) using readline 5.1 Oracle = Red Hat Enterprise Linux Server release 5.8 (Tikanga) Oracle 11.2.0 Linux = Red Hat Enterprise Linux Server release 6.4 (Santiago HSU_IDM RFQ 03152013 Addendum 1.docx Page 8

Google = Google Apps for Education 24. Please detail number of each target directory and system (for example if there is more than one AD Forest, how many MySQL instances must be supported, etc.) There is one AD Forest. There is one MySQL instance that accounts are provisioned to and one Oracle instance that accounts are provisioned to 25. Please provide details on the target Linux environment, including number of hosts, number of groups and roles supported (so that we can scope effort for the complexity of your environment), and if a directory (such as NIS, NIS+, or LDAP) or if native OS authentication is used today by your as built "listener API interface" currently in use. Currently only our production web server is provisioned via the listener API. Authentication to the Linux server still happens via Kerberos, but the Identity Management System sends over the username of the approved web developer who is to be added and the web site name to the web server via a TCP connection to the listener. The listener process then performs a useradd function to create an account for the new developer, adds them to the group with permission to write to the directory that site lives in, and creates a symbolic link from the user s home directory to that web directory. Other Linux systems use Kerberos authentication with local accounts and group membership for authorization. 26. For C.2.3, describe and quantify the identity management staff who shall be trained and expected to support the system. If available, a link to an organization chart would be ideal. To accurately scope training required, please include a technical summary of the skills for the key internal support staff for the IdM application. The org chart is available at: http://humboldt.edu/its/sites/its/files/docs/internal-itsdocs/its%20org%20chart.pdf. Primary operational responsibility for Identity Management is with the Enterprise Data Management group. Within that group, Peter Johnson and Jeff Stebbins, who are both programmers and database administrators will need to be trained to support the system. 27. For C.3.5.1 - Describe the functional requirements and security architecture (specifically authentication accepted by security policy) for the requested SMS password reset functionality. The desired SMS functionality would be for users who have forgotten their password, but have previously entered an SMS number into the IDM system, one password recovery option would be to text the user a temporary one-time password or token to that number that they could use to verify their identity and move forward to resetting their password. 28. For C.3.5.2 - what platforms are most desirable / common for mobile support (for example, Android tablets, Android phones, IOS tablets, IOS phones, etc.), and is there a mobile device management (MDM) security layer available? If MDM is not available and an open BYOD policy is supported, what authentication standards are required by security policy? If an MDM is implemented, what is the scope (for example Faculty and Staff only). ios phones and tablets, Android phones and tablets, Windows mobile phones and tablets are the most common and desirable. There is no MDM layer. Wireless Network access is authenticated via LDAP by Bradford Impulse Point Network Access Control 29. Regarding C.4.1.1 - Beyond the listed directories (OpenLDAP, Kerberos, MySQL, Oracle, Linux (via listener API) and Google (via Java API)), are there any additional systems that would need integration within the PW Reset workflow? How are Linux PWs managed? Linux systems authenticate via Kerberos. MS Active Directory is also listed in C.4.1 and should be included HSU_IDM RFQ 03152013 Addendum 1.docx Page 9

30. For C.4.1.7 - Please list attributes required to manage contractor accounts within IdM, and list systems of reference which should be considered outputs (if any). dn: uid=xxx,cn=users,dc=humboldt,dc=edu uid: xxx uidnumber: xx departmentnumber: xx telephonenumber: xx gidnumber: xx calstateedupersonassurancelevel: 1 calstateedupersonorg: humboldt calstateedupersonprincipalname: xxx homedirectory: xxx userhomequota: xxx sn: Last Name givenname: First Name displayname: First Last Name cn: First Last Name mailhost: smtp server edupersonprimaryaffiliation: Contractor/Consultant calstateedupersonprimaryaffiliation: Contractor/Consultant humboldtedupersonidnumber: ID number humboldtedupersonoperid: xxxx calstateedupersonferpaflag: N edupersonaffiliation: Contractor calstateedupersonaffiliation: Contractor objectclass: inetorgperson objectclass: HSUPerson objectclass: person objectclass: eduperson objectclass: top objectclass: organizationalperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: HSU-Quota objectclass: hsuatistatus objectclass: calstateeduperson userpassword: hash HsuAccountLastUpdated: 201304020604 31. Regarding C.4.1.9 - Please document what is required and desirable for Eduperson and CalState Eduperson schema support. See Addendum 1 Exhibit A Person Affiliation Term Map and Addendum 1 Exhibit B calstateedu Attributes for a general overview of eduperson and Calstate Eduperson. HSU supports the first two levels moving from left to right on the map. Further detail is available at: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html 32. For C.4.1.18 - Please provide a link to documentation on CAS Single Sign On (including version implemented) and version details for your implementation of Shibboleth SSO. Are either of these extended into mobile operating systems and/or browsers? CAS is currently 3.4.11 http://www.jasig.org/cas. Shibboleth is currently shibboleth-identityprovider version 2.1.2 http://shibboleth.net/products/identity-provider.html. Both work with all mobile HSU_IDM RFQ 03152013 Addendum 1.docx Page 10

browsers we have tested with and both feed from OpenLDAP, so they should not need direct provisioning from the IDM system 33. Regarding C.4.2.1 - Please enumerate and describe the functional requirements preferred for the "election" function. Is this a secure survey type of application? Yes, elections function as a secure survey. A defined group (i.e. students or faculty) are presented with a survey where each office or position is a question and the nominated candidates are answers. Each member of that group can answer the survey once. 34. For C.4.2.5 - Is the expectation that the Vendor or University will be responsible for software distribution and support of Microsoft GINA extensions to AD bound computers? If Vendor responsibility, how many systems are in scope, and what OS versions should be supported? If GINA extensions are required, HSU would be responsible for distribution. Please specify in your response if this type of modification would be required for your solution. 35. Regarding C.4.2.6 - Does the requested functionality include performing SMS emergency notifications or just collecting numbers for a bulk notification system. If the expectation is for the IdM system to perform emergency notifications, what is the required performance (messages per second)? Just collecting numbers for a bulk notification system 36. How many environments are available of all target systems (for example DEV, TST, PRD)? Development and Production 37. So that we can factor in all software, directory and database interfaces necessary for implementation, what is the desired mean time to repair (MTR) and repair point objective (RPO) for the IdM system? What high-availability data center resources are available? The Identity Management System is considered mission critical, requiring 24/7 service. In the data center we have load balancers and a seven node VMWare cluster available. 38. If the proposed product is not VPAT compatible, is that an automatic exclusion from consideration? The Identity Management System will run in the background and is bassed on user passwords, authentication to AD, etc. Therefore we have not previously gone through the VPAT certification process as there is no interaction required from an end-user other than normal password input. Review of accessibility is required for all our purchases greater than $15,000. Should the product that most meets our functionality requirements not be accessible, we will be required to develop an equally effective alternative access method and will negotiate with the vendor to develop a roadmap to becoming fully accessible. Service password reset functionality needs to be accessible as this solution must be able to serve our disabled student population. Please see section B.5 (Compliance) in the RFQ for further details of the VPAT process. HSU_IDM RFQ 03152013 Addendum 1.docx Page 11

39. Will only providing one Higher Education reference be an automatic exclusion from consideration? Identity Management Systems are relatively new to the Higher Education Industry, therefore referencing two Higher Education references may be a challenge. There are many private sector references available. As noted in section B.3 (System Reference Accounts) of the RFQ, reference accounts must include at least two higher education accounts. 40. Item D.3 references an Acceptance Test. However there is no definition of what this test will entail, or the length of the test. Can vendor s propose a Proof of Concept versus an Acceptance Test? This will minimize risk for Humboldt as the POC would take place before the actual purchase of the Identity Management System. A proof of concept is already outlined in Section. A6 as part of the proposal process. The Acceptance Test mentioned in section D.3. is intended to be part of the sign off process after implementation by the selected vendor. 41. E1 Price Quote. Will Humboldt pay for the software and services based on key Milestones? ie Pay for the software at the beginning of the project and pay for the implementation, installation and training in phases? Yes, this will be formalized during contract negotiations with the selected vendor. While HSU has typically paid for any software licenses upon receipt and any consulting or training as the work is performed and invoiced in past IT contract, payments will be made based on the terms agreed to in this final contract and associated terms and conditions. If you have payment requirements or preferences, include them with your response to the RFQ. 42. It is our goal to create and negotiate mutually acceptable master product agreements (MPA) that our end customers can utilize for future orders. Vendor s MPA is specific to the provision of its software products & services and contains the necessary licensing terms and conditions related to product & services, therefore Vendor prefers to propose and negotiate its standard license/service terms and conditions. Is Humboldt willing to take into consideration Vendor s terms, provided such terms are modified accordingly to address customer s concerns or requirements? As noted in Section B.5 (Compliance) all contracts will be drawn to comply with both CRL063 CSU General Provisions for Information Technology Acquisitions and CSU Supplementary Provisions for Information Technology Acquisitions. Responding vendors are expected to return red-lined copies with their RFQ response, indicating any areas of question or suggested edits. You are welcome to also include a copy of your terms and conditions with your response. HSU_IDM RFQ 03152013 Addendum 1.docx Page 12

Exhibit A: Person Affiliation Term Map

Attribute Table - calstateeduperson schema RFQ #03152013 Exhibit B version 2006-10-26 OID (for calstateedu attributes) See Note 1 below attibute type multi-value description Multivalue list of attributes that can NOT be made available to the public. Values = all, meaning all attributes blocked, or a list of attribute names that are 1.3.6.1.4.1.10396.2.1.1.1 calstateedupersonrestrictflag required Y blocked 1.3.6.1.4.1.10396.2.1.1.2 calstateedupersonguid required N A globaly unique 128-bit number represented by a 32 hex character string. This number is a unique identifier for this directory entry, not a unique identifier for the person identified in this entry. See Note 2 below. 1.3.6.1.4.1.10396.2.1.1.3 (deleted) OID will not be re-used 1.3.6.1.4.1.10396.2.1.1.4 calstateedupersonaffiliation suggested Y Further refinement of edupersonaffiliation (values = foundation, retired, asi (associated students)) need more input, examples and hints on how to use these. This is a controlled list of values, that can be extended after further discussion. 1.3.6.1.4.1.10396.2.1.1.5 calstateedupersonmajor suggested Y Preferred name of the major to be used when displaying entries 1.3.6.1.4.1.10396.2.1.1.6 calstateedupersonmajorcode suggested Y CSU standard major codes 1.3.6.1.4.1.10396.2.1.1.7 calstateedupersonprimaryaffiliation suggested N Further refinement of edupersonprimaryaffiliation (values = foundation, retired, asi (associated students)) need more input, examples and hints on how to use these. This is a controlled list of values, that can be extended after further discussion. 1.3.6.1.4.1.10396.2.1.1.8 calstateedupersonstateid suggested N The California ID, a California Drivers License number is the same as a California ID. This can NOT be a state ID from another state. 1.3.6.1.4.1.10396.2.1.1.9 calstateedupersonlibraryid suggested N Library identification number assigned according to CSU Library standard 1.3.6.1.4.1.10396.2.1.1.10 calstateedupersonssn suggested N Social Security Number or Taxpayer ID Number 1.3.6.1.4.1.10396.2.1.1.11 calstateedupersonbirthdate suggested N Birth date (YYYYMMDD) e.g. 19881013 1.3.6.1.4.1.10396.2.1.1.12 calstateedupersonsystemid suggested N A ten character identifier assigned by the CSU system to identify an individual person. Any instance of identity for the same person in any CSU identity system will have the same unique calstateedupersonsystemid. cn required Y First name, suggested middle name or initials, last name, generation qualifier, no title displayname required N Preferred name of the person to be used when displaying entries edupersonaffiliation required Y Everyone is at least a (member or affiliate) member can also be employee, student, or alum employee can be faculty or staff edupersonorgdn required N The DN (in DC naming) of the campus givenname required N First Name mail required N Preferred address for the TO field of email to be sent to this person o required 2 Both long and short form of o sn required N Last name commuri suggested Y Labeled URI containing an LDAP URL identifying the directory containing the referenced commobject instance. See commobject specification. description suggested See description in eduperson (200604) edupersonentitlement suggested See description in eduperson (200604) edupersonnickname suggested See description in eduperson (200604) edupersonprimaryorgunitdn suggested See description in eduperson (200604) edupersonorgunitdn suggested See description in eduperson (200604) edupersonprimaryaffiliation suggested See description in eduperson (200604) edupersonprincipalname suggested See description in eduperson (200604) edupersonscopedaffiliation suggested See description in eduperson (200604) edupersontargetedid suggested See description in eduperson (200604) facsimiletelephonenumber suggested See description in eduperson (200604) initials suggested See description in eduperson (200604) jpegphoto suggested See description in eduperson (200604) l suggested See description in eduperson (200604) labeleduri suggested See description in eduperson (200604) manager suggested See description in eduperson (200604) mobile suggested See description in eduperson (200604) Page 1

Attribute Table - calstateeduperson schema RFQ #03152013 Exhibit B OID (for calstateedu attributes) See Note 1 below attibute type multi-value description ou suggested See description in eduperson (200604) pager suggested See description in eduperson (200604) postaladdress suggested See description in eduperson (200604) postalcode suggested See description in eduperson (200604) postofficebox suggested See description in eduperson (200604) preferredlanguage suggested See description in eduperson (200604) version 2006-10-26 roomnumber suggested Use this field to hold both building and room number secretary suggested See description in eduperson (200604) seealso suggested See description in eduperson (200604) st suggested See description in eduperson (200604) street suggested See description in eduperson (200604) telephonenumber suggested See description in eduperson (200604) Note international format. title suggested See description in eduperson (200604) uid suggested See description in eduperson (200604) userpassword deferred See description in eduperson (200604) usercertificate deferred See description in eduperson (200604) usersmimecertificate deferred See description in eduperson (200604) Note 1 Note 2 LDAP schema extensions require object identifiers (OID) and names for each of the new objectclasses and attributes. We recommend that each campus obtain an OID for use with their directory at http://www.iana.org/cgi-bin/enterprise.pl. The Chancellor s Office has obtained an OID (1.3.6.1.4.1.10396) for use with the common systemwide definitions. The Technical Architecture Group will manage the CSU system OID. The attribute, calstateedupersonguid, is a unique identifier for the directory instance in which it appears, not an identifier for the person whose identity is described. It is implemented as a time based Global UID (GUID). The algorithm used for generating the GUID guarantees uniqueness, even over time. The GUID is a 128-bit number represented by a 32 hex character string. An example of a GUID is: 7db589fe-9e65-11d5-bbfa-080009d2ae61. The GUID is not considered a string that a person is going to remember or even keep somewhere. It is primarily for use internally within applications. The algorithm for generating this identifier is based on the hardware address of the generating machine and the time in nano-seconds. It is recommended that campuses share best practices and/or implementations. A document explaining this algorithm can be found at http://www.ics.uci.edu/~ejw/authoring/uuid-guid/draftleach-uuids-guids-01.txt. Page 2

Attribute Table - calstateeduorg OID attribute type multi-value description l required N city o required 2 Both long and short form of o ou required HSU IDM RFQ #03152013 Exhibit B version 2002-12-10 postaladdress required full postal address with "$" to mark line breaks (Cal N Poly $ 1 Grand Avenue $ San Luis Obispo CA 93407) postalcode required N zip code st required N 2 letter state abreviation street required N street address telephonenumber required N "+1 888 555 1212 (no dashes)" cn suggested See eduorg (200210) description suggested See eduorg (200210) eduorghomepageuri suggested See eduorg (200210) eduorgidentityauthnpolicyuri suggested See eduorg (200210) eduorglegalname suggested See eduorg (200210) eduorgsuperioruri suggested See eduorg (200210) eduorgwhitepagesuri suggested See eduorg (200210) facsimiletelephonenumber suggested See eduorg (200210) postofficebox suggested See eduorg (200210) seealso suggested See eduorg (200210) Page 3