OAuth2¶

OAuth2 is a framework that enables users to authorize applications to retrieve information, either in the form of a token or through the use of a token, about the user from an identity provider. An identity provider may be Google, Github or something else. CILogon functions as sort of a meta identity provider which implements the OAuth API.

OAuth2 specifies how you may ask for information about a user. It also specificies a method, through tokens, which a service may use to request and validate information about the user.

With OAuth2, all tokens are transferred via the Authorization Header.

JWT¶

A JSON Web Token (JWT) is a way of encoding specific claims for a subject in JSON, as well as including signatures (JWS) of the token and information on validating those signature (JWE/JWK) in the same token. Included in the JWT specification is also a way of encoding a token using Base64 in a way that’s friendly for the web.

See also: https://tools.ietf.org/html/rfc7519

CILogon¶

CILogon is a generic authentication proxy/clearing house for authentication providers from multiple institutions and services (e.g. Github, Google, NCSA, Stanford). It serves as a common endpoint for the various providers and translates their authentication mechanisms to a common authentication mechanism, while also translating claims when possible. We use CILogon to transform authentication information and claims into OAauth-style claims through CILogon’s OpenID Connect interface. With this, we typically know what institution a user is from, their email address, and whether or not they are faculty, staff, or a student. We may use this information to also map them to an NCSA user, provided that information has been previously captured, and potentially retrieve additional claims about that user, such as LDAP groups they are a member of.

SciTokens¶

SciTokens is an implementation of capabilities-based authorizations based on JWT claims, modeled as read and write, on top of a very simple JWT token.

It’s expected that we will use some form of login flow from CILogon to eventually translate claims about a user and add them to a SciTokens token. It’s expected that there will be a service where a user would present tokens acquired from CILogon to the SciTokens service to acquire a refresh token and an access token, with a very limited lifetime, from a SciTokens service. The refresh token may be used to acquire new access tokens to present to services which will accept them. This implies that services or applications which frequently may need to operate on behalf of a user for longer than the lifetime of an access token must acquire a refresh token.

Portal Aspect (Firefly)¶

When a user first logs into the portal, they will be redirected to CILogon. They may select either NCSA as their Identity Provider or their home institution. CILogon executes the login, ultimately returning information about who the user is at NCSA to the portal aspect through CILogon’s OpenID Connect interface. This providers the Portal aspect with an access token and a refresh token.

Portal to DAX¶

The Portal will send the access token to a DAX service. The Portal should configure an HTTP client with an authentication filter that can check the expiration of the access token, and, if necessary, use the refresh token to acquire a new access token from the Token server before issuing a request to the DAX services.

Notebook Aspect¶

The Portal and the notebook should share some commmon session information about the user, including refresh tokens, to enable smooth transitions and interoperability between the two. How this is implemented is undefined.

Once a user is logged in to the Notebook access, a user in the Notebook aspect can be viewed as a special case of Third Party access where we have some access to the user’s local environment, so we may be able to bootstrap an authentication mechanism on behalf of the user which ensures any necessary tokens are implicitly available in the user’s envioronment. For software developed by the LSST project, software which may use the DAX services, such as the Butler, we will ensure those applications can be automatically configured based on some form of information in the user’s Notebook environment. Other third party software may be automatically configured, or they should be configurable in the same way as if a user was running on their local machine and not in an LSP instance.

DAX¶

Authentication to DAX services is performed by using Access tokens only. Applications calling into DAX services are responsible for ensuring an access token is valid and hasn’t expired before calling into a DAX service.

If the DAX service must call another service within the DAC, such as stashing the results of a long-running TAP query in a user’s workspace after the expiration of an access token, we will allow the DAX services to perform that operation by trusting them.

Third Party¶

We expect there to be an explicit flow a user must engage in for all third party authentication. It’s not clear if a user of third-party applications will share a common token (e.g. Refresh Token) or if a user will need to explicitly retrieve tokens for all third party services. At least in the case of TOPCAT, we are incentivized to make the process as easy as possible, and we will work with the TOPCAT developer closely to develop an optimal solution.

In the case of X.509 certifications, for applications such as GSI-SSH, a certificate is typically written out to a well-defined location in the system’s temporary disk space (e.g. /tmp/x509up_u${UID}), .globus for Windows users) for reuse by all GSI-enabled applications. A similar convention would need to be constructed to allow multiple third party applications to share a common set of credential, or we can stash a token in an environment variable.