Abstract:
Distributed cyberinfrastructure requires users (and machines)
to perform some sort of authentication and authorization
(together simply known as "auth"). In the early days of com-
puting, authentication was performed with just a username
and password combination, and this is still prevalent today.
But during the past several years, we have seen an evolution
of approaches and protocols for auth: Kerberos, SSH keys,
X.509, OpenID, API keys, OAuth, and more. Not surpris-
ingly, there are trade-offs, both technical and social, for each
approach.
The NSF Science Gateway communities have had to deal
with a variety of auth issues. However, most of the early
gateways were rather restrictive in their model of access and
development. The practice of using community credentials
(certificates), a well-intentioned idea to alleviate restrictive
access, still posed a barrier to researchers and challenges for
security and auditing. And while the web portal-based gate-
way clients offered users easy access from a browser, both the
interface and the back-end functionality were constrained in
the flexibility and extensibility they could provide. Design-
ing a well-defined application programming interface (API)
to fine-grained, generic gateway services (on secure, hosted
cyberinfrastructure), together with an auth approach that
has a lower barrier to entry, will hopefully present a more
welcoming environment for both users and developers.
This paper provides a review and some thoughts on these
topics, with a focus on the role of auth between a Science
Gateway and a service provider.
