Balaji Boggaram Ramanarayan

The following baseline set of questions to put into Threat Modeling and Analysis in securing any piece of software is very critical. Authentication and Authorization  How do users and other actors in the system, including clients and servers, authenticate each other so that there is a guarantee against impersonation?   Do all operations in the system require authorization, and are these given to only the level necessary, and no more (for example, a user accessing a database has limited access to only those tables and columns they really need access to)? Third-party libraries and components Are all dependencies (both direct and transitive): Updated to mitigate all known vulnerabilities? Obtained from trusted sources (e.g., published by a well-known company or developer that promptly addresses security issues) and verified as originating from the same trusted source? Code-signing for libraries and installers is highly recommended—has code-signing been implemented? Does t...

  OAuth 2.0 / OpenID Connect in Lightwave Introduction Lightwave OIDC serves two main purposes. 1. Security Token Service (STS) in the sense that it issues security tokens in the form of JWT tokens (similar to WS-TRUST which issues SAML 2.0 Assertions) 2. single signon (SSO) / single logout (SLO) service for web-based applications (similar to SAML 2.0 Authentication Request and Single Logout protocols aka websso)   Implementation (Open source)   https://github.com/vmware/lightwave/tree/dev/vmidentity/openidconnect   Roles User (Resource Owner) User agent (browser) Client (aka Relying Party / RP) e.g: lightwaveui Authz Server (aka OpenID Provider / OP) Resource Server (server that wants to implement authz for its API's) e.g: admin server JWT tokens OAuth 2.0 defines an access_token and a refresh_token but does not specify their format. We are using JWT as the format. OpenID Connect additionaly defines an id_token and specifies its format as a JWT. Lightwave ...