Skip to main content

Requirements to Coordinate Acquisition, Authentication and Security for Online Services to the University Community Which Are Hosted Either On Campus or Off Campus

Audience:

This policy applies to any members of the University community who provide personalized or authenticated online services where:

Definition:

Host – a computer or cluster of computers that deliver an online service to the University community.

Administration – An individual administers a host when he or she has primary, day-to-day, super-user privileges which grant him or her means to control the services on the host and to bypass security measures on the host.

On-campus host – a host which is located logically within the University IP networks and is administered only by University employees.

Mixed host – a host which is located logically within the University IP networks but is administered by an ASP with or without assistance from University employees.

Off-campus host – a host which is located logically outside of the University IP networks, regardless of its administration by University employees or an ASP.

Application Service Provider (ASP) – a company which, under contract, uses off-campus hosts or mixed host solutions to deliver an online service.

Sensitive information – personally-identifiable data which the University treats as internal and not public, or which is classified as protected under regulations. All sensitive information is administered by the University through a data steward.

Policy Statement:

All online services to the University community must be reviewed and approved by the Vice President for Information Technology and Chief Information Officer under the Policy for Information Technology Acquisition, Development and Deployment.

Authentication

Services delivered from mixed host or off-campus host configurations must be authenticated via NetID and password unless exempted by Northwestern University Information Technology (NUIT). On-campus or mixed host configurations must be authenticated via the NUIT Web SSO facility. Off-campus hosts must also be authenticated via the NUIT Web SSO facility and federated authentication or Web-proxy. No LDAP, Active Directory, or Kerberos services are available to off-campus hosts. Specific contract language, reviewed and approved by NUIT and the Office of General Counsel (OGC), should define the exact method of authentication to be used.

Security

The data steward and NUIT must review and approve, in advance, any plans to expose or transfer sensitive information to an ASP in either a mixed host or off-campus host configuration. Any transfer must be contractually protected as described in the Contract Language for the Secure Handling of Sensitive Data. In all cases, the sensitive information exposed to or stored upon an ASP-administered host will be limited to that pertaining to the exact set of actual users of the service. No mass transfer of sensitive information will be allowed to any host configuration (either, on-campus, mixed, or off-campus) unless (a) such transfer has been approved in advance by the data steward, NUIT and OGC, and (b) specific contract language clearly describes this requirement.

Notice of Right to Refuse Services and Block Implementation

NUIT has distributed this policy statement widely within the University and has posted it on the official policy Web site. Any University software or service project pursued in ignorance of this policy, or pursued without consultations that include NUIT and data stewards specific to the issues within this policy, can have no expectation of assistance from NUIT or data stewards. If a project is discovered to have made unwarranted assumptions at variance with this policy, then NUIT or a data steward will have the right to block implementation until the project is reviewed and brought into compliance. The project sponsor may appeal actions taken under this paragraph to the Enterprise System Executive Committee.

Background Issues:

Services may be delivered to the University community from mixed host or off-campus host configurations only upon the prior approval of NUIT under the Policy for Information Technology Acquisition, Development and Deployment. A portion of that approval process will include review of what University data is to be exposed to the ASP and stored at the ASP.

Information exposed to or stored by the ASP must be limited to information about only those persons who are actually using the service. This requires the ASP to employ “first-access provisioning” when a new user accesses the service. The University will not supply the ASP with a list of all possible users of the service.

Authentication to the service should use existing University credentials (NetID and other factors). For on-campus or mixed host configurations, this will use the Northwestern Web SSO facility via Web server plug-in software and appropriate credentials issued by NUIT. For off-campus host configurations, this will use federated authentication or Web-proxy. Note that Web-proxy authentication does not provide attribute information about the user other than NetID. Federated authentication can pass additional attributes as agreed between the University and the ASP in the service contract. Access to any user attributes must be reviewed and approved by the relevant data steward and NUIT through current administrative processes.

Off-campus host configurations cannot access Northwestern information based in LDAP, Active Directory, or Kerberos authentication services. Therefore, additional attribute information, such as name or e-mail address, cannot be retrieved except through federated authentication protocols.

The requirements set forth in this policy should be conveyed to potential vendors while investigating possible solutions so that those vendors may propose any necessary costs for compliance as a portion of the project expense.

Any cost of compliance with this policy is borne by the service provider. This could include:

Service providers should minimize these costs by including NUIT in conversations with prospective vendors, conveying this policy to the vendors, and incorporating this policy in any contract.

Policy Review Date:

December 2016

July 2012

Original Issue Date:

December 2006

Revision Dates:

July 2012
May 2007

Related Policies: Back to top