Content with tag security .

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:

  1. 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.

  2. XSEDE allocations are awarded for open research intended for publication, but you will respect intellectual property rights and observe confidentiality agreements.

  3. 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.

  4. You will protect your access credentials (e.g., private keys, tokens & passwords) which are issued for your sole use. This includes:

    1. Using a unique password for your XSEDE User Portal account

    2. Only entering your XSEDE password into xsede.org sites

    3. Not knowingly allowing any other person to impersonate your XSEDE user identity

  5. You will immediately report any known or suspected security breach or misuse of XSEDE access credentials to the XSEDE Help Desk (help@xsede.org; https://portal.xsede.org/help-desk; or 1-866-907-2383).

  6. 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.

  7. 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.

  8. You will have only one XSEDE User Portal account and will keep your profile information up-to-date.

  9. 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.

  10. 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.

  11. 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).

  12. 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.

  13. XSEDE uses Globus services. You agree to the Globus Terms of Service (https://www.globus.org/legal/terms).

Version 1.3 (Feb 29, 2016)

Key Points
Contact Information

Security

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 security-lead@xsede.org

Current XSEDE Security Documents

 

 

 

Currently Accepted Certificate Authorities

CA WEPAGE CA CONTACT XSEDE TRUSTED SUBJECT DN'S
AddTrust-External-CA-Root tcs-pma@terena.org "/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root"
CERN-GridCA cern-ca-managers@cern.ch "/DC=ch/DC=cern/CN=CERN Grid Certification Authority"
CERN-Root-2 cern-ca-managers@cern.ch "/C=ch/O=CERN/CN=CERN Root Certification Authority 2"
CILogon ca@cilogon.org "/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Basic CA 1" "/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon Silver CA 1"
CILogon-OSG goc@opensciencegrid.org "/DC=org/DC=cilogon/C=US/O=CILogon/CN=CILogon OSG CA 1"
COMODO-RSA-CA admin@incommon.org "/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority"
DFN-GridGermany-Root dfnpca@dfn-cert.de "/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Grid - G01"
DigiCert support@DigiCert.com "/DC=com/DC=DigiCert-Grid/O=DigiCert Grid/CN=DigiCert Grid Root CA"
"/C=US/O=DigiCert Grid/OU=www.digicert.com/CN=DigiCert Grid Trust CA"
"/DC=com/DC=DigiCert-Grid/O=DigiCert Grid/CN=DigiCert Grid CA-1"
"/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA"
InCommon help@xsede.org "/C=US/O=Internet2/OU=InCommon/CN=InCommon IGTF Server CA"
"/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority"
"/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root"
INFN (Italy) infn-ca@fi.infn.it "/C=IT/O=INFN/CN=INFN CA"
KEK Takashi.Sasaki@kek.jp "/C=JP/O=KEK/OU=CRC/CN=KEK GRID Certificate Authority"
NCSA ca-admin@ncsa.uiuc.edu "/C=US/O=National Center for Supercomputing Applications/OU=Certificate Authorities/CN=MyProxy CA 2013"
"/C=US/O=National Center for Supercomputing Applications/OU=Certificate Authorities/CN=Two Factor CA 2013"
NERSC certs@nersc.gov "/DC=net/DC=ES/OU=Certificate Authorities/CN=NERSC Online CA"
IRISGrid pkirisgrid-ca@rediris.es "/DC=es/DC=irisgrid/CN=IRISGridCA"
PSC ca-admin@psc.edu "/C=US/O=Pittsburgh Supercomputing Center/CN=PSC MyProxy CA"
UK e-Science ca-manager@grid-support.ac.uk "/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA 2B"
"/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root"

 

Key Points
Report any suspected security incidents to the XSEDE Help Desk
Contact Information

XSEDE Certificates

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.

Summary

CERTIFICATE TYPE AUDIENCE NUMBER OF HOSTS MAX LIFETIME
InCommon SSL
Certificate
Web Server 1 3 Years
InCommon Wildcard
SSL Certificate
Web Server Any (1 subdomain
only)
3 Years
InCommon Multi
Domain SSL Cert
Web Server Up to 100 3 Years
ITGF Server
Certificate
HPC / Grid
Server
1 1 Year
ITGF Multi Domain
Certificate
HPC / Grid
Server
Up to 100 1 Year

Next Step

Once you have decided on a certificate type for your server, you need to generate a Certificate Signing Request (CSR).

Key Points
Use this only for host certificate requests for the xsede.org domain.
Your local institution, if an InCommon member, should be able to issue IGTF-accredited certificates for your insitution's domain.
XSEDE does not issue long term user certificates.
XSEDE issued host certificates are for XSEDE Enterprise Services and XSEDE allocated resources.
Contact Information