...
It’s possible that ambitious IDP operators from organizations you serve will want to set up single logout. When a user logs out of one service and is sent to the IDP’s logout URL, the IDP will try to destroy sessions from other services that the user accessed during that IDP session. This method is far from perfect, but for it to even be remotely successful, SPs must be able to support these single logout requests from an IDP. In reality, few IDPs use single logout because of technical implications and the over-all user education associated with it. Supporting it on your service is a relatively easy task, though, if you already support logout locally, and it adds value for those few IDPs that want to utilize it.
Policy and Compliance
This section covers topics that are of special interest to Higher Education, and it is assumed that the Identity Provider is being operated by a school that must comply with The Family Educational Rights and Privacy Act (FERPA).
FERPA
Although Identity Providers at Higher Education institutions are likely familiar with the following information, this section contains guidance specific to cloud service integration. It may also be of special interest to cloud service providers who do not have significant experience working in the Higher Education sector and who may receive attributes from Identity Providers that is considered to be FERPA protected by the school releasing the data. That this is not to be considered legal advice, but rather a brief and general overview of FERPA.
Overview
FERPA is a federal law intended to protect the privacy of student education records. All schools that receive funds under an applicable US Department of Education program are required to comply with the law (http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html)
FERPA classifies information into two categories:
- Educational Records
- Directory Information
FERPA requires institutions that make directory information publicly available, such as in an online directory or institutional white pages, to publicly define the information classified as such, and that a reasonable amount of time be given after that notice for the owner of the data to request that it not be released.
When personal information is transferred to a third party, such as a Service Provider, it must be on the condition that the information will not be disclosed to any other party without written consent of the individual considered by FERPA to be the owner of the record: the parent or student, depending on the student's age (http://www.law.cornell.edu/uscode/text/20/1232g).
The language of FERPA will be interpreted by each schools legal council and so attributes classified as Directory Information and mechanisms for compliance will differ from school to school.
Campus: DO work with data owners to consider a default release policy.
Much of the information of interest to SPs is the kind of information that many institutions historically have classified as Directory Information under FERPA. In the case of public institutions, much of this data is often considered public record for employees (allowing that this varies by state). While releasing this data as part of authentication is not the same as hosting it in a directory, it is also not materially different, and arguably constitutes a more controlled release of data at the discretion of the data subject.
InCommon members should consider the adoption of policies to release Directory Information attributes to federation services on at least some ad hoc basis. The Research and Scholarship program is an alternative to federation-wide policies and may also be of interest. Work with data owners such as the HR department and Registrar (or others as appropriate) to establish consensus about the appropriate policy to use for default release.
Recognize that a default-deny policy will act to inherently limit the value provided by an IdP, though it will likely decrease ongoing support costs. Make these decisions deliberately.
Campus: CONSIDER a user consent mechanism for attribute release.
Consider a consent-based approach to provide user control of data release. Many federation products include functionality, or support add-ons, to support user consent to the release of data to services. A consent process may be a good way of expanding the reach of an IdP by enabling users to make the decision about whether to release data, in lieu of requiring contracts for every individual service a user might access. Consent systems also provide an auditable record of approvals, and can help address a requirement for acceptance of usage terms.
Note that consent approaches have limits. They should never be used if a student or employees failure to consent would bar them from a service they are required to use, nor do they work well for attributes beyond a user's capability to understand.
A typical consent UI should be able to identify the relevant service, and attributes, concisely. InCommon membership, and the use of SAML metadata, provides a good source of reliable information to use in driving such a UI.
Campus: DO establish procedures for managing the release of restricted data.
Some cloud services will inevitably need access to restricted or sensitive data, so be prepared for this by working with policy makers to establish a process for all involved to follow. Requiring participation in a federation that follows current best practice in the identity federation space may facilitate the contract review process by covering some of the basic expectations regarding use of data and disclosure to third parties.
Campus: CONSIDER that cloud services may solicit additional identity data directly from users.
Even if only a small amount of data is provided via an IdP to a cloud service (even as little as an opaque identifier like the eduPersonTargetedID attribute), users may be prompted to fill in a user profile within the service that includes additional personal information. FERPA may be implicated if the use of a service is mandatory and the additional data is required.
HIPAA
This section covers the Health Insurance Portability and Accountability Act (HIPAA), which is a law intended to protect the privacy of individual's healthcare information while allowing for the flow of health information necessary to provide healthcare services and to protect the nations overall public health. Like the previous section of FERPA this is not legal advice, but provides general guidance to be considered by campuses and cloud service providers that offer services that may be used to store HIPAA protected data.
Campus: DO require that cloud service providers sign a Business Associates Agreement (BAA) if it is intended to be used with HIPAA protected data.
HIPAA's provisions for Business Associates Agreement is particularly important in regards to the use of cloud services that a campus intends to use to store protected data. A "Business Associate" is generally defined as a entity "... that performs certain functions or activities on behalf of, or provides certain services to, a covered entity that involve the use or disclosure of individually identifiable health information." (http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/)
Sample language is provided by the US Department of Health and Human Services: http://www.hhs.gov/ocr/privacy/hipaa/understanding/coverdentities/contractprov.html
Campus: CONSIDER requiring all data covered by a BAA be contained within the borders of the United States.
Discussion
It is possible that a vendor of cloud applications will store your institutional data in a data center that is located outside of the United States. Under such circumstances the data may be accessible to the foreign government of the country where the data is physically located.
Campus: CONSIDER requiring that cloud services who store communications and data sign a BAA.
Discussion
Even if institutional policy forbids sending or storing HIPAA protected in a cloud service, such a policy may not be sufficient to prevent the use of a cloud service for such purposes. Email and file storage services may be of particular concern. If the cloud provider is able to sign a BAA that could mitigate any exposure by the institution's members to that particular vendor.
Data Stewardship
Campus: DO protect your identity data.
After you release user attributes to a service, that data is no longer under your control. The service may not own the data, but they’re responsible for applying needed safeguards for how the data is used, stored, and accessed. Before an identity provider releases anything to a service, they should know about the service’s practices and security measures. In many cases, a federation’s operating agreement may address this issue. If not, or if the service isn’t a member of a federation, make sure to get satisfactory, up front answers on how your identity data will be stored and used.
Campus: DO articulate a strategy for dealing with the difference between institutional and personal user data.
Most cloud services house some kind of user data, and of course this is particularly true for applications that provide collaboration and file storage service. Many higher ed users will use cloud service accounts to store a mix of personal and institutional data. For example, a faculty member may have research work, family photographs, and departmental policy documents, all under a single account. If the user were to leave the university, the family photos and (probably) the research files would rightfully leave with the user, but the policy files should stay with the user's department. Untangling these document collections can be very time consuming, and lead to both institutional data loss and serious de-provisioning complexities.
Before launching a new cloud service, take some time to think through how users will store data on the service, and whether or not the service is prone to encourage the mixing of personal and institutional data. If so, do develop a strategy for dealing with this problem before the service goes live to your campus. In some cases providing a best practice guide may be the best solution. For other services you may want to consider leveraging a groups service or creating shared or non-personal service accounts that can be used to store data that should stay with the institution when an individual leaves their job.
Campus: DO publish a list of approved data types for your cloud services.
When a new cloud service goes live, the first question that many campus users will ask is, "What kind of data can I store on this service?" Consider publishing an approved data types chart that lists the institution's cloud services plus the approved data types for each service vendor. Note that local or regional laws may apply either based on particular kinds of activity (e.g., FERPA, HIPPA and some data localisation rules in Europe, e.g., on financial and medical), or on particular kinds of data (e.g., personal data in Europe). These laws may touch on a variety of aspects to cloud services, including their physical location, security, data retention policies, applicable jurisdiction, data portability, etc. You data classification policy should include enough categories to be useful, but not some many that the chart becomes cumbersome or confusing to your users.
Campus: DO manage data sensitivity and stewardship concerns from day one, and don't underestimate the potential impact to project scope.
This is another "look before you leap" recommendation. It's important to identify the data stewardship and compliance stakeholders on your campus at the beginning of your deployment project, bring them into your project team, and budget time for identifying approved data types as well as areas of concern that may need to be mitigated.
Data Stewardship
Responsibility for the information being shared between a campus and a service provider continues past the initial authentication and (if applicable) authorization transaction. While specific legal and policy guidelines may vary between countries or regions, some basic best practices will always apply.
Campus: DO protect your identity data.
After you release user attributes to a service, that data is no longer under your control. The service may not own the data, but they’re responsible for applying needed safeguards for how the data is used, stored, and accessed. Before an identity provider releases anything to a service, they should know about the service’s practices and security measures. In many cases, a federation’s operating agreement may address this issue. If not, or if the service isn’t a member of a federation, make sure to get satisfactory, up front answers on how your identity data will be stored and used.
Campus: DO articulate a strategy for dealing with the difference between institutional and personal user data.
Most cloud services house some kind of user data, and of course this is particularly true for applications that provide collaboration and file storage service. Many higher ed users will use cloud service accounts to store a mix of personal and institutional data. For example, a faculty member may have research work, family photographs, and departmental policy documents, all under a single account. If the user were to leave the university, the family photos and (probably) the research files would rightfully leave with the user, but the policy files should stay with the user's department. Untangling these document collections can be very time consuming, and lead to both institutional data loss and serious de-provisioning complexities.
Before launching a new cloud service, take some time to think through how users will store data on the service, and whether or not the service is prone to encourage the mixing of personal and institutional data. If so, do develop a strategy for dealing with this problem before the service goes live to your campus. In some cases providing a best practice guide may be the best solution. For other services you may want to consider leveraging a groups service or creating shared or non-personal service accounts that can be used to store data that should stay with the institution when an individual leaves their job.
Campus: DO publish a list of approved data types for your cloud services.
When a new cloud service goes live, the first question that many campus users will ask is, "What kind of data can I store on this service?" Consider publishing an approved data types chart that lists the institution's cloud services plus the approved data types for each service vendor. Note that local or regional laws may apply either based on particular kinds of activity (e.g., FERPA, HIPPA and some data localisation rules in Europe, e.g., on financial and medical), or on particular kinds of data (e.g., personal data in Europe). These laws may touch on a variety of aspects to cloud services, including their physical location, security, data retention policies, applicable jurisdiction, data portability, etc. You data classification policy should include enough categories to be useful, but not some many that the chart becomes cumbersome or confusing to your users.
Campus: DO manage data sensitivity and stewardship concerns from day one, and don't underestimate the potential impact to project scope.
This is another "look before you leap" recommendation. It's important to identify the data stewardship and compliance stakeholders on your campus at the beginning of your deployment project, bring them into your project team, and budget time for identifying approved data types as well as areas of concern that may need to be mitigated.
Appendix: US Policy and Compliance
This section covers topics that are of special interest to Higher Education, and it is assumed that the Identity Provider is being operated by a school that must comply with The Family Educational Rights and Privacy Act (FERPA).
FERPA
Although Identity Providers at Higher Education institutions are likely familiar with the following information, this section contains guidance specific to cloud service integration. It may also be of special interest to cloud service providers who do not have significant experience working in the Higher Education sector and who may receive attributes from Identity Providers that is considered to be FERPA protected by the school releasing the data. That this is not to be considered legal advice, but rather a brief and general overview of FERPA.
Overview
FERPA is a federal law intended to protect the privacy of student education records. All schools that receive funds under an applicable US Department of Education program are required to comply with the law (http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html)
FERPA classifies information into two categories:
- Educational Records
- Directory Information
FERPA requires institutions that make directory information publicly available, such as in an online directory or institutional white pages, to publicly define the information classified as such, and that a reasonable amount of time be given after that notice for the owner of the data to request that it not be released.
When personal information is transferred to a third party, such as a Service Provider, it must be on the condition that the information will not be disclosed to any other party without written consent of the individual considered by FERPA to be the owner of the record: the parent or student, depending on the student's age (http://www.law.cornell.edu/uscode/text/20/1232g).
The language of FERPA will be interpreted by each schools legal council and so attributes classified as Directory Information and mechanisms for compliance will differ from school to school.
Campus: DO work with data owners to consider a default release policy.
Much of the information of interest to SPs is the kind of information that many institutions historically have classified as Directory Information under FERPA. In the case of public institutions, much of this data is often considered public record for employees (allowing that this varies by state). While releasing this data as part of authentication is not the same as hosting it in a directory, it is also not materially different, and arguably constitutes a more controlled release of data at the discretion of the data subject.
InCommon members should consider the adoption of policies to release Directory Information attributes to federation services on at least some ad hoc basis. The Research and Scholarship program is an alternative to federation-wide policies and may also be of interest. Work with data owners such as the HR department and Registrar (or others as appropriate) to establish consensus about the appropriate policy to use for default release.
Recognize that a default-deny policy will act to inherently limit the value provided by an IdP, though it will likely decrease ongoing support costs. Make these decisions deliberately.
Campus: CONSIDER a user consent mechanism for attribute release.
Consider a consent-based approach to provide user control of data release. Many federation products include functionality, or support add-ons, to support user consent to the release of data to services. A consent process may be a good way of expanding the reach of an IdP by enabling users to make the decision about whether to release data, in lieu of requiring contracts for every individual service a user might access. Consent systems also provide an auditable record of approvals, and can help address a requirement for acceptance of usage terms.
Note that consent approaches have limits. They should never be used if a student or employees failure to consent would bar them from a service they are required to use, nor do they work well for attributes beyond a user's capability to understand.
A typical consent UI should be able to identify the relevant service, and attributes, concisely. InCommon membership, and the use of SAML metadata, provides a good source of reliable information to use in driving such a UI.
Campus: DO establish procedures for managing the release of restricted data.
Some cloud services will inevitably need access to restricted or sensitive data, so be prepared for this by working with policy makers to establish a process for all involved to follow. Requiring participation in a federation that follows current best practice in the identity federation space may facilitate the contract review process by covering some of the basic expectations regarding use of data and disclosure to third parties.
Campus: CONSIDER that cloud services may solicit additional identity data directly from users.
Even if only a small amount of data is provided via an IdP to a cloud service (even as little as an opaque identifier like the eduPersonTargetedID attribute), users may be prompted to fill in a user profile within the service that includes additional personal information. FERPA may be implicated if the use of a service is mandatory and the additional data is required.
HIPAA
This section covers the Health Insurance Portability and Accountability Act (HIPAA), which is a law intended to protect the privacy of individual's healthcare information while allowing for the flow of health information necessary to provide healthcare services and to protect the nations overall public health. Like the previous section of FERPA this is not legal advice, but provides general guidance to be considered by campuses and cloud service providers that offer services that may be used to store HIPAA protected data.
Campus: DO require that cloud service providers sign a Business Associates Agreement (BAA) if it is intended to be used with HIPAA protected data.
HIPAA's provisions for Business Associates Agreement is particularly important in regards to the use of cloud services that a campus intends to use to store protected data. A "Business Associate" is generally defined as a entity "... that performs certain functions or activities on behalf of, or provides certain services to, a covered entity that involve the use or disclosure of individually identifiable health information." (http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/)
Sample language is provided by the US Department of Health and Human Services: http://www.hhs.gov/ocr/privacy/hipaa/understanding/coverdentities/contractprov.html
Campus: CONSIDER requiring all data covered by a BAA be contained within the borders of the United States.
Discussion
It is possible that a vendor of cloud applications will store your institutional data in a data center that is located outside of the United States. Under such circumstances the data may be accessible to the foreign government of the country where the data is physically located.
Campus: CONSIDER requiring that cloud services who store communications and data sign a BAA.
Discussion
Even if institutional policy forbids sending or storing HIPAA protected in a cloud service, such a policy may not be sufficient to prevent the use of a cloud service for such purposes. Email and file storage services may be of particular concern. If the cloud provider is able to sign a BAA that could mitigate any exposure by the institution's members to that particular vendor.
Summary Guidelines and Principles for Integration with Cloud Service Providers
Appendix: Identifier Properties
...