Roar Policies

Authentication and Access Control Policy (Roar Supercomputer)

1.0 Overview

The Roar supercomputer is Penn State’s high performance research cloud. The Roar supercomputer is a balanced allocation of highly available infrastructure resources with complimentary services that are provided by ICDS.

2.0 Purpose

The purpose of ICDS-ACI-P030 is to establish policy for the lifecycle management of ICDS accounts that are created under the current state and configuration of Roar, in concurrence with the latest revision of this document. By requesting a Roar user account, users acknowledge that they have read and understand all Roar guidelines and applicable Penn State policies and agree to abide by said policies.

3.0 Professional Acknowledgement

Users are also asked to acknowledge their use of Roar resources in resulting publications and reports with the following statement:

This research or portions of this research were conducted with Advanced CyberInfrastructure computational resources provided by The Institute for Computational and Data Sciences at The Pennsylvania State University (

4.0 Scope

ICDS-ACI-P030 details the criteria for creating a Roar account, using a user account, and terminating a user account. This guideline exists to ensure fair and equitable access to Roar. Use of the Roar supercomputer is restricted to facilitating research within the University or other function(s) pre-approved by the ICDS Director. Anyone violating these guidelines is subject to suspension and/or termination of their Roar account. ICDS-ACI-P030 applies to any person with a Roar account, regardless of Penn State affiliation, as well as anyone who sponsors an individual with a Roar account. In the absence of specific Roar guidelines and policies, Penn State policies apply. ICDS-ACI-P030 augments the following Penn State policies:

  • AD11 – University Policy on Confidentiality of Student Records
  • AD95 – Information Assurance and IT Security (formerly AD20)
  • AD23 – Use of Institutional Data
  • ADG01 – Glossary of Computerized Data and System Terminology
  • ADG02 – Computer Facility Security
  • HR102 – Separation and Transfer Protocol

5.0 Guidelines

5.1 Roar Accounts

Roar accounts are composed of user categories as described in the table below:

User Category


Principal Investigator (PI)

A Penn State faculty sponsor typically leading a research effort. PIs may sponsor any number of accounts, but these accounts must be used for research only. PIs are responsible for all of their sponsored account users. These accounts are subject to periodic review and will have to be renewed if the sponsoring faculty or the account holders change their University affiliation or fail to comply with Penn State or Roar account policies. All user accounts will be assigned resources and job priority based on the allocations and priorities of their sponsoring PI. Roar User IDs are based on the PI’s Penn State Access ID.


Any graduate student, undergraduate student, postdoc, or other researcher supporting a PI’s research. Roar User IDs are based on Penn State Access IDs.


Any Penn State employee supporting a PI’s research. Roar User IDs are based on the employee’s Penn State Access ID.

Sponsored Guests

A person supporting a PI’s research who is not already affiliated with Penn State University and who works closely with a PI. Roar User IDs are based on the sponsored guest’s Penn State Sponsored Access Account ID. Sponsored Access Accounts may be requested through ITS Accounts Office.

5.2 Roar Account Requests

Roar accounts are available through an account request process (ref. section 8.2 Workflow diagram). The accounts are governed by the following requirements for all users and sponsors:

5.2.1 Users

  • Roar accounts are available to Penn State faculty, students, postdocs, staff, and guests already having a University access ID. Guests must first secure a Sponsored Access Account from Penn State’s ITS Accounts Office to obtain a University access ID
  • Roar User Accounts for Penn State students, postdocs, staff, and guests require a faculty sponsor (reference section 5.2.2, Sponsors)
  • New users must submit a completed online Account Request form for an Roar account:
    • The account request form may be accessed directly via Penn State Web Access or via the ICDS web site and selecting “Request an Roar Account”
    • Roar User Account requests are processed through the i-ASK Center. Please contact iASK Center staff at for assistance with requests if necessary
  • Additional approvers may be required as necessary depending upon the details provided in the account request (e.g. computational and data requirements that span multiple departments)
  • The account holder and their sponsor will be notified via email that the account request has been processed and an account has been created (or denied)
  • Users are responsible for promptly notifying Roar via email to if they are leaving Penn State or otherwise lose affiliation with Penn State
  • Users are responsible for promptly notifying Roar via email to if their sponsor needs to be changed (e.g. sponsor leaves or otherwise loses affiliation with Penn State)
  • Users may be asked periodically by Roar to renew their account
  • Users and their sponsors will be notified when their account has violated Roar or Penn State policy. Actions, including termination of the account, may be taken at the discretion of Roar account managers. Please reference section 6.0 Enforcement later in this document.
  • By providing your email address, you are subscribing to the Institute for Computational and Data Sciences news feed and will receive occasional emails with useful information about funding, training, and other opportunities. If you do not wish to receive the ICDS news feed, you may unsubscribe yourself.

5.2.2 Sponsors

  • Accounts must be sponsored by Penn State faculty or other Penn State staff who have been preapproved as sponsors by ICDS. Sponsors are herein referred to as a Principal Investigator (PI). PIs are responsible to oversee use of ALL sponsored accounts
  • A PI can sponsor multiple users, and users can be sponsored by multiple PIs
  • Account requests will be verified with the associated PI
  • Account sponsors are responsible for promptly notifying Roar via email to if they cannot fulfill their duties as a sponsor (e.g. due to leave of absence from Penn State or loss of affiliation with Penn State)
  • Account sponsors are responsible for promptly notifying Roar via email to if any of their sponsored accounts should be terminated (e.g. a sponsored user leaves Penn State)
  • PIs may be asked periodically by Roar to review the accounts that they sponsor and notify Roar via email to of any changes
  • PIs will be notified when an account that they sponsor has violated Roar or Penn State policy. Actions, including termination of the sponsored account, may be taken at the discretion of Roar account managers. Please reference section 6.0 Enforcement later in this policy.
  • PIs are responsible for oversight of accounts that they sponsor. Sponsored accounts that violate policy are subject to termination of all of a PI’s sponsored accounts, including their own

5.2.3 Advanced Users

  • All user accounts must operate under the principle of “least privilege” to ensure that processes operate at privilege levels no higher than are necessary to accomplish required functions
  • Users may request an exception to have elevated permissions on Roar instances to accomplish legitimate research needs. Approval is at the discretion of ICDS
  • Users with the capability for elevated permissions are not permitted to enable elevated permissions for other accounts.

5.3 Account Administration

All account requests, modifications, and related communications will be archived based upon audit record storage requirements of the Institute for Computational and Data Sciences.

5.4 Account Attributes

Accounts are configured with the following attributes and associated data storage options:

Attribute Description
Account Name Penn State employee/student ID or Sponsored Access Account User ID
Systems Access Dependent upon the PI’s Roar plan and associated Service Level Agreement (SLA). Plan options include:
Guaranteed Response Time (GReaT) – purchased allocation
Open Queue – no cost
Temporary 30-day trial Roar allocation – no cost
Job Submission Dependent upon the PI’s Roar plan and associated SLA
Storage Directories Home – No cost; available to all users; backed up
Work – No cost; available to all users; backed up
Group – Fee-based; allocation varies with SLA; backed up
Scratch – One million files capacity; NOT backed up; routinely deleted after 30 days
Wall Time Zero wall time limit for GReaT accounts
48 hours wall time limit for Open Queue
Software Stack Access to existing pre-installed software packages. The stack includes application-driving software (e.g., compilers and communication libraries) and commonly used research applications.

Special requests should be submitted via an email to and are subject to faculty defined governance.

5.5 Account Modifications

Requests to change account attributes must be submitted to All account modifications must be approved by an Roar account consultant and verified by the sponsor of the account.

5.6 Account Lifecycle

The following table lists the possible states for an ICDS account:

Account State Description
Pending Login requires additional automated interaction
Active Login directly
Inactive Login requires a state change initiated by either the end user or the Roar Operations Team.
Note: Inactive status may result from system default settings or manual intervention by System Administrators. Refer to section 4.10, Account Reinstatement for account restoration
Deleted Previously existing account is removed from the accounts system; audit trail maintained

The lifecycle of an account is dependent upon the user account type. The following table lists the maximum authorization periods for the different user categories:

User Category Maximum Authorization Period
Faculty/PI Indefinite as long as University affiliation is maintained or upon request for change to “Inactive”
Students/Postdocs/Researchers/Staff Two years or as authorized by the Sponsor; annual review
Sponsored Guests One year or as authorized by the Sponsor; annual review

Faculty/PIs who leave the University will maintain their ICDS account as long as their original Penn State Access ID remains active. See Identity Services’ “Access Account Deactivation and Extension” site for more details, including the default duration. The determination of whether or not a refund will be issued for any unused services that were already paid for will be outlined in the signed Service Level Agreement (SLA) that originally granted access to Roar services.
Faculty/PIs who leave Penn State and whose ICDS account has transitioned into an “Inactive” state can reacquire an ICDS account by first requesting a Sponsored Guest account from ITS and then submitting an Roar account request.

Accounts may be transitioned to “Inactive” in certain situations at the discretion of the Roar Security and Compliance team in coordination with the ICDS Leadership team. Situations where this can occur include:

  • Any violation of Penn State or Roar policies, guidelines, and procedures. Roar guideline documents and procedures are available at
  • Possible account compromise
  • Loss of Penn State affiliation (in which case the user may be eligible for a sponsored guest account)
  • Upon request of a sponsor who oversees the use of the account
  • Termination of the last SLA between the PI and Roar.

5.7 Account Deletion

Deletion of an account does not necessarily mean that the data associated with the account will also be deleted. The handling of any data associated with an account is discussed in ICDS-ACI-P020: Data Protection and Retention.

5.8 Account Transfer and End User Status Changes

User accounts are only to be used by the individual to whom the account is assigned. Although data associated with an account may be transferred to another individual via processes outlined in ICDS-ACI P020: Data Protection and Retention, a user account itself may not be transferred to any other individual.
Faculty/PIs who leave the University may transfer their sponsored accounts to other faculty/PIs upon mutual agreement of all parties involved and in coordination with the appropriate ICDS teams (Leadership, Client Engagement, Operations). The state of a sponsored account will parallel the state of the associated sponsoring account, with the exception of any sponsored account that previously has had separate actions taken against it.
Account holders are expected to notify Roar of any status changes via a service desk request so that a determination can be made regarding any necessary changes to accounts. This requirement is in addition to the requirements outlined in Penn State Policy HR102: Separation and Transfer Protocol.

5.9 Access Control

All access to Roar resources should only be executed in a secure manner:

  • All account credentials must be stored and transmitted in a manner meeting University and Roar requirements. As an example, “telnet” is not a permitted communications protocol for accessing Roar resources since it passes login credentials in unencrypted form
  • Account holders are not permitted to enable “Guest” accounts or anonymous access to data or services hosted on Roar resources
  • Roar will provide a list of approved remote access mechanisms both on the ICDS website and in the account approval message to end users
  • Shared accounts are not allowed on Roar and it is the responsibility of the PIs to make sure that their sponsored users are aware of this. Sharing passwords or credentials is a violation of University and ICDS policies and procedures. (Reference AD96:

Always remember: Roar personnel will NEVER ask for a password.
All users, internal or external to ICDS, are required to lock their system in accordance with University policy and standards (i.e. AD95).

5.10 Compromise Response

If you suspect that an account compromise may have occurred, or if you identify a situation that could potentially lead to an account compromise, then it is your responsibility to report it. The following reporting structure should be followed with progression down the list if you feel that the entity you are reporting to is not responding adequately to the situation:

  • Principal Investigator
  • ICDS Security
  • ICDS Administrative Staff
  • Penn State Security Operations and Services

When Roar is made aware of a potential compromise, any potentially compromised account is rendered “Inactive” (refer to section 4.5, Account Lifecycle) and any potentially compromised node is removed from network connectivity and seized by Roar administrators. If Penn State’s Office of Information Security (OIS) is not already aware of the compromise, then a report is submitted to them as well. If the compromise is validated, the node is fully scanned for any information classified as High (e.g. Personally Identifiable Information (PII), Controlled Unclassified Information, Export Controlled Data, etc.), and a report is submitted to OIS. Once mitigation instructions have been provided by OIS, the node is wiped and rebuilt by ICD Operations.

5.11 Inactive Account – Reinstatement

Accounts may be rendered Inactive through manual intervention by system administrators. Manual intervention is directed by the Roar Leadership and is typically the result of possible or actual account compromise (refer to section 4.9, Compromise Response), policy infractions, activities deemed by Roar as misuse of system resources, or to support audit and account refresh events. All manual intervention instances will be adjudicated by Roar Leadership for subsequent account restoration and administering corrective action as required.

6.0 Enforcement

All account policies exist to facilitate research. Any PI, Faculty, Student, or Sponsored Guest violating any of the above policies are subject to immediate termination of their account. Data will be retained and can be transferred to the PI. Any employee, student, or visitor found to have violated ICDS-ACI-P030 may be subject to disciplinary action by their administrative unit, the college, or the University.

7.0 Supporting Documents

ICDS-ACI-P020: Data Protection and Retention

8.0 Appendix

8.1 Glossary

ACI-bRoar sub-system configured to execute jobs submitted to a variety of queues, i.e. batch processing.
ACI-uRoar User-Specific “Development/Test” interactive subsystem where PIs may specify a system configuration for user-specific interactive sessions, including root access and user-defined software stack.
BatchExecuting or processing of a series of programs (jobs) on a system without manual intervention.
CoreData processing unit within a server. The total cores per server is dependent upon the vendor’s architecture of the server.
Core AllocationAmount of physical compute resources purchased by or granted to a user through Roar plans.
F&AFacilities and Administration charge, sometimes referred to as “indirect” or “overhead”.
GPFSGeneral Parallel File System.
GroupA self-defined set of multiple users—for example, students and researchers in a faculty member’s lab. Such rights as access to storage and allocation of resources can be delegated in an organized fashion by the PI.
Group StorageDedicated disk space for storing group-related data or research.
Guaranteed Response TimeThe maximum time that it takes for a job to start execution after submission to a queue.
Home DirectoryA user’s dedicated disk space for storing personal files, directories and programs. Directory that a user is taken to after logging into the system.
ICDS-ACIInstitute for Computational and Data Sciences – Advanced Cyber Infrastructure.
ICDS-ACI-BurstQueue to allow usage of compute resources in the ACI-b subsystem above a PI’s physical allocation that are needed for a short time period.
ICDS-ACI-GuaranteedQueue providing access to the ACI-b subsystem within a guaranteed time, provided request is within a PI’s physical allocation.
ICDS-ACI-OpenQueue to provide user access to idle ACI-b resources that can be used during times when supply exceeds demand.
Legacy SystemsPre-2015 ICDS computing systems, such as the Lion-X clusters.
Login NodesFront-end servers used to log in to the Roar compute system.
NASNetwork-Attached Storage.
PIPrincipal or Primary Investigator. Person, such as faculty, who is authorized to direct all of his or her research Roar resources, e.g. access, storage, compute.
Pre-emptionThe act of pausing or stopping a job that is currently processing in order to fulfill terms and conditions to other users under service level agreements.
Scratch DirectoryDisk space dedicated for temporary storage of data.
Service Level Agreement (SLA)Agreement between ICDS and Research PI in relation to research Roar resources, e.g. access, storage, compute.
SubsystemA unit or device that is part of a larger system, e.g., ACI-b.
SystemThe computing engine along with the software, storage, network, and peripheral devices that are necessary to make the computer function, e.g., Roar.
UserA person, such as a student or faculty, who has a user account to use the Roar resources.
User AccountThe means by which a user can access a computer system. Roar has four distinct user accounts: PI, Student, Staff, and Sponsored Guests.
Wall TimeA queue parameter that is set to define the maximum allowable execution time for a job once it has started.
Work DirectoryUser’s dedicated disk space for storing research data.