Back in the 90s when AdaCore was founded, the state of IT security was very different. A unique Unix login and password were enough to connect to a shared server and run business applications. Most of the protocols used were still unencrypted, and the most elaborate access controls were based on Unix groups and perimeter defense. As the company evolved, we gave users access to more and more services, some not hosted on-premise. More services meant distinct credentials. Security-savvy users, who did not accept reusing the same password everywhere, had the burden of maintaining all these distinct credentials. Most credentials were long-lived, and very often shared. Also as the notion of perimeter defense became more and more fuzzy with the introduction of PaaS, IaaS, .. the need for safer access and communication protocols increased significantly.

The industry then shifted to web services relying on identity providers. Single-Sign-On promised to address all authentication challenges once and for all. We followed the trend: SAML and OIDC setups allowed us to connect external and internal services to our identity providers. Switching to Google Workspace, we rolled out progressively stricter policies regarding authentication mechanisms such as password length complexity, the use of multi-factor authentication, better audit capabilities, and centralized onboarding and offboarding.

Many users of the AdaCore information system were not benefiting much from Single-Sign-On. Developers still had to use terminal applications to access servers and source code repositories. They could not effortlessly reuse their Single-Sign-On tokens in their command-line tools relying on REST APIs or Cloud APIs. In addition to their Single-Sign-On credentials, they had to maintain long-lived SSH keys and application passwords. System administrators had difficulties ensuring former workers had no access to any of our systems.

Our main challenge was to rebuild something similar to Single-Sign-On but for non-web-based applications. Our idea was to find a way for the developer to access our identity provider and get a short-lived attestation of its identity on its workstation. We developed a tool and an associated service to get that attestation.

Before interacting with AdaCore services, users can run a command on their terminal. The tool redirects the user to an URL that the user opens using his web browser to authenticate on Google Workspace. In case of successful authentication, the tool stores the identity attestation embedded into a JWT refresh token. This token is short-lived and is only a proof of identity: it does not contain any permissions in its scopes or attributes.

Once the developer possesses that identity attestation, they can exchange that identity proof for other credentials like very short-lived JWT access tokens to access REST APIs. We have developed several services that consume JWT access tokens and return other temporary credentials. For the end user, this approach presents the advantage that there is no need for technical knowledge on how to generate and secure long term credentials such as Access Keys. Also from an IT perspective, disabling the Google Workspace identity is enough to shut down access to all our CLI and Web-based services.

One of our most pressing maintenance issues was the maintenance of our SSH access control configuration. Our SSH security was based on public-key authentication. We had to deploy users' public keys on all the servers they had access to. And of course, we had to remove users' public keys when they were changing roles. For quite some time, we wanted to switch to SSH certificates which provide a very secure system, in particular when associated with short-lived tokens. SSH certificates also free you from the tedious maintenance of authorized_keys on all your servers.

To implement a SSH certificate based access control, we decided to leverage our proof of identity. Users can run a tool automating the generation of a SSH key. The key is securely sent to a service via a HTTP API, and, in exchange, users receive the key signed with our SSH CA authority. We also sign our servers’ host keys and automatically generate the user SSH configuration files to ensure that all connections will automatically verify the servers' identity. With that setup in place, there are no more "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" messages when connecting to a server. As for REST APIs tokens, both host and user SSH certificates have relatively short expiration dates.

Among the upcoming additions to the service, users will soon be able to generate short-lived X509 certificates and private keys to sign either commits or metadata. This effort is part of a larger project to be compliant with SSDF NIST Guidance.

Finally the same approach is used to authenticate services between each other except that in order to get the identity attestation, the service uses other kinds of security challenges such as being able to assume a given AWS IAM role. In the future the attestation will use SPIFFE identities rather than tailored email addresses associated with each service.