XSEDE Usage Policy
All XSEDE service provider sites have legal and other obligations to protect shared resources as well as the intellectual property of users. Users share this responsibility by observing the rules of acceptable use that are outlined in this document.
How to Accept Your Responsibility Form
When XSEDE approves your request for resources, you must digitally sign the XSEDE Acceptable Use Policy the first time you log into the XSEDE User Portal at the beginning of each allocation. You must do this within 30 days of the approval of your allocation, or your account will be deactivated.
Your on-line acceptance is your acknowledgment that you have read and understand your responsibilities as a user. If you have questions, please contact the XSEDE Help Desk.
XSEDE Acceptable Use Policy
By using resources associated with an XSEDE allocation, you agree to comply with the following conditions of use:
You will only use XSEDE-allocated resources to perform work and transmit/ store data consistent with the stated allocation request goals and conditions of use as defined by your approved XSEDE project, this XSEDE Acceptable Use Policy (AUP), and any local service provider policies.
XSEDE allocations are awarded for open research intended for publication, but you will respect intellectual property rights and observe confidentiality agreements.
You will not use XSEDE-allocated resources for unauthorized financial gain or any unlawful purpose, nor attempt to breach or circumvent any XSEDE administrative or security controls. You will comply with all applicable laws, working with your home institution and the specific XSEDE service providers utilized to determine what constraints may be placed on you by any relevant regulations such as export control law or HIPAA.
You will protect your access credentials (e.g., private keys, tokens & passwords) which are issued for your sole use. This includes:
Using a unique password for your XSEDE User Portal account
Only entering your XSEDE password into xsede.org sites
Not knowingly allowing any other person to impersonate your XSEDE user identity
You will immediately report any known or suspected security breach or misuse of XSEDE access credentials to the XSEDE Help Desk (firstname.lastname@example.org; https://portal.xsede.org/help-desk; or 1-866-907-2383).
Access-granting organizations, your allocation's Principal Investigator (PI), and service providersare entitled to regulate, suspend or terminate your access, and you will immediately comply with their instructions.
PIs are responsible for properly vetting users on their allocations and by doing so they are attesting that the XSEDE User Portal username belongs to the intended person. PI's will also ensure that users who have access to XSEDE-allocated resources on the PI's XSEDE allocation follow this AUP.
You will have only one XSEDE User Portal account and will keep your profile information up-to-date.
Use of resources and services through XSEDE is at your own risk. There are no guarantees that resources and services will be available, that they will suit every purpose, or that data will never be lost or corrupted. Users are responsible for backing up critical data.
Logged information, including information provided by you for registration purposes, is used for administrative, operational, accounting, monitoring and security purposes. This information may be disclosed, via secured mechanisms, only for the same purposes and only as far as necessary to other organizations cooperating with XSEDE.
You will acknowledge use of XSEDE, supported by National Science Foundation award number OCI-1053575, in manuscripts submitted for publication. In addition, you are expected to acknowledge use of the specific resource(s) utilized (See http://portal.xsede.org/acknowledge).
Violations of XSEDE policies and/or service provider policies can result in loss of access to resources. Activities in violation of any laws may be reported to the proper authorities for investigation and prosecution.
XSEDE uses Globus services. You agree to the Globus Terms of Service (https://www.globus.org/legal/terms).
Version 1.3 (Feb 29, 2016)
If you suspect a security incident, or if your account has been compromised, please contact the XSEDE Help Desk immediately to report a security incident.
For other security issues, contact email@example.com
Current XSEDE Security Documents
- XSEDE Certificate Service (Get an SSL server cert)
- Incommon Federation: Participant Operational Practices
- XSEDE-approved CA certificates, signing policies, and CRL URLs [Download] [PGP signature(s) for download]
- XSEDE Security Working Group Charter
- XSEDE Security Playbook
- XSEDE Enterprise Services Baseline Security Standard
- XSEDE Science Gateway Security Policy & Guideline
- XSEDE Acceptable Use Policy
- XSEDE Resources SSH Keys
- XSEDE Level1 Service Provider Security Agreement
- XSEDE Security Working Group Service Provider (SP) Guide & FAQ
- XSEDE Information Security Training for XSEDE Researchers
Currently Accepted Certificate Authorities
|CA WEPAGE||CA CONTACT||XSEDE TRUSTED SUBJECT DN'S|
|INFN (Italy)||firstname.lastname@example.org|| |
|NCSAemail@example.com|| " |
|UK e-Sciencefirstname.lastname@example.org|| |
As of July 2014, XSEDE uses the InCommon Certificate Service to provide SSL certificates for web and grid-based servers in the *.xsede.org domain. (If your server is in a different domain or you need a certificate for Globus "strict mode", look at Domains Other than xsede.org for possible help.) There are several types of SSL certificates available, described below.
But first, consider if you even need an XSEDE SSL server certificate. If you are simply transferring data between servers, you can use Globus Connect Multiuser (part of Globus Connect Server) which does not require server certificates. If you need a user certificate rather than a server certificate, use the XSEDE SSO Login Hub.
SSL Certificate Types
XSEDE provides several types of SSL certificates for servers in the *.xsede.org domain. Read the descriptions below to help you decide which type of server certificate you need. Note that for all certificate types, the default is to generate certificates with the SHA-2 algorithm. This is due to vulnerabilities found in the SHA-1 algorithm.
1. InCommon SSL Certificate
The InCommon SSL Certificate is a "standard" SSL server certificate for use with web servers. The certificate secures a single domain (e.g. foo.xsede.org), and can have a lifetime of 1, 2, or 3 years.
2. InCommon Wildcard SSL Certificate
The InCommon Wildcard SSL Certificate is a wildcard certificate for use with web servers. The certificate secures all hosts in a single subdomain level (e.g., *.foo.xsede.org), and can have a lifetime of 1, 2, or 3 years. Note that there are limitations with these wildcard certificates. They cannot be used to secure the base domain (e.g. foo.xsede.org) or deeper level subdomains (e.g. host.bar.foo.xsede.org). If these limitations apply to you, consider the InCommon Multi Domain SSL Certificate instead.
3. InCommon Multi Domain SSL Certificate
The InCommon Multi Domain SSL Certificate is for use with web servers on multiple domains. This is accomplished by specifying additional hostnames in the SubjectAltName (SAN) field of the SSL certificate. Up to 99 additional domains can be specified and secured by a single InCommon Multi Domain SSL Certificate. The certificate can have a lifetime of 1, 2, or 3 years.
4. IGTF Server Certificate
The IGTF Server Certificate is used primarily to secure a single server in HPC and grid computing environments. These certificates have a lifetime of 1 year. While these certificates can be used for web servers, their primary purpose is securing IGTF grid servers (e.g., GridFTP, GSISSH, GRAM, UNICORE). These certificates do not support wildcards or multiple domains.
5. IGTF Multi Domain Certificate
The IGTF Multi Domain Certificate is new for 2016. It is similar to the IGTF Server Certificate, but it allows for multiple domains by specifying additional hostnames in the SubjectAltName (SAN) field of the SSL certificate. Up to 99 additional domains can be specified and secured by a single IGTF Multi Domain Certificate. The certificate has a lifetime of 1 year.
|CERTIFICATE TYPE||AUDIENCE||NUMBER OF HOSTS||MAX LIFETIME|
| InCommon SSL |
|Web Server||1||3 Years|
| InCommon Wildcard |
|Web Server|| Any (1 subdomain |
| InCommon Multi |
Domain SSL Cert
|Web Server||Up to 100||3 Years|
| ITGF Server |
| HPC / Grid |
| ITGF Multi Domain |
| HPC / Grid |
|Up to 100||1 Year|
Once you have decided on a certificate type for your server, you need to generate a Certificate Signing Request (CSR).