Making frequent changes to cloud applications running in production is the de-facto standard. To minimize errors, engineers use CI/CD automation, techniques like code reviews, green-blue deployments and others. Git pull requests often serve as a foundational component for triggering code reviews, Slack notifications, and subsequent automation such as testing and deployments. This automated process enforces peer reviews and creates enough visibility to minimize human error.

Writing a web application that supports securely logging into a website and managing your credentials is a surprisingly difficult task. You have to develop a way to manage sessions, understand how browsers store state (cookies), learn a cryptographically safe password storing technique (like bcrypt), all the while making sure you mitigate common web security vulnerabilities like XSS and CSRF.

Teleport has supported multi-factor authentication (MFA) for a while now, via Authenticator Apps (TOTP) and Hardware Tokens (U2F) such as YubiKeys. But this support was pretty limited: you could only choose one MFA protocol and users could only register one device. If a user lost their device, they would be locked out and need an account reset by the administrator. So, for Teleport 6.0, we’ve reimplemented the MFA support to make it more flexible.

Security Assertion Markup Language (SAML) 2.0 is one of the most widely used open standard for authentication and authorizing between multiple parties. It’s one of the protocol that give users the single sign-on (SSO) experience for applications. The other adopted open standard is OAuth and OpenID. Of the two, SAML 2.0, released in 2005, remains the 800 pound gorilla in Enterprise SSO space. This post provides a detailed introduction on how SAML works.