Student Developed applications are a special subset of the applications that use the Campus API Gateway. To submit a request to access APIs for a student-developed application, please see the API Access Request page. To ensure the safety and security of the data provided there are some special considerations for applications using APIs. These considerations include:

Registrar Statement on Student Access to Protected Student Data APIs

UCSB must ensure that security best practices are being followed and have auditable evidence that the campus' student data is being used appropriately and securely.

To confirm that student-developed applications are following security best practices and that the campus' student data is being used appropriately and securely, regular security reviews must be performed by the Campus API Gateway Team.

Due to the resourcing limitations of the Campus API Gateway Team to perform these security reviews, UCSB has no way to ensure that security best practices are being followed and verify that the campus' student data is being used appropriately and securely; therefore, UCSB cannot grant access to confidential student information for any student-developed applications.

Must Display that it's not an Official UCSB Application

Your application will need to display someplace within it that it is not an official UCSB application. This just needs to be some brief text noting that it is not an official UCSB application.

  • For Mobile Apps: This should be noted in the Description of the application within the store (iOS App Store, Android App Store, etc). And, on the application loading screen.
  • For Web Applications: This should be noted in the footer of the site, or within an About page description.
  • For Browser extensions: This should be in the Description within the store (Google Web Store, Mozilla Add-ons, etc). And, within the About description of the extension.

Credential Storage

In general, all credentials, either for the Campus API Gateway or other services, need to be securely stored, protected, and used. To do this, Secret Keys, Passwords, and Secure Credentials need to be:

Not Included in Source Code Repositories

Keys and Secrets should not be checked into source control systems. One of the easiest ways to expose a secret is to accidentally check it into a new GitHub project. GitHub provides a service that notifies interested parties when new repositories are created. Groups (both black hats and white hats) monitor the creation of new repositories and race to scan the source code for secrets and passwords. In general, if a secret key is exposed through an accidental check-in it will be recorded by a malicious group; even if they don't have plans to use it right away. The safest thing to do is be mindful of storing your applications' keys and secrets in files that are assured to not be checked into source control. Two common ways to do this are:

  • Use a password safe. (Preferred) These are external services like AWS KMS, Azure Key Vault, Google KMS and there are many more.
  • Use a source control ignored file. Often it's easy to just create a file on disk within your source code and simply add that file to your .gitignore list (or your preferred source control's .ignore file).

Encrypted at Rest

Wherever your Keys and Secrets are stored, they should be encrypted. This is a requirement for both the keys and secrets that you use in local development and even more important on any keys or secrets that will be shipped with your application. Mobile applications are very susceptible to be downloaded and decompiled to their original source code; when a secret is stored within the compiled source as plain text it becomes very easy to retrieve. There are many ways to do this:

  • Server-Side Applications

    • Use a password safe. These are external services like AWS KMS, Azure Key Vault, Google KMS and there are many more. This isn't always the easiest thing to do as you have to securely identify your application to the password safe; and how do you secure that password? This works much better in environments where the credentials of the applications are on the system and passed seamlessly in the background to the password safe.
    • Inject the password into environment variables. Some deployment systems, like Heroku, Kubernetes, Azure Web Apps, AWS Configuration and more have ways to safely store your applications' passwords and secrets outside of your application and they will inject the values as runtime environment variables to solely by used by your application.

  • Mobile Applications

    • Built-in Key and Secrets Managers. This is a common problem for mobile applications, and the platform providers have built key storage into the operating systems: iOS, Android.

Shared through Secure Mechanisms

So, you've ensured you are securely storing your secret for your development and kept the secret safe in the running application, but now a new developer comes onto the project and you need to share the password with them. How do you share it securely?

  • DO NOT SEND YOUR SECRETS OVER EMAIL. Get in the habit of never putting any sensitive information into emails.
  • Use a password safe. These are external services like AWS KMS, Azure Key Vault, Google KMS and there are many more.
  • If a password safe isn't available, ensure the mechanism you are using to share the secret uses some form of login to authenticate the person that will retrieve the secret. Try diligently to encrypt the password within the shared location, and delete the shared secret once the recipient has retrieved it.

HTTPS (End-to-End)

All communication from the client through your applications services/servers all the way to the Campus API Gateway needs to be encrypted (encryption in flight). In general, this is provided by using https to make web service calls. Purchasing SSL certificates is pretty inexpensive and provided by many cloud providers (Heroku, AWS, Azure, GCP). You can also use Let's Encrypt to get free certificates.

Student Credentials (Google OAuth)

Student developed applications could provide some student-specific data to the logged-in user. When the user is a student, the applications will need a safe and secure way to ask the student to authenticate themselves to the system and the application will need to provide those student credentials when making calls to the Campus API Gateway. For more information on this please see Security - Google End User OAuth.

Functional Email Accounts

Student's don't have the ability to create Functional Accounts the same way that staff do. As such, the Functional Account can be handled in one of these ways:

  • If you are a student doing an assignment on your own for a class, please indicate this within your API Access Request. Within the request please list:

    • That you are working on the project for a class, including the class number (ie. CMPSC 180)
    • List your Faculty Sponsor with their email address within the Other Business Contacts list, and note they are the "(Faculty Sponsor)"
    • State that you will be working alone and that you wish to use your @ucsb.edu account as the Functional Account

  • If you are a student within a team, doing an assignment for a class, please indicate this within your API Access Request. Within the request please list:

    • That you are working on the project for a class, including the class number (ie. CMPSC 180)
    • List your Faculty Sponsor with their email address within the Other Business Contacts list, and note they are the "(Faculty Sponsor)"
    • List your teammates names and email addresses within the Other Business Contacts list
    • Create an email account for the team @gmail.com, that the team can access and monitor
    • State that you will be working as a team and that you wish to use the @gmail.com account as the Functional Account
    • The API Gateway Admin will create a new account on the Developer Portal (this site) for the @gmail.com account, and they will send you a password using saltify.io.
    • Once you have the ability to log into the new Functional Account on the Developer Portal, you'll need to create a new Application within that account and update the API Access Request with the new account information.

Application Requests

Detailed instructions to request an application for use with the Campus API Gateway can be found on the API Access Request page. However, when a student application has requested access to APIs that require access approval a few special considerations need to be taken:

  • Sponsorship by a UCSB Faculty Member or Associated Students

    Student applications must be sponsored by UCSB Faculty Member or the Associated Student office. This ensures there is an entity on campus that has reviewed your applications idea, and is taking the responsibility of performing periodic security reviews to validate that the application follows required security standards and the data is used appropriately.

    • Please add the your Faculty Sponsor with their email address within the Other Business Contacts list, and note they are the "(Faculty Sponsor)".
    • If you are requesting access to an API that requires Approval (ie. not Auto-Approved) please also email support@developer.ucsb.edu with your Faculty Sponsor CC'd, so that the API Gateway team knows that your Faculty Sponsor has awareness and they are willing to take on the responsibility of security reviews and liability of ensuring the data is used appropriately.

  • Open Source Projects Only

    This ensures that the Campus API Gateway team can audit your source code on a periodic basis. The campus wants to ensure that security best practices are being followed and have auditable evidence that the campus' student data is being used appropriately and securely.

    Please include a link to the projects source code within the Application Technologies section.

  • Regular Security Reviews

    To ensure the applications are following security best practices and that the campus' student data is being used appropriately and securely, regular security reviews will be performed by the Faculty Sponsor (and periodically by Campus API Gateway Team or a designated delegate). These reviews may also include follow-up meetings where discussions about lists of improvements and application roadmaps may be developed. As a project shows long term stability the frequency of the security reviews may become lessened.

  • Contact person that will be responsive to requests for information

    All applications (student and otherwise) are required to have a person or group of people who will be responsible to keep up communication with the Campus. This is necessary to ensure that if there are concerns about the application, its security, or its use of data they can be addressed and remediated quickly.

  • Servers and Resources used with the application must be in the United States

    All servers, services, and resources used to host and provide the application need to be running in the United States. This ensures we don't have to worry about unexpected legal responsibilities that we are not tracking.

  • Student Information Must Not Be Stored

    The student information provided by the Campus API Gateway is expected to be used for immediate processing and display to the students. Do not store or distribute the data in any way.