Applications

User Authentication and Authorization

LSST will have a central authentication system:

• Available throughout internal LSST infrastructure (Base, Archive, DACs)
  • Categories
    • Internal LSST users (operators, staff scientists, technicians)
    • External users (public, students, scientists, partners)
  • Username/password and, for critical access, two-factor authentication
  • On server side, map authentication to a delegatable crypto token. For example:
    • Convert username/password to a signed cryptographic token (for example, OpenID does this)
    • Exchange token for a short-lived PKI certificate (for example, GridShib? or MyProxy?)
• Serves user attributes to applications that depend upon it
  • Required
    • User ID
    • Authentication level (password, two-factor, etc.)
    • Identity Authority (if federated)
  • Possible
    • Personal info (Name, Email, etc.)
    • Institutional attributes (student, staff, funder, etc.)
• Possible technologies
  • OpenID
  • Shibboleth & GridShib?

Trust of Services

Services that interact with each other will need to establish a trust relationship. Possibilities are:

• Trusted network, for example in the summit and base
• On a non-trusted network, services will require their own authentication and encryption abilities, such as long-lived PKI credentials

Data Integrity

Even in a secure network, we need to verify the integrity of data transfers. Most likely this will be via:

• A checksum that accompanies each chunk of data
• A feedback channel that can request a re-send

We may integrate the checksum with long-term data integrity checks; for example, the Archive Center may check integrity each time it reads data, or even on a more frequent maintenance schedule, so that it can request a spot-recovery from a DAC remote backup.

Transfer from Summit to Base

Trusted network. LSST owns the fiber, tightly controls access to the network, and monitors for intrusions.

Transfer from Base to Archive

Raw image data and metadata are sent to the Archive over a series of dedicated networks between the Base Facility and the Archive Center.

Transfer from Archive to DACs

DACs are expected to receive data from the Archive either in bulk (such as at startup or during disaster recovery) or piecemeal (such as daily updates, isolated data loss).

Transfer from DACs to Archive (Recovery)

The DACs double as a distribute backup service for LSST. Normally, data flows only one direction -- from the Archive to the DACs. However, under some circumstances we will need to transfer data the other direction:

1. Catastrophic data loss at the Archive
2. Isolated corruption at the Archive